That menu is a little different from VirtualBox’s one.
Snapshots are wonderful! I always take a snapshot after powering down a working VM. Every time.
That menu is a little different from VirtualBox’s one.
Snapshots are wonderful! I always take a snapshot after powering down a working VM. Every time.
Eureka!
So there’s good news and bad news. The good news is that I was able to reproduce the boot loop and found out how to recover from it. I’ve also found out how to specify custom kernel command line parameters in grubenv.
The bad news is, altering grubenv this way, without authorizing its new hash with the TPM, renders TPM-backed FDE useless – one has to enter the recovery key on every boot.
I also have a correction to make:
Apparently I wasn’t quite thinking straight anymore, when writing that. The file I (must have) altered was /boot/grub/grubenv.
The reason for the boot loop turned out to be rather pedestrian. I watched the text splash more closely and saw that there was an error message complaining that grubenv wasn’t exactly 1024 bytes in size, but 1025 — this was with the “restored” file. That’s when it clicked. While diffing the original against some other candidates — on the seed partition, because I was still thinking I had altered the one there — I had noticed a warning that all of them had no newline character at the end. But I edited the file with Vim, which added the “missing” newline; can’t have that, right? So after sudo truncate -s 1K grubenv I am now finally able to boot with the restored file and the TPM reveals the FDE key.
@paddylandau, if you want to boot with custom parameters[1], make a backup — sudo cp -f --backup=t /boot/grub/grubenv{,} — and add them to snap_full_cmdline_args in /boot/grub/grubenv:
# GRUB Environment Block
kernel_status=
snapd_extra_cmdline_args=
snapd_full_cmdline_args=console=ttyS0,115200n8 console=tty1 panic=-1 quiet splash snapd.xkb="us,pc86,altgr-intl,caps:ctrl_modifier,ctrl:nocaps,shift:both_capslock_cancel"
###################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################
Then run sudo truncate -s 1K /boot/grubenv.
somewhat pointless with TPM measurements being invalidated ↩︎
Well discovered, Peter! Thank you.
This means that after I have installed the Ubuntu system on my laptop, I have to change the file via the Live USB before I restart.
Small correction: /boot/grub/grubenv.
This is brilliant, Peter, thank you!
This will do as a workaround until such a time as the bugs are fixed.
We should notify @ogra Oliver.
Hmm, thinking about this
What’s going to happen when the kernel is next updated?
One more reply. Unfortunately, it won’t work as a workaround, because as you said:
I thought that I’d be able to fix this using one of the existing methods (snap-tpmctl, systemd-cryptenroll), but, alas, I was unable to.
(Very sad face
)
To manage the grubenv file you use the tool created for this - grub-editenv, not a normal editor. grubenv is not a text file.
FAICT it is not possible to permanently set custom options at all. It is not possible to set only dangerous options because pc gadget grade is signed; and it is not possible to set non-dangerous options because no options are allowed in the gadget.yaml:
bor@resolute:~$ cat /snap/pc/220/meta/gadget.yaml
kernel-cmdline:
append:
- quiet
- splash
volumes:
...
That’s surely a major omission? I’m hardly the only person who has to use a GRUB option to get around a hardware limitation — many people need this in order to be able to use Linux.
Up until you opened this thread, I’d have thought most anything can be set otherwise at boot/run time, e.g. via sysctl and sysfs. But the IOMMU must be disabled on the command line or in the UEFI.
Is there really no knob in the UEFI settings to disable virtualization features? Perhaps it’s just hidden in an advanced menu (CtrlS)? Apparently, some models have one.
No workee
:
peter@Ubuntu-26-04-VM ~ % sudo grub-editenv /boot/grub/grubenv set snapd_full_cmdline_args='console=ttyS0,115200n8 console=tty1 panic=-1 quiet splash snapd.xkb="us,pc86,altgr-intl,caps:ctrl_modifier,ctrl:nocaps,shift:both_capslock_cancel" intel_iommu=off'
grub-editenv: error: environment block too small.
1 peter@Ubuntu-26-04-VM ~ % sudo grub-editenv /boot/grub/grubenv set snapd_full_cmdline_args='console=ttyS0,115200n8 console=tty1 panic=-1 quiet splash snapd.xkb="us,pc86,altgr-intl,caps:ctrl_modifier,ctrl:nocaps,shift:both_capslock_cancel"'
peter@Ubuntu-26-04-VM ~ %
The second command sets it to the original value, which I copied before.
I didn’t even think to look up what IOMMU meant — it worked, and that was all that I cared about!
I’ve looked it up now, and it’s the “input–output memory management unit.”
It doesn’t seem to have anything to do with virtualisation features. To quote Wikipedia, “the IOMMU maps device-visible virtual addresses (also called device addresses or memory mapped I/O addresses in this context) to physical addresses.” I know that it uses the phrase “virtual addresses,” but that seems to be for enhanced CPU access and (for later models) enhanced security, not specifically for virtualisation.
In any case, there’s nothing relevant in the BIOS that I can find in my 11-year-old laptop. Here’s a list of the BIOS menus and contents:
| Field | Value |
|---|---|
| CPU Type | Intel(R) Core™ i3-5005U CPU @ 2.00GHz |
| CPU Speed | 2.00GHz |
| System BIOS Version | V1.37 |
| GOP Version | Intel(R) GOP Driver [5.5.1028] |
| HDD Model Name | ST2000LM003 HN-M201RAD |
| HDD Serial Number | redacted |
| ATAPI Model Name | Slimtype DVD A DA8A6SH |
| Total Memory | 8192 MB |
| Serial Number | redacted |
| Asset Tag Number | |
| Product Name | Aspire F5-571 |
| Manufacturer Name | Acer |
| UUID | redacted |
| Field | Value |
|---|---|
| System Time | 17:10:07 |
| System Date | 07/12/2026 |
| Network Boot | [Disabled] |
| F12 Boot Menu | [Enabled] |
| Wake on LAN | [Disabled] |
| Touchpad | [Advanced] |
| Lid Open Resume | [Enabled] |
| D2D Recovery | [Enabled] |
| GPT Partition Recovery | [None] |
| GPT Partition Record | No Record |
| Field | Value |
|---|---|
| Supervisor Password Is | Set |
| User Password Is | Clear |
| HDD Password Is | Frozen |
| Set Supervisor Password | [Enter] |
| Set User Password | [Enter] |
| Set HDD Password | [Enter] |
| Password on Boot | [Disabled] |
| Secure Boot Mode | Custom |
| Erase all Secure Boot Setting | [Enter] |
| Select an UEFI file as trusted for executing | [Enter] |
| Restore Secure Boot to Factory Default | [Enter] |
| Current TPM (TCM) State | Enabled |
| Change TPM (TCM) State | [Enabled] |
| Clear TPM (TCM) | [Clear] |
| Field | Value |
|---|---|
| Boot Mode | [UEFI] |
| Secure Boot | [Enabled] |
| Boot priority order: | |
| 1. EFI File Boot 1 | Ubuntushim |
| 2. EFI File Boot 2 | Ubuntugrub |
| 3. HDD | ST2000LM003 HN-M201RAD |
| 4. ATAPI CDROM | Slimtype DVD A DA8A6SH |
| 5. USB FDD | |
| 6. Network Boot-IPV4 | |
| 7. USB HDD | |
| 8. USB CDROM | |
| 9. Network Boot-IPV6 | |
| 10. EFI File Boot 0 | Ubuntummx |
None of those, as far as I can tell, has anything to do with the input–output memory management unit.
Works here.
bor@resolute:~$ sudo grub-editenv /boot/grub/grubenv set snapd_full_cmdline_args='console=ttyS0,115200n8 console=tty1 panic=-1 quiet splash snapd.xkb="us,pc86,altgr-intl,caps:ctrl_modifier,ctrl:nocaps,shift:both_capslock_cancel" intel_iommu=off'
[sudo: authenticate] Password:
bor@resolute:~$ grub-editenv - list
grub-editenv: warning: disk does not exist, so falling back to partition device /dev/sda3.
grub-editenv: warning: disk does not exist, so falling back to partition device /dev/sda3.
grub-editenv: warning: disk does not exist, so falling back to partition device /dev/sda3.
grub-editenv: warning: cannot open device hostdisk//dev/sda3: disk `hostdisk//dev/sda3' not found.
kernel_status=
snapd_extra_cmdline_args=
snapd_full_cmdline_args=console=ttyS0,115200n8 console=tty1 panic=-1 quiet splash snapd.xkb="us,pc86,altgr-intl,caps:ctrl_modifier,ctrl:nocaps,shift:both_capslock_cancel" intel_iommu=off
bor@resolute:~$
Could be fallout of your attempts to edit this file.
Indeed. I reverted to the state just after the installation and it worked. Sadly though, it doesn’t change much, because I still had to enter my recovery key on two consecutive boots. Usually it’s only once, in case some update to the expected measurements is performed. Apparently, that’s not the case for the manually edited kernel command line.
BTW, it can’t be the file that’s measured, because I set $snapd_extra_cmdline_args and that didn’t change a thing, including not being asked for the recovery key, since the command line didn’t change. Don’t what that variable is for; perhaps those are snap arguments?
I also experimented with this! I can’t find a definitive explanation of this. All that I can find is the comment (unsubstantiated) that if you change it, future updates will undo your changes.
And why did you expect it to do anything?
set cmdline_args="$snapd_static_cmdline_args $snapd_extra_cmdline_args"
if [ -n "$snapd_full_cmdline_args" ]; then
set cmdline_args="$snapd_full_cmdline_args"
fi
and snapd_full_cmdline_args is set.
Just read grub.cfg.
That’s a really unhelpful and unfair reply. Not everyone here is a programmer, or would even know where to look if they were.
What we need is clear and easy-to-find documentation. That’s not an unreasonable request. I realise that the devs are extremely busy, and so I fully understand if the documentation isn’t complete; that’s fair. That’s why we have support forums, to help those who need documentation that is unavailable or hard to find.
That looks more like somebody wanted the first line to read:
set snapd_full_cmdline_args="$snapd_static_cmdline_args $snapd_extra_cmdline_args"
Because, why have a variable that says extra only to then ignore it? The way they are named suggests that $snapd_full_cmdline_args includes $snapd_extra_cmdline_args.
Or perhaps the whole thing should read:
set cmdline_args="$snapd_static_cmdline_args $snapd_extra_cmdline_args"
if [ -n "$snapd_full_cmdline_args" ]; then
set cmdline_args="$snapd_full_cmdline_args $cmdline_args"
fi
That indeed makes sense, Peter, and if you’re right, it could be simplified further without bothering with the if statement:
set cmdline_args="$snapd_full_cmdline_args $snapd_static_cmdline_args $snapd_extra_cmdline_args"
Regardless, this needs to be reported as a bug, otherwise a lot of people (including me) won’t be able to use TPM-backed FDE.
Here’s the bug report. Please vote for it if it affects you.
@ogra — Oliver, now that some time has passed, what are the chances of the fwupd bug and the GRUB bug being fixed by the 26.04.1 release (also in Ubuntu Core 26)?
If they aren’t both fixed, I won’t be able to use Desktop 26.04 for laptop and desktop, or Core 26 for my server.
I at least have a workaround: I’ve been testing Clevis, and it works on both Desktop 26.04 and Server 26.04. It’s not ideal — it’s not as secure as the full method — but it will do.