Only memtest and UEFI settings in GRUB menu

Support and Help
,
1

Ubuntu Support Template

Ubuntu Version:
26.04

Problem Description:
The system fails to boot from the first GRUB stage, apparently, due to a missing luks2 module. After that I am dropped into a grub menu with only memtest and UEFI FW settings.

Relevant System Information:
TPM-backed full disk encryption (FDE/TPM) is enabled, which seems to be the most relevant system info.

Screenshots or Error Messages:

image
image1920×1080 8.99 KB

Looks like the LUKS2 module went AWOL. :exclamation_question_mark: :confused:

image
image1920×1080 11.6 KB

Only Memtest and UEFI FW settings.

Journal of last successful boot

Backstory
This is my toy VM, which I’ve set up to evaluate FDE/TPM. I’ve also recently abused it to see how low one could go with available RAM and still get a live session, so I accidentally booted the installed system with only 2 GiB of RAM, which did work at first. But after some hours of it sitting idle on a different desktop workspace — had all but forgotten that it was still running — it seemed to be stuck: high CPU load, black screen, no response. I was able to get a login on the TTY3 (CtrlAltF3) but even that session behaved erratic. I was able to run journalctl to see that snapd was failing repeatedly, but after exiting the pager, the cursor was gone and no keyboard echo. I was able to reset the console, but that only lasted to the next pager invocation. At some point I saw in virt-manager that the available memory was still set to 2 GiB.

I then decided to see what happens after a reboot, expecting it to fail, but, to my surprise, it did not; no obvious errors. The VM had been rebooted a couple of times until it failed just now. After going through the last boot log from a live session, I’ve found this:

Jul 08 10:13:47 Ubuntu-2604-VM sudo[22640]: peter : TTY=/dev/pts/3 ; PWD=/home/peter ; USER=root ; COMMAND=/usr/bin/apt reinstall alsa-topology-conf memtest86+

Because of said (near) OOM mentioned earlier, I decided to do a debsums run, found alsa-topology-conf and memtest86+ were missing files and hence reinstalled them. So I’ve got the feeling that this is just another manifestation of this bug. But this time, I just reinstalled a package (memtest86+), which must have triggered update-grub.

What I’ve Tried:
Even though I knew better, I tried to use the recovery desktop, but didn’t get past the recovery key prompt; it refused my recovery key, which I entered and double checked against the cleartext echo; 3 attempts, 3 failures. But that only seems to be a different manifestation of the bug.

Since the topic on the update-grub bug closed after @paddy had solved it by reporting the bug and there being no decision on how to fix it, is there any way for me to recover from this manually? If this were a “classic” (non-snap) boot scenario, I would just chroot into the target system, run update-grub and all would be fine, but what’s the equivalent, if any, for the snappified FDE/TPM setup?

1 Like
2

My bet would be that the memtest package actually calls update-grub from its postinst or a hook/trigger, I doubt there is an easy way out of that state though …

In the update-grub bug I think the agreement was to divert the command altogether so it becomes a no-op, but I don’t think anything has happened in the archive for it yet

1 Like
3

Oh, looks like I am able to use the text console to login. I remembered that Virtual Machine Manager (VMM) offered a serial console connection, opened it and found the familiar TTY login prompt. Oddly enough, the “Ubuntu Core” boot splash keeps spinning the spinner and says “Starting recovery system…” on the virt-viewer display all the while.

Does that increase my chances of fixing this manually, @ogra? I’m really one for fixing problems, rather than nuking them. :toolbox: :slight_smile:

But I’m also curious, why the desktop won’t come up. systemctl status graphical.target says it’s running, though.

BTW, I now know what causes this:

Apparently, @paddylandau’s Virtualbox setup does not include/enable a serial console; toyed with some VMM settings and, in the process, accidentally deleted the respective serial device. After that the newly booted VM kept spamming its journal with that message.

4

As the bug hasn’t been confirmed by anyone, I rather suspect that nothing will come of it.

I am puzzled by this. Why should a modern computer require a serial console? They haven’t been used in decades, have they? Unless you simply mean having a console, which VirtualBox provides for every machine — I can always access a console, even if it’s unusable (as in the case for Ubuntu Core) unless accessing the virtual BIOS or GRUB.

