I'm not 100% sure this is a bug and not my own oversight but I'm unable to successfully boot the kernel produced by buildroot when the initramfs filesystem option is selected using Grub on an x86_64 EFI system To isolate to the bare minimum number of changes I started with pc_x86_64_efi_defconfig, changed the file system selection from ext2 to initramfs and modified the post image script to account for the differences. The result is that after Grub I see only a frozen cursor in the upper left of an otherwise blank screen. The config and modified post script needed to reproduce are attached.
Created attachment 8031 [details] .config and post.sh
I enabled CONFIG_EFI_STUB support in the kernel and was able to boot the same kernel with embedded initramfs directly with just using EFI and omitting GRUB. That makes me think this is a GRUB issue.
Looked into this more and the source of the issue is setting the console argument to certain values causes the boot process to lock up but only when the initramfs file system is used. I have been setting the console value to null which causes the problem and when I changed it back to tty1 I made a typo and wrote /dev/tty1 which also causes the problem. None of these values cause a boot hang when used with a file system other than initramfs. This might have something to do with the /init script installed as part of the cpio fs option that initramfs depends on but since there is no output I can't tell what the exact problem is. #!/bin/sh # devtmpfs does not get automounted for initramfs /bin/mount -t devtmpfs devtmpfs /dev exec 0</dev/console exec 1>/dev/console exec 2>/dev/console exec /sbin/init "$@"
This sounds very much like what I observed too. When I try to boot an ARM system with U-Boot and with 'silent' flag set, /init fails, kernel panics and the local display is left with a cursor alone (I watch the kernel messages from the serial line). U-Boot's 'silent' flag makes it to adjust kernel command line with 'console=<empty>'. Here is a proposed patch: https://patchwork.ozlabs.org/patch/1166017
There is no entry for fs/cpio in the DEVELOPERS file. This bug and the patch feels like orphaned. What should we do? Pete, would you be able to evaluate and test the patch?
(In reply to Timo Ketola from comment #5) I tried this patch today with 2020.2.1 and can confirm it does fix this issue.
Pete, Timo, All, Fixed with commit 98a6f1fc02e41ac30db24ac2b7262033faabacde. Thanks for the patience while waiting for that fix. Regards, Yann E. MORIN.
Great, thanks all!