Issue with initramfs testing

[Emanuele Iaccarino]

Hello,

I am a GSoC contributor for ChromiumOS and my project requires an initramfs.

I have defined the build target for my initramfs in both the platform/initramfs/[initramfsname] folder and in the chromeos-initramfs ebuild file, and I managed to get a build running the instructions provided here. After getting the build, I ran the testing instructions to get a VM image that I could test with QEMU to try my initramfs, but the VM keeps kernel panicking as soon as I start it (logs attached).

This issue reproduces both with my initramfs and with the Flexor initramfs untouched from the main tree.

 What is the current way to define a new initramfs and get a functioning VM for testing? My goal is to get a shell environment where I can run a disk erasure.

Thank you,

Emanuele

[Daniil Lunev]

Hi Emanuele,

It will be easier for us to help you if you could upload your WIP changes so we can take a look at what might be going wrong.

From the error message the panic generated it looks like the initramfs kernel code complains that the supplied archive doesn't have the correct cpio magic in the header, which likely means either a malformed archive or a wrong object passed as an archive.

Cheers,

Daniil Lunev

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
https://groups.google.com/a/chromium.org/group/chromium-os-dev
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-d...@chromium.org.

--

Daniil Lunev

ChromeOS Platform Storage

[Emanuele Iaccarino]

Hello Daniil, 

thank you very much for your reply!

There is no WIP change needed to reproduce the issue I am having as I am currently getting the same cpio magic number kernel panic when using a clean tree with no changes and already defined initramfs configurations.

I can give an outline of what has been tried so far, using recovery_ramfs as example (I have tried both flexor_ramfs and recovery_ramfs):

-  Build of the initramfs package through USE flags: USE=recovery_ramfs emerge-amd64-generic chromeos-initramfs --verbose

- Once that build is completed successfully and the initramfs is moved to /build/amd64-generic, I cd into platform/initramfs/test and run ./test.sh --board=amd64-generic recovery

- Afterwards, I have a complete VM image in build/initramfs/recovery that I can launch through the supplied qemu script. I have tried both simply running the qemu script without changing anything, and providing the kernel and CPIO archive file through the -kernel and -initrd arguments.

Since the kernel panics were forcing reboots, I have supplied to the VM the -no-reboot -nographic -append "console=ttyS0 panic=3"  arguments as well.

Please let me know if you need any further information!

Thanks,

Emanuele  

[Gwendal Grignou]

Talking with Emanuele, the problem may be related with test.sh that requires some update. See https://b.corp.google.com/issues/322818179. Opened a world-accessible duplicate bug:  b/339442878.

[Emanuele Iaccarino]

Hello,

I did some more testing today and it seems like the issue is actually related to the cpio archive compression. I have disabled compression entirely and submitted a CL (https://chromium-review.googlesource.com/c/chromiumos/platform/initramfs/+/5527115) with the changes that got me a working build and set it as WIP. Please let me know if the way I filled in all the fields etc. is correct as this is my first CL! :) 

I think the compression is done on the kernel side too (for supported architectures) as specified in the Kconfig for the Linux kernel in third_party, so we could be doing double compression even after just moving it to the initramfs.mk makefile.