1 Like
5

Julian is the grub maintainer and I think he has a plan since he re-assigned it to his boot-managed-by-snapd package already … (for stonking it will simply conflict with grub-common as I understand, for resolute there will be a diversion added in grub-common to make the script a no-op)

3 Likes
6

Peter, I’ve just tested your apt reinstall, and I confirm that I have the same result.

You can reboot the computer, and press Esc to get to the normal GRUB. Then you can choose the recovery option. But, of course, you then get this bug, leaving it still inoperable.

I’ll leave a note on the bug report so that the devs are aware.

7

Oops, I knew I had forgotten something. Thanks for the reminder; I’ve hit the button and posted a brief comment.

They are a great debugging tool, as has been shown by this very episode.

Or, so you thought. :wink:

No, it’s a separate device; I have virt-viewer for the “Graphical Console”, and I can simultaneously connect to said serial console, which only supports text mode, whereas the former can double as both. In your case, since there was no other (primary) console for the error messages, they had to be sent to the one on which you were logged in.

It’s only unusable insofar as the failures to connect the service to the serial device interfere with your user input/output.

1 Like
8

No, I don’t; at least I can actually use the console without hiccups. That’s what I was trying to convey between the lines. You either need to stop that service, which should stop it from spamming your login console; but that can be hard to do when the keyboard responds erratically, I’d imagine. Or you need to add a serial (console) device to your VM to satisfy its hardware dependency.

image
image1920×1080 140 KB

But technically, that’s not a desktop, so something is still not quite right. However, given the right instructions, I’m sure I can get it to work from here.

9

They are used pretty much daily in the server space (i.e. to maintain bigger server farms through serial style kvm switches and such…) they are also rather the default way of logging in to industrial and IoT systems. On desktop they are used rarely nowadays, that is indeed correct.

2 Likes
10

Only because you did manually set a local password though, the default is to only allow ssh login with your key from SSO … (well, the actual default in production systems is to actually not have a user at all (one less attack vector) and use some agent snap for fleet management like the landscape-client snap)

11

No, this is the Desktop with TPM-backed FDE. :wink:

But the recovery “desktop” turned out to be a TTY. :grin:

12

The MOTD is clearly UbuntuCore… weird, are you sure you booted the right VM ?

(There is also no console-conf service on desktop normally (that is the setup wizard for core to set up network and the SSO account), you’d have to explicitly install the console-conf snap to even get it on a desktop, there is nothing that would seed it there)

13

Yes, I am 1000% positive that it’s the Desktop. The branding of the boot splash switches half way through; I think after the TPM releases the key, because before, when I was stuck in the recovery key prompt, it still had the Desktop splash at that point. But I had left the ISO live installer enabled in the boot order, which caused the measurements to fail. After I fixed that, the TPM released the key even in recovery mode.

I am not really sure, I follow. Are you saying, I shouldn’t be seeing the console I’m seeing? snap list does not list console-conf. I just thought there is a bug in the boot procedure for the recovery desktop. But perhaps this only happens with VM’s?

14

Your systemctl output lists console-conf@tty1.service … that is only provided by the console-conf snap (or in older UC releases (prior to UC24) by the base snap)

There is also no core splash in the desktop initrd so if you see a core splash something clearly switched you over to a core rootfs…

15

Well, what can I say? I sure didn’t put it there. :slight_smile:

Here is some more output:

peter@localhost:~$ snap info console-conf
^C
peter@localhost:~$ snap list
Name       Version      Rev    Tracking              Publisher   Notes
core24     20260317     1587   latest/stable         canonical✓  base
pc         26.04-1      220    classic-26.04/stable  canonical✓  gadget
pc-kernel  7.0.0-14.14  3390   26.04/stable          canonical✓  kernel
snapd      2.75.2       26865  latest/stable         canonical✓  snapd
peter@localhost:~$

Had to abort the first command, because network isn’t set up.

BTW, shouldn’t I be able to just write the correct menu entry manually? AFAICT, only the grub menu is botched, which doesn’t even qualify as a flesh wound. :grin: What would I have to put in grub.cfg?

