New: iniramfs file system fails to boot using Grub on EFI x86_64

https://bugs.busybox.net/show_bug.cgi?id=11866

Bug ID: 11866
Summary: iniramfs file system fails to boot using Grub on EFI
x86_64
Product: buildroot
Version: 2019.02.2
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: Other
Assignee: unassigned at buildroot.uclibc.org
Reporter: pmorici at dev295.com
CC: buildroot at uclibc.org
Target Milestone: ---

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.

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=11866

--- Comment #1 from Pete Morici <[email protected]> --- Created attachment 8031
--> https://bugs.busybox.net/attachment.cgi?id=8031&action=edit
.config and post.sh

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=11866

--- Comment #2 from Pete Morici <[email protected]> ---
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.

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=11866

--- Comment #3 from Pete Morici <[email protected]> ---
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 "$@"

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=11866

Timo Ketola <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |timo.ketola at exertus.fi

--- Comment #4 from Timo Ketola <[email protected]> ---
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

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=11866

--- Comment #5 from Timo Ketola <[email protected]> --- 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?

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=11866

--- Comment #6 from Pete Morici <[email protected]> ---
(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.

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=11866

Yann E. MORIN <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |ASSIGNED
                 CC|                            |yann.morin.1998 at free.fr
           Assignee|unassigned at buildroot.uclibc |yann.morin.1998 at free.fr
                   |.org                        |

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=11866

Yann E. MORIN <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Yann E. MORIN <[email protected]> --- Pete, Timo, All,

Fixed with commit 98a6f1fc02e41ac30db24ac2b7262033faabacde.

Thanks for the patience while waiting for that fix.

Regards,
Yann E. MORIN.

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=11866

--- Comment #8 from Timo Ketola <[email protected]> --- Great, thanks all!

You are receiving this mail because:
You are on the CC list for the bug.