How do I specify a GRUB option for Ubuntu 26.04?

Support and Help
, ,
1

Ubuntu Version: 26.04, using TPM-backed full-disk encryption (FDE)

Desktop Environment (if applicable): GNOME

Background:

My old laptop has slightly tricky hardware. Linux cannot identify or communicate with the TPM chip unless GRUB boot includes intel_iommu=off.

When booting the Live USB, or the installed version of prior versions, this was easy enough:

  1. Interrupt boot to get to GRUB.
  2. Press “e”.
  3. Add intel_iommu=off to the “linux” line.

Also, in the installed version of prior versions, you could edit /etc/default/grub.cfg to add the line, and update-grub to make it permanent.

For 26.04, this changes. The installed version can use:

snap set system system.kernel.dangerous-cmdline-append="intel_iommu=off"

The problem:

When Ubuntu 26.04 is installed, it needs to be started for the first time with intel_iommu=off. At this point, as the system hasn’t yet been started, it hasn’t been possible to set this up.

So, I need to interrupt GRUB when starting the system for the first time to tell it to add intel_iommu=off.

The problem is that GRUB for 26.04 is completely different, and I have no clue how to go about doing this.

So, that’s my question:

How do I interrupt GRUB on 26.04 to add intel_iommu=off to the boot process?

Relevant System Information:

Hardware: Acer Aspire F5

What I’ve Tried:

I have tried looking this up and using AI, but haven’t found a solution. I also can’t find the official documentation.

2

Not the answer to your question, more of a workaround, can you disable the IOMMU in the EFI menu?

3

Can’t you edit /boot/grub/grub.cfg before you reboot and insert that option in the menuentry linux line? (section 10 linux)?

4

Are you using TPM2 FDE? Because this is entirely different animal.

2 Likes
5

Here’s how you edit the (second stage) grub menu:

Just add your parameters after $cmdline_args and press Ctrlx or F10. This should have the side effect of the TPM measurements of the kernel command line being wrong and you will need to enter the recovery key.

BTW, that still doesn’t work.

$ cat /proc/cmdline 
snapd_recovery_mode=run console=ttyS0,115200n8 console=tty1 panic=-1 quiet splash snapd.xkb="us,pc105,altgr-intl,"
$ snap get system system.kernel.dangerous-cmdline-append
intel_iommu=off

That is just after I’ve rebooted. I’ve also tried the system.kernel.cmdline-append but that fails, probably because it’s not on the allow list, or because of the pc-gadget snap; I think it’s the latter.

1 Like
6

I don’t know. I haven’t even heard of such a thing. How would I go about doing this? Especially on a semi-immutable system, as 26.04 is (I forgot to mention that this is TPM-backed FDE).

I forgot to specify that this is TPM-backed FDE, so no, that wouldn’t work. Changing GRUB in the immutable system borks the system.

Yes. Sorry, I forgot to say this. I’ve edited my original post to say so.

Oh… That simple? Excellent.

Ugh, I forgot about that. This should be raised in a bug report. Otherwise I won’t be able to use my laptop with 26.04. That’s another task for tomorrow.

Ubuntu 26.04 has raised so many new problems. I hope that they’re fixed before the point-one release.

7

TPM or not shouldn’t matter at that stage. The easiest way to get to the (U)EFI settings is to select “UEFI firmware settings” from the first stage grub menu; press Esc as soon as you see the boot splash.

As for the UEFI menu itself, hard to tell; consult the manual. Perhaps there is a setting that’s explicitly named. If not, I’d try, in this order:

  1. disable VT-d (device passthrough), which is just another name for IOMMU, IIRC
  2. disable AMD-V or Intel VT-x, without which no VT-d, if there is no setting for the latter
  3. anything that looks like virtualization

Agreed, but it’s only with TPM-backed FDE. I guess, some kinks were to be expected. Perhaps there is a way to change the snap model grade to “dangerous”, @ogra? I’m having a hard time understanding all the snap stuff, so I don’t know if that is fixed at image creation time or if it can be changed at runtime.

1 Like
8

Ah, you mean what I think of as the BIOS, right? I’ve looked through all of the settings there, and there’s nothing that could be related to IOMMU, VT-d, etc. It’s a pretty simple menu. The laptop is old.

1 Like
9

Well here is described how the models work:

https://documentation.ubuntu.com/core/reference/assertions/model/#reference-assertions-model

On UbuntuCore we have a feature called “remodeling” that is usually used to switch from one release to another or change the snap store that is branded into the image, I doubt this will work on classic though (and you would most likely need a model signed by Canonical for this):