16

Check your mount output I have the suspicion you actually booted into the core24 snap as rootfs (with /writable as the overlay for writable pieces)…

Can you sudo touch /bin/foo ? Or is it read only ?

17 
peter@localhost:~$ sudo touch /bin/foo
[sudo] password for peter: 
touch: cannot touch '/bin/foo': Read-only file system

I have triple checked that no Ubuntu Core storage device is involved. If you want, you can check the VM’s XML config. It’s pretty basic, really. I added a new VM and VMM selected the linux2024 template. Had to manually enable UEFI/TPM/SB by copy/pasting the example XML from the libvirt docs. In the meantime I’ve added a virtio (serial) console, for whatever that’s worth. I can assure you that this VM has never seen an Ubuntu Core image.

Apart from the serial console issue, @paddylandau seems to see exactly the same behavior, i.e. no desktop but a TTY login is possible. Something is wrong.

VM config 
<domain type="kvm">
  <name>Ubuntu_Desktop_26.04</name>
  <uuid>b0ef2cd1-a37c-42df-b2ef-f2aa05e12d76</uuid>
  <title>Ubuntu Desktop 26.04</title>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://libosinfo.org/linux/2024"/>
    </libosinfo:libosinfo>
  </metadata>
  <memory unit="KiB">8388608</memory>
  <currentMemory unit="KiB">6291456</currentMemory>
  <memoryBacking>
    <source type="memfd"/>
    <access mode="shared"/>
  </memoryBacking>
  <vcpu placement="static">4</vcpu>
  <cputune>
    <emulatorpin cpuset="0-4"/>
  </cputune>
  <os firmware="efi">
    <type arch="x86_64" machine="pc-q35-noble">hvm</type>
    <firmware>
      <feature enabled="yes" name="enrolled-keys"/>
      <feature enabled="yes" name="secure-boot"/>
    </firmware>
    <loader readonly="yes" secure="yes" type="pflash">/usr/share/OVMF/OVMF_CODE_4M.ms.fd</loader>
    <nvram template="/usr/share/OVMF/OVMF_VARS_4M.ms.fd">/var/lib/libvirt/qemu/nvram/linux2024_VARS.fd</nvram>
  </os>
  <features>
    <acpi/>
    <apic/>
    <vmport state="off"/>
    <smm state="on"/>
  </features>
  <cpu mode="host-passthrough" check="none" migratable="on"/>
  <clock offset="utc">
    <timer name="rtc" tickpolicy="catchup"/>
    <timer name="pit" tickpolicy="delay"/>
    <timer name="hpet" present="no"/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <pm>
    <suspend-to-mem enabled="no"/>
    <suspend-to-disk enabled="no"/>
  </pm>
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type="file" device="cdrom">
      <driver name="qemu" type="raw"/>
      <source file="/home/peter/Downloads/ubuntu-26.04-desktop-amd64.iso"/>
      <target dev="sda" bus="sata"/>
      <readonly/>
      <address type="drive" controller="0" bus="0" target="0" unit="0"/>
    </disk>
    <disk type="file" device="disk">
      <driver name="qemu" type="qcow2" cache="writeback"/>
      <source file="/var/lib/libvirt/images/ubuntu.qcow2"/>
      <target dev="sdb" bus="sata"/>
      <boot order="1"/>
      <address type="drive" controller="0" bus="0" target="0" unit="1"/>
    </disk>
    <controller type="usb" index="0" model="qemu-xhci" ports="15">
      <address type="pci" domain="0x0000" bus="0x02" slot="0x00" function="0x0"/>
    </controller>
    <controller type="pci" index="0" model="pcie-root"/>
    <controller type="pci" index="1" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="1" port="0x10"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x0" multifunction="on"/>
    </controller>
    <controller type="pci" index="2" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="2" port="0x11"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x1"/>
    </controller>
    <controller type="pci" index="3" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="3" port="0x12"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x2"/>
    </controller>
    <controller type="pci" index="4" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="4" port="0x13"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x3"/>
    </controller>
    <controller type="pci" index="5" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="5" port="0x14"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x4"/>
    </controller>
    <controller type="pci" index="6" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="6" port="0x15"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x5"/>
    </controller>
    <controller type="pci" index="7" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="7" port="0x16"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x6"/>
    </controller>
    <controller type="pci" index="8" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="8" port="0x17"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x7"/>
    </controller>
    <controller type="pci" index="9" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="9" port="0x18"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x0" multifunction="on"/>
    </controller>
    <controller type="pci" index="10" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="10" port="0x19"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x1"/>
    </controller>
    <controller type="pci" index="11" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="11" port="0x1a"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x2"/>
    </controller>
    <controller type="pci" index="12" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="12" port="0x1b"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x3"/>
    </controller>
    <controller type="pci" index="13" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="13" port="0x1c"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x4"/>
    </controller>
    <controller type="pci" index="14" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="14" port="0x1d"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x5"/>
    </controller>
    <controller type="pci" index="15" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="15" port="0x1e"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x6"/>
    </controller>
    <controller type="pci" index="16" model="pcie-to-pci-bridge">
      <model name="pcie-pci-bridge"/>
      <address type="pci" domain="0x0000" bus="0x08" slot="0x00" function="0x0"/>
    </controller>
    <controller type="sata" index="0">
      <address type="pci" domain="0x0000" bus="0x00" slot="0x1f" function="0x2"/>
    </controller>
    <controller type="virtio-serial" index="0">
      <address type="pci" domain="0x0000" bus="0x03" slot="0x00" function="0x0"/>
    </controller>
    <controller type="scsi" index="0" model="virtio-scsi">
      <address type="pci" domain="0x0000" bus="0x06" slot="0x00" function="0x0"/>
    </controller>
    <filesystem type="mount" accessmode="passthrough">
      <driver type="virtiofs"/>
      <source dir="/home/peter/VM/shared"/>
      <target dir="host_shared"/>
      <address type="pci" domain="0x0000" bus="0x07" slot="0x00" function="0x0"/>
    </filesystem>
    <interface type="network">
      <mac address="52:54:00:25:5c:b6"/>
      <source network="default"/>
      <model type="virtio"/>
      <address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
    </interface>
    <serial type="pty">
      <target type="isa-serial" port="0">
        <model name="isa-serial"/>
      </target>
    </serial>
    <console type="pty">
      <target type="serial" port="0"/>
    </console>
    <console type="pty">
      <target type="virtio" port="1"/>
    </console>
    <channel type="spicevmc">
      <target type="virtio" name="com.redhat.spice.0"/>
      <address type="virtio-serial" controller="0" bus="0" port="1"/>
    </channel>
    <input type="tablet" bus="usb">
      <address type="usb" bus="0" port="1"/>
    </input>
    <input type="mouse" bus="ps2"/>
    <input type="keyboard" bus="ps2"/>
    <input type="keyboard" bus="virtio">
      <address type="pci" domain="0x0000" bus="0x09" slot="0x00" function="0x0"/>
    </input>
    <input type="tablet" bus="virtio">
      <address type="pci" domain="0x0000" bus="0x0a" slot="0x00" function="0x0"/>
    </input>
    <tpm model="tpm-tis">
      <backend type="emulator" version="2.0"/>
    </tpm>
    <graphics type="spice">
      <listen type="none"/>
      <image compression="auto_lz"/>
      <jpeg compression="auto"/>
      <zlib compression="auto"/>
      <playback compression="on"/>
      <streaming mode="filter"/>
      <gl enable="yes" rendernode="/dev/dri/renderD128"/>
    </graphics>
    <sound model="ich9">
      <address type="pci" domain="0x0000" bus="0x00" slot="0x1b" function="0x0"/>
    </sound>
    <audio id="1" type="spice"/>
    <video>
      <model type="virtio" heads="1" primary="yes">
        <acceleration accel3d="yes"/>
      </model>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x0"/>
    </video>
    <redirdev bus="usb" type="spicevmc">
      <address type="usb" bus="0" port="2"/>
    </redirdev>
    <redirdev bus="usb" type="spicevmc">
      <address type="usb" bus="0" port="3"/>
    </redirdev>
    <watchdog model="itco" action="reset"/>
    <memballoon model="virtio">
      <address type="pci" domain="0x0000" bus="0x04" slot="0x00" function="0x0"/>
    </memballoon>
    <rng model="virtio">
      <backend model="random">/dev/urandom</backend>
      <address type="pci" domain="0x0000" bus="0x05" slot="0x00" function="0x0"/>
    </rng>
  </devices>
