Trying to understand Grub in 26.04 with unsuccessful booting

[paddylandau]

Ubuntu Version: 26.04

Desktop Environment: GNOME

Problem Description:

Background: I have installed Ubuntu 26.04 with TPM-backed LUKS. This is in a virtual machine so that I can test and understand it prior to installing it live. This lets me break it, and revert to previous snapshots.

Current test: I am trying to understand Grub and recovery options, which appear to have changed completely since 24.04.

What I did (part 1):

In order to access Grub on boot, I set GRUB_DEFAULT="menu" and GRUB_TIMEOUT=8 in /etc/default/grub, and ran sudo update-grub.

Now, I cannot get into my system! When booting, I am presented with just one option, namely to go into the BIOS settings.

This takes me into a loop: Go into BIOS, exit BIOS without making changes, and back to this screen!

If I interrupt the boot process with the Esc key, I get a better selection, as per the screenshot:

However, if I select the first option, “Continue to run mode”, guess what — I’m back to the previous screen!

• I don’t want “Install using enhanced-secureboot-desktop” — I have nothing to install.
• I don’t want to “Factory reset using enhanced-secureboot-desktop” — I’m just trying to get into my system.
• So, I try “Recover using enhanced-secureboot-desktop”.

The last option leads to two different outcomes, and I don’t know what causes one or the other (I’ve tried this many times; it seems random):

Scenario 1

A console asking for “localhost login”. I can log into my Ubuntu user into my Home folder.

Also, every ten seconds, the console outputs the message, serial-console-conf@ttyS0.serviceserial-console-conf@ttyS0.service. This covers whatever I’m trying to do.

I don’t know what to do here, so I try rebooting, which takes me back to the beginning loop.

Scenario 2

Asks me to enter my recovery key. After entering it, the console displays a bunch of messages, after which I end up with Scenario 1, and thus back to the loop.

Relevant System Information:

In case it makes a difference, this is the virtual machine setup:

• Host: Ubuntu 24.04
• VM: VirtualBox 7.2.10
• Guest: Ubuntu 26.04

Questions:

1. On a virtual machine, I can of course just revert to a previous snapshot — but, what if this were my live system? How would I get back into my system?
2. What do the new Grub options mean, and why are there two Grub menus, one of which requires Esc to get to?

[rubi1200]

Some basic questions:

1. did you choose erase and install on entire disk or some other option?
2. were you offered a choice whether to use GRUB or secure-boot at any point during the install?
3. did you change Vbox settings to boot from the hard drive first, rather than the floppy or optical? Yes, it sounds rather basic but I made that mistake once and got stuck in a loop

[paddylandau]

1. Erase and install on the entire disk. There was nothing else on the disk anyway beforehand.
2. I was offered Secure Boot, which I accepted (if I remember correctly, it was a checkbox). As my memory is a bit faint, I’ll run through the installation again if it’s important — let me know if you want me to do this.
3. It’s definitely booting from the virtual hard drive. After installing Ubuntu, I removed the virtual Live USB (the ISO) from the virtual machine and indeed from VirtualBox itself. I have just double-checked to ensure that this is the case.

I should state, because I realise that I didn’t make it clear, that I had successfully booted into the system. This problem arose only after I changed /etc/default/grub, ran sudo update-grub, and rebooted.

[peterwhite23]

@paddylandau

I should state, because I realise that I didn’t make it clear, that I had successfully booted into the system. This problem arose only after I changed /etc/default/grub, ran sudo update-grub, and rebooted.

I suspect that resulted in an effectively empty menu, except for the UEFI option. Can you rewind to a snapshot prior to this change? Then do exactly the same, show the output of update-grub and the menu section of /boot/grub/grub.cfg. On a side note, it’s probably best to leave /etc/default/grub alone an put drop-ins in /etc/default/grub.d/.

As for the two GRUB menus, I think that’s due to the two-stage boot with secure boot. At least that’s what I gathered from this:

@mkukri

You see with an encrypted /boot, as an attacker with disk access I can just as easily modify your ESP where your GRUB lives and modify GRUB’s initial bootstrap configuration (on the ESP) …

(emphasis added)
That bootstrap grub.cfg is in /boot/efi/EFI/ubuntu/ on my 24.04 installation.

[ogra]

@paddylandau

This problem arose only after I changed /etc/default/grub, ran sudo update-grub, and rebooted.

I’m, pretty sure this is not supported at all, the grub.cfg file that update-grub would create is actually not used here, the config comes from the gadget snap which is read-only (there should be something under /snap/pc/current on the system)