https://documentation.ubuntu.com/core/explanation/remodeling/

2 Likes
10

Except it has two bootloaders and you need to catch and edit the right one.

1 Like
11

BTW, have you tried booting without intel_iommu=off? Usually such settings are meant as a stopgap. Perhaps the newer kernel and/or a UEFI update fixed it in the meantime.

FWIW, I remembered @avb66 hint:

Thought I was clever, while doing:

sudo mount -o remount,rw /var/lib/snapd/seed
sudo editor /var/lib/snapd/seed/EFI/ubuntu/grubenv

I wasn’t. :frowning: Thought I’d save you from a boot loop.

1 Like
12

Maybe it was a bit too subtle, but I did point it out.

1 Like
13

The second one, right? That’s what I’ve been doing, anyway.

Yes, absolutely. I’ve tried a whole bunch of things, and this is the only one that works. Without it, I absolutely cannot communicate with the TPM chip.

Ha ha, what happened?

14

I am now stuck in a boot loop and haven’t yet figured out how to break it; undoing my changes from a live boot session seems to do nothing to fix it. I’m forever stuck in a loop. TPM and/or snap must be angry with me for even touching that file. I can enter my recovery key, alright, but soon after the machine just reboots. When I switch to text splash mode (Esc) I can catch a glimpse that a dependency of intrd-root-device.target failed emergency-reboot.service being started is the last line.

15

Oof, that sucks. I have little doubt that you’ve been hit by the GRUB modification bug and the GRUB repair bug. I believe that the two bugs are related.

You might have to back up your data via a Live USB, and reinstall.

16

No, that one is actually recoverable. It just took me a while to realize, because of tunnel vision on the the menu editor.

This time I have booted a live session pretty soon after realizing that the parameter wasn’t even set — echo $cmdline_args in the grub shell showed that my parameter wasn’t in there. So it had to be something to with the modified grubenv file; the partition being mounted read-only in a normal Desktop session was a bit of a red flag. :wink: But hey, that’s how I’ve learnt the most – pushing the red button, when it presented itself. :grin: It’s only a disposable VM, after all.

But all this goes to show that it’s pretty much impossible to circumvent the TPM/FDE protections and/or Secure Boot. I’ll put that in the pro column.

I am now pondering if I should try to cannibalize an Ubuntu Core image and get the seed partition from there. Any thoughts on that, @ogra? Or is there some way that I can get the pc-gadget snap to run from a live boot session; chrooted into ubuntu-data of the patient? That’s what’s preparing the boot files, e.g. grub.cfg and friends, right? But my previous attempts have failed; couldn’t start the snapd inside the (unlocked) data partition, because systemctl refused to run in the chroot.

Sorry, I’ve just realized, that this isn’t exactly on topic. :flushed_face:

2 Likes
17

Please continue. As you share, so I learn. It’s kind of related.

1 Like
18

Quick Update

So I decided to see if I can reproduce this boot loop on a fresh install, but the installer complained about Secure Boot being disabled; without which no TPM/FDE. I did disable it to see if I could break the boot loop that way, to no avail. So I re-enabled[1] it, only for the installer to now complain about some unexpected (pending?) TPM sysprep application:

image
image1012×732 79.3 KB

Not quite sure of the cause yet…

  1. not quite straightforward ↩︎

19

Is this still on a virtual machine? It seems that something is out of sync with the TPM chip.

In this case, it’s tempting to do the Windows thing: Power down your computer, wait a minute, and start up. Let me know what happens.

20

Yes, this is all still in the same VM. I have changed some settings, though. And I now know the cause of that message. Being tired of manually changing boot order, every time I wanted a live boot, I decided to enable the boot menu, which seems to be nothing more than a three seconds timeout, during which pressing Esc opens the regular UEFI menu. In there I opened Boot Manager and selected the DVD device, pressed Enter and the machine booted directly from the virtual DVD device. But, here’s the catch, apparently going through that Boot Manager kept it running somehow, hence the sysprep application error.

In case other stumble over this, here is how to do it the right way: UEFI Firmware Settings → Boot Maintenance Manager → Boot Next Value:

image
image1920×1080 58.7 KB

Save the setting (F10), go back to the main menu and select Reset. That way there is no sysprep app still running when the TPM check of the installer runs.

I am now waiting for the installer to complete. And this time I’ll take a snapshot. Reinstalling is getting old. :face_with_bags_under_eyes: