Hi all,
over the last days I was trying to bring up a setup where we simply try
to boot up a kernel and initrd combination that is provided by Debian
"as is". Sounds trivial at first but I ran into a problem with the
initrd:
The initrd contains some microcode, shipped as prepended uncompressed
archive. The microcode is added because the intel-microcode package was
installed during image generation.
When such an initrd enters the LAVA machinery, where the initrd is
first unpacked and later re-packed the file gets corrupted in a way
that the kernel is unable to unpack/use it. The end result was that NFS
boot did not work as the mounting of the rootfs did not take place.
Interestingly there is no error message, not within the unpack/repack
step in LAVA and the kernel does not complain later during the boot
sequence either.
To disable the LAVA unpack/repack sequence I had to modify my deploy
action. Setting install_overlay and install_modules [2] to false seems
to qualify as workaround:
- deploy:
timeout:
minutes: 15
to: tftp
kernel:
url: <kernel-url>
ramdisk:
url: <initrd-url>
install_overlay: false
install_modules: false
Looking at the initramfs-tools implementation [1] I think that
something similar is missing in LAVA.
Does that make sense? Ideas / comments?
I believe that you are right as LAVA does not take into account the possibility for initramfs to have prepend data.
If you are willing to send a patch, I will be happy to review it?
Thanks
Best regards,
Florian
[1] https://gitlab.com/lava/lava/-/blob/master/lava_dispatcher/actions/deploy/apply_overlay.py?ref_type=heads#L556
[2] https://salsa.debian.org/kernel-team/initramfs-tools/-/blob/master/unmkinitramfs?ref_type=heads#L69
--
Siemens AG, Technology
Linux Expert Center
_______________________________________________
lava-users mailing list -- lava-users@lists.lavasoftware.org
To unsubscribe send an email to lava-users-leave@lists.lavasoftware.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s