If you could tinker with the bootloader you could also attempt to circumvent the secure boot → Full Disk Encryption chain by manipulating bootloader behavior

EDIT: here is the doc describing the thing:

System options

[ogra]

Please file a bug against the grub2-common package, I just had an internal discussion and it has been agreed that update-grub should have operated as a no-op here (and probably print something telling you that it can not be used in such a setup) … This should be fixed before the 1. release of 26.04 (and THANKS !!! for finding this oddity !)

[paddylandau]

@peterwhite23

Can you rewind to a snapshot prior to this change? Then do exactly the same…

Reading the following comments, it seems that I should not have done it at all! I’ll revert to the previous snapshot.

@ogra

I’m, pretty sure this is not supported at all, the grub.cfg file that update-grub would create is actually not used here, the config comes from the gadget snap

I was blissfully unaware of this. Thank you for the link — that’s refreshing, because it answers an unrelated question of mine regarding security.

@ogra

Please file a bug against the grub2-common package, I just had an internal discussion and it has been agreed that update-grub should have operated as a no-op here

I’ll document everything carefully and raise a bug report. I presume that I raise it as a normal Launchpad bug report.

Once done, I’ll post the bug link here. It might take me several hours to get to it.

[peterwhite23]

@ogra

If you could tinker with the bootloader you could also attempt to circumvent the secure boot → Full Disk Encryption chain by manipulating bootloader behavior

What about GRUB’s menu editor, which one can reach by pressing e while the menu is displayed? Is that disabled for the FDE/TPM case? I mused about it in the SB thread. If it’s disabled, how can a user fix a mistake? For instance, a syntax error in grub.cfg; never forget to escape ; in a boot parameter – found that out the hard way. I don’t quite remember if the system actually failed to boot, though, but that’s my greatest fear with this GRUB lockdown; me doing something silly and only realizing it at the boot prompt, with no way to fix it.

OTOH, if the editor is still available, doesn’t that render the lockdown measures, which prevent grub.cfg manipulations at system runtime, moot?

[ogra]

@peterwhite23

If it’s disabled, how can a user fix a mistake? For instance, a syntax error in grub.cfg

How would that error get there in the first place, the file in use is read only (if the provided grub.cfg would have an error the install would have failed)

I can’t really tell anything about the editor though (I’m just a user on that level and not involved in the implementation (though I created an early prototype several years ago but the production implementation has changed completely from that) and I also have never used it outside of Ubuntu Core yet) you should probably bump that question again in the other thread if nobody answered yet…

[peterwhite23]

@ogra

How would that error get there in the first place, the file in use is read only (if the provided grub.cfg would have an error the install would have failed)

This looks like a candidate: snap set system system.kernel.dangerous-cmdline-append=”opt1=val1 opt2=val2”. I don’t know how much checking goes into the values of the parameters; I reckon only the parameter names are whitelisted in the non-dangerous variant, but looks like “dangerous” hands me all ammo I need.

@ogra

you should probably bump that question again in the other thread if nobody answered yet…

I’ll think about it.

[peterwhite23]

@peterwhite23

I don’t quite remember if the system actually failed to boot, though

In that particular case, the answer is no, the system eventually booted. But I was able to get a kernel panic just now with these:

sudo tee /etc/default/grub.d/silly_me.cfg >/dev/null <<'EOF'
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT thp_anon=16K-32K:always\;64K-2M:inherit; set root=foo"
EOF
sudo update-grub

The equivalent snap command would probably be:

snap set system system.kernel.dangerous-cmdline-append="thp_anon=16K-32K:always\;64K-2M:inherit; set root=foo"

That first escaped ; in the thp_anon parameter shows that I’ve learned from my mistake, the second ; is to demonstrate how to send the kernel into a panic on boot, because that ends the current grub command, everything after is considered the next grub command. Of course, no sane user would ever do that, but it shows that one can render the system unbootable. I couldn’t come up with a legitimate kernel parameter to do it so I directed grub to the wrong root; which in GRUB’s case is actually /boot. But I just now realized that this will work too:

snap set system system.kernel.dangerous-cmdline-append="root=/paht/ot/tyop"

Still a bit concocted but it’s a legit boot parameter; just the wrong value (that’s supposed to show a typo).

---

But I guess I should acutally raise that question in the other topic.

[paddylandau]

@ogra, I have reported the bug here:

Bug #2157702 “Amending Grub on 26.04 breaks boot, with no way to...” : Bugs :...

Thank you for having attended to this. I’ve learned a little about the new way of using Grub.