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?
Best regards, Florian
[1] https://gitlab.com/lava/lava/-/blob/master/lava_dispatcher/actions/deploy/ap... [2] https://salsa.debian.org/kernel-team/initramfs-tools/-/blob/master/unmkinitr...
Hello,
Le mar. 12 mars 2024 à 11:54, Florian Bezdeka florian.bezdeka@siemens.com a écrit :
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/ap... [2] https://salsa.debian.org/kernel-team/initramfs-tools/-/blob/master/unmkinitr...
-- 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
lava-users@lists.lavasoftware.org
-
Florian Bezdeka -
Remi Duraffort