Bug 11866

Summary:	iniramfs file system fails to boot using Grub on EFI x86_64
Product:	buildroot	Reporter:	Pete Morici <pmorici>
Component:	Other	Assignee:	Yann E. MORIN <yann.morin.1998>
Status:	RESOLVED FIXED
Severity:	normal	CC:	buildroot, timo.ketola, yann.morin.1998
Priority:	P5
Version:	2019.02.2
Target Milestone:	---
Hardware:	All
OS:	Linux
Host:		Target:
Build:
Attachments:	.config and post.sh

Description Pete Morici 2019-05-10 21:55:51 UTC

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.

Comment 1 Pete Morici 2019-05-10 22:00:30 UTC

Created attachment 8031 [details]
.config and post.sh

Comment 2 Pete Morici 2019-05-11 15:50:50 UTC

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.

Comment 3 Pete Morici 2019-05-13 13:11:35 UTC

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 "$@"

Comment 4 Timo Ketola 2020-03-05 08:02:41 UTC

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

Comment 5 Timo Ketola 2020-04-24 06:33:58 UTC

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?

Comment 6 Pete Morici 2020-04-25 01:55:04 UTC

(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.

Comment 7 Yann E. MORIN 2020-04-25 12:10:15 UTC

Pete, Timo, All,

Fixed with commit 98a6f1fc02e41ac30db24ac2b7262033faabacde.

Thanks for the patience while waiting for that fix.

Regards,
Yann E. MORIN.

Comment 8 Timo Ketola 2020-04-27 05:27:27 UTC

Great, thanks all!