</domain>
mount output 
peter@localhost:~$ mount
tmpfs on /run type tmpfs (rw,nosuid,nodev,size=1591376k,nr_inodes=819200,mode=755,inode64)
/dev/sda2 on /run/mnt/ubuntu-seed type vfat (rw,nosuid,nodev,noexec,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/run/mnt/ubuntu-seed/snaps/pc-kernel_3390.snap on /run/mnt/kernel type squashfs (ro,relatime,errors=continue,threads=single)
/run/mnt/ubuntu-seed/snaps/core24_1587.snap on /run/mnt/base type squashfs (ro,relatime,errors=continue,threads=single)
/run/mnt/ubuntu-seed/snaps/pc_220.snap on /run/mnt/gadget type squashfs (ro,relatime,errors=continue,threads=single)
tmpfs on /run/mnt/data type tmpfs (rw,nosuid,relatime,inode64)
/dev/sda3 on /run/mnt/ubuntu-boot type ext4 (rw,relatime)
/dev/mapper/ubuntu-data-4f6b9629-0918-4466-aa9d-ca8c5d105fe9 on /run/mnt/host/ubuntu-data type ext4 (rw,nosuid,relatime)
/dev/mapper/ubuntu-save-6fbd1b9b-80b5-4976-9683-6421930ffd20 on /run/mnt/ubuntu-save type ext4 (rw,nosuid,nodev,noexec,relatime)
/run/mnt/ubuntu-seed/snaps/core24_1587.snap on / type squashfs (ro,relatime,errors=continue,threads=single)
tmpfs on /writable type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /etc/writable type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /etc/dbus-1 type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /etc/hosts type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /etc/iproute2 type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /etc/modprobe.d type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /etc/modules-load.d type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /etc/netplan type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /etc/network/if-up.d type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /etc/ssh type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /etc/sudoers.d type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /etc/systemd type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /etc/udev/rules.d type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /etc/cloud type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /etc/sysctl.d type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /etc/default/swapfile type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /etc/environment type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /etc/machine-id type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /etc/motd.d type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /etc/update-motd.d type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /etc/security/pwquality.conf type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /etc/polkit-1/actions type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /etc/polkit-1/rules.d type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /etc/fstab type tmpfs (rw,nosuid,nodev,size=1591376k,nr_inodes=819200,mode=755,inode64)
tmpfs on /snap type tmpfs (rw,nosuid,relatime,inode64)
/run/mnt/ubuntu-seed/snaps/pc-kernel_3390.snap on /usr/lib/firmware type squashfs (ro,relatime,errors=continue,threads=single)
/run/mnt/ubuntu-seed/snaps/pc-kernel_3390.snap on /usr/lib/modules type squashfs (ro,relatime,errors=continue,threads=single)
tmpfs on /var/snap type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /var/lib/snapd type tmpfs (rw,nosuid,relatime,inode64)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=3424356k,nr_inodes=856089,mode=755,inode64)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,size=3978432k,nr_inodes=994608,inode64,usrquota)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=600,ptmxmode=000)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,nosuid,nodev,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot,memory_hugetlb_accounting)
none on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=24,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=7686)
tmpfs on /etc/group type tmpfs (rw,nosuid,nodev,size=1591376k,nr_inodes=819200,mode=755,inode64)
tmpfs on /etc/gshadow type tmpfs (rw,nosuid,nodev,size=1591376k,nr_inodes=819200,mode=755,inode64)
tmpfs on /etc/passwd type tmpfs (rw,nosuid,nodev,size=1591376k,nr_inodes=819200,mode=755,inode64)
tmpfs on /home type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /host type tmpfs (rw,nosuid,nodev,size=1591376k,nr_inodes=819200,mode=755,inode64)
/dev/mapper/ubuntu-data-4f6b9629-0918-4466-aa9d-ca8c5d105fe9 on /host/ubuntu-data type ext4 (rw,nosuid,relatime)
tmpfs on /etc/shadow type tmpfs (rw,nosuid,nodev,size=1591376k,nr_inodes=819200,mode=755,inode64)
tmpfs on /media type tmpfs (rw,relatime,inode64)
tmpfs on /mnt type tmpfs (rw,relatime,inode64)
tmpfs on /root type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /tmp type tmpfs (rw,relatime,inode64)
tmpfs on /var/cache/snapd type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /var/cache/apparmor type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /var/lib/cloud type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /var/lib/console-conf type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /var/lib/dbus type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /var/lib/dhcpcd type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /var/lib/extrausers type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /var/lib/private/systemd type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /var/lib/misc type tmpfs (rw,nosuid,relatime,inode64)
/dev/sda2 on /var/lib/snapd/seed type vfat (ro,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
tmpfs on /var/lib/sudo type tmpfs (rw,relatime,mode=700,inode64)
/dev/mapper/ubuntu-save-6fbd1b9b-80b5-4976-9683-6421930ffd20 on /var/lib/snapd/save type ext4 (rw,nosuid,nodev,noexec,relatime)
tmpfs on /var/lib/waagent type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /var/lib/systemd type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /var/log type tmpfs (rw,nosuid,relatime,inode64)
tmpfs on /var/tmp type tmpfs (rw,nosuid,relatime,inode64)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
/run/mnt/ubuntu-seed/snaps/snapd_26865.snap on /snap/snapd/26865 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide,x-gvfs-hide)
/run/mnt/ubuntu-seed/snaps/snapd_26865.snap on /usr/lib/snapd type squashfs (ro,nodev,relatime,errors=continue,threads=single)
/run/mnt/ubuntu-seed/snaps/core24_1587.snap on /snap/core24/1587 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide,x-gvfs-hide)
/run/mnt/ubuntu-seed/snaps/pc-kernel_3390.snap on /snap/pc-kernel/3390 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide,x-gvfs-hide)
/run/mnt/ubuntu-seed/snaps/pc_220.snap on /snap/pc/220 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide,x-gvfs-hide)
tmpfs on /run/snapd/ns type tmpfs (rw,nosuid,nodev,size=1591376k,nr_inodes=819200,mode=755,inode64)
nsfs on /run/snapd/ns/pc-kernel.mnt type nsfs (rw)
nsfs on /run/snapd/ns/pc.mnt type nsfs (rw)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=600920k,nr_inodes=150230,mode=700,uid=1000,gid=1000,inode64)
18

