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.
But hey, that’s how I’ve learnt the most – pushing the red button, when it presented itself.
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. ![]()