GRUB stuck unable to start flatcar

[Moxinilian]

Hello!

I am trying to run Flatcar bare metal on a Framework 13 7840U laptop motherboard. Because this motherboard only supports UEFI boot and not legacy boot options, I was not able to use the Flatcar provided install image. Instead I used an Arch Linux install image instead that I put on a USB stick, to which I added wget, flatcar-install and my ignition file (that I tested and works in QEMU). I installed it on my NVME drive with flatcar-install -C stable -d /dev/nvme0n1 -i ignition.json, which finished and informed me the installation was successful.

However, when I try to boot into the newly installed drive, GRUB successfully starts and displays the three boot options (default, A and B). But when I start the default boot option, I simply get a dead (non-flashing) cursor, and the system hangs indefinitely. No logs, it looks like it was not even able to start Linux.

I don't really know where to go to debug from there. Did I miss something?

Thanks!

[chewi]

Apologies for not providing a UEFI ISO. It's a known issue, but we've struggled to get around to it.

It's hard to say what's causing your issue, but we are about to bump GRUB. There's currently an image you can try with sudo flatcar-install -d /dev/nvme0n1 -i ignition.json -f, but I suspect it's about to get cleaned up.

[Moxinilian]

Hey! Thanks, no worries, with the script it should work anyway, so that wasn't too much of an issue.

I tried with the image you linked, unfortunately the result seems to be the same. I don't really know what a normal grub entry for Flatcar looks like but it doesn't have a lot in it, is that normal?

Otherwise I don't know what else could be going wrong. I'm sorry, I'm not super experienced debugging early boot issues like that, does anyone know if there is a verbose mode in grub maybe that could give me some more feedback about what is happening?

[tormath1]

Hey, at this point you can try to update¹ the linux command line (the last one) to have something like:

 linux$suf $gptprio_kernel $gptprio_cmdline $linux_cmdline systemd.journald.max_level_console=debug console=ttyS0

Then hit "Ctrl+x"

This might bring more debug information, maybe it's just an Ignition configuration issue. :)

Footnotes

1. https://www.flatcar.org/docs/latest/provisioning/ignition/boot-process/#debugging-ignition ↩

[chewi]

Bummer. I'm assuming you don't have Secure Boot enabled, otherwise you wouldn't have got this far. Our development builds are not signed for real firmware. It would just be helpful to rule this out.

I have debugged GRUB with GDB, but that was with QEMU, and even then, it was tricky. You can get some debug logging out of it though. When the menu appears, hit c for the console, and enter set debug=all,-fat. The FAT logging is very noisy and slows things down a lot. Then hit escape and choose the menu entry. If the interesting bit flashes by too fast, add set pager=1.

The boot entry in your screenshot looks normal. We set up the command line in variables in the global config.

It may be the kernel rather than GRUB that's the issue, but let's see where this gets us.

Some of our team members do have Framework laptops. Maybe not this specific model but still. They won't want to wipe their NVMe disks, but I wonder if it would reproduce with an external disk.

[Moxinilian]

Hey, thanks! @tormath1 changing the Linux parameters had no effect unfortunately, meanwhile, here is where it hangs with the grub debug logs:

This all looks pretty normal to me and it seems to fail when jumping to the kernel then? Actually that the text section is not executable is a bit odd...