There we go, so you booted half an UbuntuCore on top of a desktop disk :joy: (which the read-only-ness of /bin already confirmed)

Fun galore… but after all this weirdness won’t happen anymore once the update-grub issue is solved

19

That’s on the Ubuntu Desktop/Core hybrid then; I had no part in it, wouldn’t even know how. When @paddylandau first reported the issue, I hadn’t even touched any Core images yet. I set up a (since nuked) Desktop FDE/TPM VM to reproduce the issue. As I said above, half-way through the recovery desktop boot, the splash changes to “Ubuntu Core” in rather huge letters:

image
image1920×1080 120 KB

(that’s spinning all the time while I’m using the serial console for the shell interaction)

Perhaps it’s a FrankenCore? Didn’t you say that Desktop FDE/TPM just reuses that part from UC?

20

ubuntu-grub overwrites /boot/grub/grub.cfg which on TPM2 FDE system is on the ubuntu-boot partition (bind-mounted on the /run/mnt/ubuntu-boot/EFI/ubuntu/). While it is possible to manually load the kernel from the ubuntu-boot partition I am not aware of any way to regenerate the grub.cfg post install, even though it is pretty static and I suspect is the same on every system. I had hoped that it is part of some snap, but I could not find it.

Well,

root@resolute:~# mount | grep core24
/var/lib/snapd/snaps/core24_1587.snap on /snap/core24/1587 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide,x-gvfs-hide)
/var/lib/snapd/snaps/core24_1643.snap on /snap/core24/1643 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide,x-gvfs-hide)
root@resolute:~#

This is fully booted Ubuntu desktop.

1 Like