Bug #2063113 “FDE is still unreliable on UC22” : Bugs : snapd

Revision history for this message

Viktor Petersson (vpetersson) wrote on 2024-04-22:

#1

lshw output Edit (25.6 KiB, text/plain)

Revision history for this message

Valentin David (valentin.david) wrote on 2024-04-23:

#2

What is the output of "findmnt --submounts /sys"?

Revision history for this message

Valentin David (valentin.david) wrote on 2024-04-23:

#3

Also the output of "udevadm info /sys/class/tpm/tpm0/device"

Revision history for this message

Viktor Petersson (vpetersson) wrote on 2024-04-23:

#4

Hi Valentin,

Sure thing:

$ findmnt --submounts /sys
TARGET SOURCE FSTYPE OPTIONS
/sys sysfs sysfs rw,nosuid,nodev,noexec,relatime
├─/sys/kernel/security securityfs securityfs rw,nosuid,nodev,noexec,relatime
├─/sys/fs/cgroup cgroup2 cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot
├─/sys/fs/pstore pstore pstore rw,nosuid,nodev,noexec,relatime
├─/sys/firmware/efi/efivars efivarfs efivarfs rw,nosuid,nodev,noexec,relatime
├─/sys/fs/bpf bpf bpf rw,nosuid,nodev,noexec,relatime,mode=700
├─/sys/kernel/debug debugfs debugfs rw,nosuid,nodev,noexec,relatime
├─/sys/kernel/tracing tracefs tracefs rw,nosuid,nodev,noexec,relatime
├─/sys/fs/fuse/connections fusectl fusectl rw,nosuid,nodev,noexec,relatime
└─/sys/kernel/config configfs configfs rw,nosuid,nodev,noexec,relatime

$ udevadm info /sys/class/tpm/tpm0/device
P: /devices/LNXSYSTM:00/LNXSYBUS:00/MSFT0101:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/MSFT0101:00
E: DRIVER=tpm_crb
E: MODALIAS=acpi:MSFT0101:MSFT0101:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=7452148
E: ID_VENDOR_FROM_DATABASE=M-Systems Flash Disk Pioneers

Revision history for this message

Valentin David (valentin.david) wrote on 2024-04-24:

#5

Is that machine using coreboot + edk2? Was the edk2 payload built with secure boot enabled?

Another common thing is wrong ACPI tables. It would be nice to get the journal output to see where the kernel failed.

What image did you test? Was it a stable build of UC22 for x86-64? Do you know which version of pc-kernel it is using?

Revision history for this message

Viktor Petersson (vpetersson) wrote on 2024-04-24:

#6

To add to this, we have a second device now that is behaving the same way. This device I would also expect to "just work" as it's a regular NUC (NUC13ANBi3), which should be supported by FDE on Core 22.

Debug output from this device:

$ ls -lah /dev/tpm0
crw-rw---- 1 tss root 10, 224 Apr 23 19:30 /dev/tpm0

$ cat /sys/class/tpm/tpm*/tpm_version_major
2

$ findmnt --submounts /sys
TARGET SOURCE FSTYPE OPTIONS
/sys sysfs sysfs rw,nosuid,nodev,noexec,relatime
├─/sys/kernel/security securityfs securit rw,nosuid,nodev,noexec,relatime
├─/sys/fs/cgroup cgroup2 cgroup2 rw,nosuid,nodev,noexec,relatime,n
├─/sys/fs/pstore pstore pstore rw,nosuid,nodev,noexec,relatime
├─/sys/firmware/efi/efivars efivarfs efivarf rw,nosuid,nodev,noexec,relatime
├─/sys/fs/bpf bpf bpf rw,nosuid,nodev,noexec,relatime,m
├─/sys/kernel/tracing tracefs tracefs rw,nosuid,nodev,noexec,relatime
├─/sys/kernel/debug debugfs debugfs rw,nosuid,nodev,noexec,relatime
├─/sys/kernel/config configfs configf rw,nosuid,nodev,noexec,relatime
└─/sys/fs/fuse/connections fusectl fusectl rw,nosuid,nodev,noexec,relatime

$ udevadm info /sys/class/tpm/tpm0/device
P: /devices/LNXSYSTM:00/LNXSYBUS:00/MSFT0101:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/MSFT0101:00
E: DRIVER=tpm_crb
E: MODALIAS=acpi:MSFT0101:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=11635477
E: ID_VENDOR_FROM_DATABASE=M-Systems Flash Disk Pioneers

$ sudo dmsetup ls --target crypt
No devices found

$ sudo blkid
/dev/loop1: TYPE="squashfs"
/dev/nvme0n1p5: LABEL="ubuntu-data" UUID="72f553b9-b48b-412a-9839-c0f1a4fdbe27" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="ubuntu-data" PARTUUID="32f23f52-9534-f849-9a13-bd8d20a822ab"
/dev/nvme0n1p3: LABEL="ubuntu-boot" UUID="1a8e53a3-2767-455b-8536-0a7aed02c05c" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="ubuntu-boot" PARTUUID="608ddc38-3b53-7a45-873a-a96db0c0bd1e"
/dev/nvme0n1p1: PARTLABEL="BIOS Boot" PARTUUID="16c60cce-4701-450b-98ce-5404f1897d64"
/dev/nvme0n1p4: LABEL="ubuntu-save" UUID="643db19f-3f7f-4654-9aa5-b38f9408f2c4" BLOCK_SIZE="1024" TYPE="ext4" PARTLABEL="ubuntu-save" PARTUUID="186cbb18-1c14-d94f-92c9-6700fc69b3d0"
/dev/nvme0n1p2: LABEL_FATBOOT="ubuntu-seed" LABEL="ubuntu-seed" UUID="312B-9570" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="ubuntu-seed" PARTUUID="5ab39fc7-7088-451b-8db7-ea97e710e9af"
/dev/loop4: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop0: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"

For both these devices, we used the upstream amd64 image (which should have 'prefer-encryption' set by default I believe).

To add to this, we have a second device now that is behaving the same way. This device I would also expect to "just work" as it's a regular NUC (NUC13ANBi3), which should be supported by FDE on Core 22.

Debug output from this device:

$ ls -lah /dev/tpm0
crw-rw---- 1 tss root 10, 224 Apr 23 19:30 /dev/tpm0

$ cat /sys/class/tpm/tpm*/tpm_version_major
2

$ findmnt --submounts /sys
TARGET                      SOURCE     FSTYPE  OPTIONS
/sys                        sysfs      sysfs   rw,nosuid,nodev,noexec,relatime
├─/sys/kernel/security      securityfs securit rw,nosuid,nodev,noexec,relatime
├─/sys/fs/cgroup            cgroup2    cgroup2 rw,nosuid,nodev,noexec,relatime,n
├─/sys/fs/pstore            pstore     pstore  rw,nosuid,nodev,noexec,relatime
├─/sys/firmware/efi/efivars efivarfs   efivarf rw,nosuid,nodev,noexec,relatime
├─/sys/fs/bpf               bpf        bpf     rw,nosuid,nodev,noexec,relatime,m
├─/sys/kernel/tracing       tracefs    tracefs rw,nosuid,nodev,noexec,relatime
├─/sys/kernel/debug         debugfs    debugfs rw,nosuid,nodev,noexec,relatime
├─/sys/kernel/config        configfs   configf rw,nosuid,nodev,noexec,relatime
└─/sys/fs/fuse/connections  fusectl    fusectl rw,nosuid,nodev,noexec,relatime

$ udevadm info /sys/class/tpm/tpm0/device
P: /devices/LNXSYSTM:00/LNXSYBUS:00/MSFT0101:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/MSFT0101:00
E: DRIVER=tpm_crb
E: MODALIAS=acpi:MSFT0101:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=11635477
E: ID_VENDOR_FROM_DATABASE=M-Systems Flash Disk Pioneers

$ sudo dmsetup ls --target crypt
No devices found

$ sudo blkid
/dev/loop1: TYPE="squashfs"
/dev/nvme0n1p5: LABEL="ubuntu-data" UUID="72f553b9-b48b-412a-9839-c0f1a4fdbe27" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="ubuntu-data" PARTUUID="32f23f52-9534-f849-9a13-bd8d20a822ab"
/dev/nvme0n1p3: LABEL="ubuntu-boot" UUID="1a8e53a3-2767-455b-8536-0a7aed02c05c" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="ubuntu-boot" PARTUUID="608ddc38-3b53-7a45-873a-a96db0c0bd1e"
/dev/nvme0n1p1: PARTLABEL="BIOS Boot" PARTUUID="16c60cce-4701-450b-98ce-5404f1897d64"
/dev/nvme0n1p4: LABEL="ubuntu-save" UUID="643db19f-3f7f-4654-9aa5-b38f9408f2c4" BLOCK_SIZE="1024" TYPE="ext4" PARTLABEL="ubuntu-save" PARTUUID="186cbb18-1c14-d94f-92c9-6700fc69b3d0"
/dev/nvme0n1p2: LABEL_FATBOOT="ubuntu-seed" LABEL="ubuntu-seed" UUID="312B-9570" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="ubuntu-seed" PARTUUID="5ab39fc7-7088-451b-8db7-ea97e710e9af"
/dev/loop4: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop0: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"

For both these devices, we used the upstream amd64 image (which should have 'prefer-encryption' set by default I believe).

Revision history for this message

Viktor Petersson (vpetersson) wrote on 2024-04-24 (last edit on 2024-04-24):

#7

Looks like the wires crossed. :)

> Is that machine using coreboot + edk2? Was the edk2 payload built with secure boot enabled?

We're using the upstream amd64 image to rule out any disk image errors (https://cdimage.ubuntu.com/ubuntu-core/22/stable/current/ubuntu-core-22-amd64.img.xz).

> Another common thing is wrong ACPI tables. It would be nice to get the journal output to see where the kernel failed.

Sure - here's the full output from `journalctl`:
https://gist.github.com/vpetersson/3ed08452bb1ee930c2fcf322705be34f

> What image did you test? Was it a stable build of UC22 for x86-64? Do you know which version of pc-kernel it is using?

As mentioned, it's the upstream image.

Here's the list of snaps (after a `snap refresh` once though).

$ sudo snap list
Name Version Rev Tracking Publisher Notes
core22 20240408 1380 latest/stable canonical✓ base
pc 22-0.3 146 22/stable canonical✓ gadget
pc-kernel 5.15.0-105.115.1 1781 22/stable canonical✓ kernel
snapd 2.62 21465 latest/stable canonical✓ snapd

Revision history for this message

Valentin David (valentin.david) wrote on 2024-04-24:

#8

Is /sys/kernel/security/tpm0/binary_bios_measurements missing also on the NUC?

I have tried the image on a NUC10i7FNB and it worked.

Also, could you look if the tpm has a lockout? Do this and give the output.

sudo snap install tpm2-tools-alexmurray
sudo snap connect tpm2-tools-alexmurray:tpm
sudo tpm2-tools-alexmurray.getcap properties-variable

If it has a lockout from another previously installed OS, then install may fail and install without tpm.

To reset the tpm you have to do

echo 5 | sudo tee /sys/class/tpm/tpm0/ppi/request

Then you have to reboot. You can force reinstall by rebooting with this command:

sudo snap reboot --install

For the Star Labs System's Byte Mk 2, could you give the content of all the /sys/devices/virtual/dmi/id/bios_* ?

Revision history for this message

Viktor Petersson (vpetersson) wrote on 2024-04-24 (last edit on 2024-04-24):

#9

Download full text (3.8 KiB)

For context - both of these systems should be brand new. To my knowledge, no other OS has been installed on either of them.

> Is /sys/kernel/security/tpm0/binary_bios_measurements missing also on the NUC?

I need to wait until later today when my colleague wakes up to check that.

> Also, could you look if the tpm has a lockout? Do this and give the output.

Sure - this is the output from the Star Labs System device:

$ sudo snap install tpm2-tools-alexmurray
tpm2-tools-alexmurray 5.3 from Alex Murray (alexmurray✪) installed

$ sudo snap connect tpm2-tools-alexmurray:tpm

$ sudo tpm2-tools-alexmurray.getcap properties-variable
TPM2_PT_PERMANENT:
  ownerAuthSet: 0
  endorsementAuthSet: 0
  lockoutAuthSet: 0
  reserved1: 0
  disableClear: 0
  inLockout: 0
  tpmGeneratedEPS: 0
  reserved2: 0
TPM2_PT_STARTUP_CLEAR:
  phEnable: 1
  shEnable: 1
  ehEnable: 1
  phEnableNV: 1
  reserved1: 0
  orderly: 1
TPM2_PT_HR_NV_INDEX: 0x0
TPM2_PT_HR_LOADED: 0x0
TPM2_PT_HR_LOADED_AVAIL: 0x3
TPM2_PT_HR_ACTIVE: 0x0
TPM2_PT_HR_ACTIVE_AVAIL: 0x40
TPM2_PT_HR_TRANSIENT_AVAIL: 0x3
TPM2_PT_HR_PERSISTENT: 0x0
TPM2_PT_HR_PERSISTENT_AVAIL: 0x15
TPM2_PT_NV_COUNTERS: 0x0
TPM2_PT_NV_COUNTERS_AVAIL: 0x4
TPM2_PT_ALGORITHM_SET: 0x0
TPM2_PT_LOADED_CURVES: 0x4
TPM2_PT_LOCKOUT_COUNTER: 0x0
TPM2_PT_MAX_AUTH_FAIL: 0x20
TPM2_PT_LOCKOUT_INTERVAL: 0x1C20
TPM2_PT_LOCKOUT_RECOVERY: 0x15180
TPM2_PT_NV_WRITE_RECOVERY: 0x0
TPM2_PT_AUDIT_COUNTER_0: 0x0
TPM2_PT_AUDIT_COUNTER_1: 0x0

$ echo 5 | sudo tee /sys/class/tpm/tpm0/ppi/request
5

$ cat /sys/devices/virtual/dmi/id/bios_*
04/19/2024
24.2
coreboot
24.04

$ sudo snap reboot --install

[wait for the device to be re-instated]

$ findmnt --submounts /sys
TARGET SOURCE FSTYPE OPTIONS
/sys sysfs sysfs rw,nosuid,nodev,noexec,relatime
├─/sys/kernel/security securityfs securityfs rw,nosuid,nodev,noexec,relatime
├─/sys/fs/cgroup cgroup2 cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot
├─/sys/fs/pstore pstore pstore rw,nosuid,nodev,noexec,relatime
├─/sys/firmware/efi/efivars efivarfs efivarfs rw,nosuid,nodev,noexec,relatime
├─/sys/fs/bpf bpf bpf rw,nosuid,nodev,noexec,relatime,mode=700
├─/sys/kernel/debug debugfs debugfs rw,nosuid,nodev,noexec,relatime
├─/sys/kernel/tracing tracefs tracefs rw,nosuid,nodev,noexec,relatime
├─/sys/fs/fuse/connections fusectl fusectl rw,nosuid,nodev,noexec,relatime
└─/sys/kernel/config configfs configfs rw,nosuid,nodev,noexec,relatime

$ sudo blkid
/dev/loop1: TYPE="squashfs"
/dev/nvme0n1p5: LABEL="ubuntu-data" UUID="4b2c84bc-d101-4876-a974-5facbb5af775" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="ubuntu-data" PARTUUID="52025746-fc3d-c24e-b094-26f721c7cd48"
/dev/nvme0n1p3: LABEL="ubuntu-boot" UUID="5a2c439c-cf62-4773-8376-2603ea7a81fe" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="ubuntu-boot" PARTUUID="7206e296-fce4-924c-b6fd-affe...

For context - both of these systems should be brand new. To my knowledge, no other OS has been installed on either of them.

> Is /sys/kernel/security/tpm0/binary_bios_measurements missing also on the NUC?

I need to wait until later today when my colleague wakes up to check that.

> Also, could you look if the tpm has a lockout? Do this and give the output.

Sure - this is the output from the Star Labs System device:

$ sudo snap install tpm2-tools-alexmurray
tpm2-tools-alexmurray 5.3 from Alex Murray (alexmurray✪) installed

$ sudo snap connect tpm2-tools-alexmurray:tpm

$ sudo tpm2-tools-alexmurray.getcap properties-variable
TPM2_PT_PERMANENT:
  ownerAuthSet:              0
  endorsementAuthSet:        0
  lockoutAuthSet:            0
  reserved1:                 0
  disableClear:              0
  inLockout:                 0
  tpmGeneratedEPS:           0
  reserved2:                 0
TPM2_PT_STARTUP_CLEAR:
  phEnable:                  1
  shEnable:                  1
  ehEnable:                  1
  phEnableNV:                1
  reserved1:                 0
  orderly:                   1
TPM2_PT_HR_NV_INDEX: 0x0
TPM2_PT_HR_LOADED: 0x0
TPM2_PT_HR_LOADED_AVAIL: 0x3
TPM2_PT_HR_ACTIVE: 0x0
TPM2_PT_HR_ACTIVE_AVAIL: 0x40
TPM2_PT_HR_TRANSIENT_AVAIL: 0x3
TPM2_PT_HR_PERSISTENT: 0x0
TPM2_PT_HR_PERSISTENT_AVAIL: 0x15
TPM2_PT_NV_COUNTERS: 0x0
TPM2_PT_NV_COUNTERS_AVAIL: 0x4
TPM2_PT_ALGORITHM_SET: 0x0
TPM2_PT_LOADED_CURVES: 0x4
TPM2_PT_LOCKOUT_COUNTER: 0x0
TPM2_PT_MAX_AUTH_FAIL: 0x20
TPM2_PT_LOCKOUT_INTERVAL: 0x1C20
TPM2_PT_LOCKOUT_RECOVERY: 0x15180
TPM2_PT_NV_WRITE_RECOVERY: 0x0
TPM2_PT_AUDIT_COUNTER_0: 0x0
TPM2_PT_AUDIT_COUNTER_1: 0x0

$ echo 5 | sudo tee /sys/class/tpm/tpm0/ppi/request
5

$ cat /sys/devices/virtual/dmi/id/bios_*
04/19/2024
24.2
coreboot
24.04

$ sudo snap reboot --install

[wait for the device to be re-instated]

$ findmnt --submounts /sys
TARGET                      SOURCE     FSTYPE     OPTIONS
/sys                        sysfs      sysfs      rw,nosuid,nodev,noexec,relatime
├─/sys/kernel/security      securityfs securityfs rw,nosuid,nodev,noexec,relatime
├─/sys/fs/cgroup            cgroup2    cgroup2    rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot
├─/sys/fs/pstore            pstore     pstore     rw,nosuid,nodev,noexec,relatime
├─/sys/firmware/efi/efivars efivarfs   efivarfs   rw,nosuid,nodev,noexec,relatime
├─/sys/fs/bpf               bpf        bpf        rw,nosuid,nodev,noexec,relatime,mode=700
├─/sys/kernel/debug         debugfs    debugfs    rw,nosuid,nodev,noexec,relatime
├─/sys/kernel/tracing       tracefs    tracefs    rw,nosuid,nodev,noexec,relatime
├─/sys/fs/fuse/connections  fusectl    fusectl    rw,nosuid,nodev,noexec,relatime
└─/sys/kernel/config        configfs   configfs   rw,nosuid,nodev,noexec,relatime

$ sudo blkid
/dev/loop1: TYPE="squashfs"
/dev/nvme0n1p5: LABEL="ubuntu-data" UUID="4b2c84bc-d101-4876-a974-5facbb5af775" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="ubuntu-data" PARTUUID="52025746-fc3d-c24e-b094-26f721c7cd48"
/dev/nvme0n1p3: LABEL="ubuntu-boot" UUID="5a2c439c-cf62-4773-8376-2603ea7a81fe" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="ubuntu-boot" PARTUUID="7206e296-fce4-924c-b6fd-affe319f9f1f"
/dev/nvme0n1p1: PARTLABEL="BIOS Boot" PARTUUID="3a1a3e5c-6b7b-479e-9752-7cc79e4a5e46"
/dev/nvme0n1p4: LABEL="ubuntu-save" UUID="83d045a3-2e33-47f9-b1e2-7c7d59d4541e" BLOCK_SIZE="1024" TYPE="ext4" PARTLABEL="ubuntu-save" PARTUUID="c967e18c-9991-0544-9316-55a0c988f7a8"
/dev/nvme0n1p2: LABEL_FATBOOT="ubuntu-seed" LABEL="ubuntu-seed" UUID="2EFA-CB53" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="ubuntu-seed" PARTUUID="61cd77c3-d8c0-4382-9b03-0714bc38ffda"
/dev/loop4: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop0: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"

Updated journalctl dump:
https://gist.github.com/vpetersson/3b41538b1405d55b2833b45f0fae375e

Revision history for this message

Valentin David (valentin.david) wrote on 2024-04-24:

#10

For the Star Labs System, I think this is an issue with the firmware. I do not think the lockout is the issue.

Could you give the output of the following commands on the Star Labs System?

sudo cat /sys/firmware/acpi/tables/TPM2 | basenc --base16
cat /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c | basenc --base16

Revision history for this message

Viktor Petersson (vpetersson) wrote on 2024-04-24:

#11

Sure thing:

$ sudo cat /sys/firmware/acpi/tables/TPM2 | basenc --base16
54504D324C00000004C8434F52457634434F5245424F4F5400000000434F5245280623200000
00004000D4FE00000000070000000000000000000000000000000000010000D09B7600000000

$ cat /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c | basenc --base16
cat: /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c: No such file or directory

$ ls /sys/firmware/efi/efivars/
Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c LoaderDevicePartUUID-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f OsIndicationsSupported-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c LoaderFirmwareInfo-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0002-8be4df61-93ca-11d2-aa0d-00e098032b8c ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c LoaderFirmwareType-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c HwErrRecSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c LoaderImageIdentifier-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f PlatformRecovery0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c Key0000-8be4df61-93ca-11d2-aa0d-00e098032b8c MTC-eb704011-1402-11d3-8e77-00a0c969723b SbatLevelRT-605dab50-e046-4300-abb6-3dd810dd8b23
BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c Key0001-8be4df61-93ca-11d2-aa0d-00e098032b8c MokListRT-605dab50-e046-4300-abb6-3dd810dd8b23 StubInfo-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c Lang-8be4df61-93ca-11d2-aa0d-00e098032b8c MokListTrustedRT-605dab50-e046-4300-abb6-3dd810dd8b23 Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c LangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c MokListXRT-605dab50-e046-4300-abb6-3dd810dd8b23 VarErrorFlag-04b37fe8-f6ae-480b-bdd5-37d98c5e89aa

Sure thing:

$ sudo cat /sys/firmware/acpi/tables/TPM2  | basenc --base16
54504D324C00000004C8434F52457634434F5245424F4F5400000000434F5245280623200000
00004000D4FE00000000070000000000000000000000000000000000010000D09B7600000000

$ cat /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c | basenc --base16
cat: /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c: No such file or directory

$ ls /sys/firmware/efi/efivars/
Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c           ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c           LoaderDevicePartUUID-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f   OsIndicationsSupported-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c           ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c        LoaderFirmwareInfo-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f     PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0002-8be4df61-93ca-11d2-aa0d-00e098032b8c           ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c        LoaderFirmwareType-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f     PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c        HwErrRecSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c  LoaderImageIdentifier-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f  PlatformRecovery0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c  Key0000-8be4df61-93ca-11d2-aa0d-00e098032b8c          MTC-eb704011-1402-11d3-8e77-00a0c969723b                    SbatLevelRT-605dab50-e046-4300-abb6-3dd810dd8b23
BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c          Key0001-8be4df61-93ca-11d2-aa0d-00e098032b8c          MokListRT-605dab50-e046-4300-abb6-3dd810dd8b23              StubInfo-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c              Lang-8be4df61-93ca-11d2-aa0d-00e098032b8c             MokListTrustedRT-605dab50-e046-4300-abb6-3dd810dd8b23       Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c           LangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c        MokListXRT-605dab50-e046-4300-abb6-3dd810dd8b23             VarErrorFlag-04b37fe8-f6ae-480b-bdd5-37d98c5e89aa

Revision history for this message

Valentin David (valentin.david) wrote on 2024-04-24:

#12

It looks like the firmware on the Star Labs machine does not support secure boot. I wonder if it is a build of edk2 without secure boot and tpm2 enabled. Could you see if you can update the firmware with fwupd?

Revision history for this message

Viktor Petersson (vpetersson) wrote on 2024-04-24:

#13

> It looks like the firmware on the Star Labs machine does not support secure boot. I wonder if it is a build of edk2 without secure boot and tpm2 enabled. Could you see if you can update the firmware with fwupd?

I'm 99% sure it does. In fact, it will not boot anything that isn't Secure Boot

Revision history for this message

Viktor Petersson (vpetersson) wrote on 2024-04-24:

#14

Interesting:

$ sudo snap install test-snapd-mokutil --beta --devmode
test-snapd-mokutil (beta) 0.3.0 from Sergio Cazzolato (cachio) installed

$ test-snapd-mokutil --sb-state
This system doesn't support Secure Boot

Revision history for this message

Valentin David (valentin.david) wrote on 2024-04-25:

#15

> In fact, it will not boot anything that isn't Secure Boot

I think it is probably booting only UEFI and it cannot boot legacy BIOS. But I do not think it boots in secure boot.

Since they claim it can do secure boot and measured boot on their website, I expect there are newer builds of the firmware that can do it.

Or maybe there is some firmware configuration. Have you tried to go in the settings menu of the firmware? Probably pressing ESC while booting.

Revision history for this message

Viktor Petersson (vpetersson) wrote on 2024-04-25:

#16

Thanks, Valentin. I'm in conversation with the vendor and they are working on reproducing (and patching) the BIOS.

I'm also still awaiting the output from the other NUC.

Revision history for this message

Star Labs (starlabs) wrote on 2024-04-25:

#17

To update from our end. The current coreboot build is built with SecureBoot disabled and hidden.

We have since verified on our reference AMI firmware that the hardware will allow an FDE with TPM deployment of Ubuntu core 22.

Now we know the requirements, we can adjust the coreboot firmware to requirements.

Philip Meulengracht (the-meulengracht) on 2024-04-25

Changed in snapd:
assignee:	nobody → Valentin David (valentin.david)
status:	New → Triaged
importance:	Undecided → High

Revision history for this message

Viktor Petersson (vpetersson) wrote on 2024-04-27:

#18

@Valintin - I think we can rule out the Star Labs device for this for now. Will chat with the guys over there on the best way to proceed.

In the meantime, here's the output from the first NUC:

```
$ ls -l /sys/kernel/security/tpm0/binary_bios_measurements
-r--r----- 1 root root 0 Apr 25 17:38 /sys/kernel/security/tpm0/binary_bios_measurements
```
```
$ sudo snap install tpm2-tools-alexmurray
tpm2-tools-alexmurray 5.3 from Alex Murray (alexmurray✪) installed
```
```
$ sudo snap connect tpm2-tools-alexmurray:tpm
```
```
$ sudo tpm2-tools-alexmurray.getcap properties-variable
TPM2_PT_PERMANENT:
  ownerAuthSet: 0
  endorsementAuthSet: 0
  lockoutAuthSet: 1
  reserved1: 0
  disableClear: 1
  inLockout: 0
  tpmGeneratedEPS: 0
  reserved2: 0
TPM2_PT_STARTUP_CLEAR:
  phEnable: 1
  shEnable: 1
  ehEnable: 1
  phEnableNV: 1
  reserved1: 0
  orderly: 1
TPM2_PT_HR_NV_INDEX: 0x3
TPM2_PT_HR_LOADED: 0x0
TPM2_PT_HR_LOADED_AVAIL: 0x3
TPM2_PT_HR_ACTIVE: 0x0
TPM2_PT_HR_ACTIVE_AVAIL: 0x40
TPM2_PT_HR_TRANSIENT_AVAIL: 0x3
TPM2_PT_HR_PERSISTENT: 0x3
TPM2_PT_HR_PERSISTENT_AVAIL: 0x12
TPM2_PT_NV_COUNTERS: 0x2
TPM2_PT_NV_COUNTERS_AVAIL: 0x4
TPM2_PT_ALGORITHM_SET: 0x0
TPM2_PT_LOADED_CURVES: 0x4
TPM2_PT_LOCKOUT_COUNTER: 0x0
TPM2_PT_MAX_AUTH_FAIL: 0x20
TPM2_PT_LOCKOUT_INTERVAL: 0x1C20
TPM2_PT_LOCKOUT_RECOVERY: 0x15180
TPM2_PT_NV_WRITE_RECOVERY: 0x0
TPM2_PT_AUDIT_COUNTER_0: 0x0
TPM2_PT_AUDIT_COUNTER_1: 0x0
```

Revision history for this message

Valentin David (valentin.david) wrote on 2024-04-30:

#19

Yes, there is a lockout. There was probably another system using the TPM on this machine. Could you try to do the following?

echo 5 | sudo tee /sys/class/tpm/tpm0/ppi/request
sudo snap reboot --install

Revision history for this message

Viktor Petersson (vpetersson) wrote on 2024-05-01:

#20

Here's the output from the various commands after the reset:

$ sudo blkid
/dev/loop1: TYPE="squashfs"
/dev/nvme0n1p5: LABEL="ubuntu-data" UUID="d751579d-4f5a-4292-9f7f-75b3a3ef40e5" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="ubuntu-data" PARTUUID="f9cdc648-3237-f240-adbf-27a04a35f971"
/dev/nvme0n1p3: LABEL="ubuntu-boot" UUID="e946a179-14a7-4af2-b151-2ff7220a66ec" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="ubuntu-boot" PARTUUID="46c44e68-a578-3e42-8205-2aaf7418b005"
/dev/nvme0n1p1: PARTLABEL="BIOS Boot" PARTUUID="16c60cce-4701-450b-98ce-5404f1897d64"
/dev/nvme0n1p4: LABEL="ubuntu-save" UUID="f9db7166-2b18-4442-9938-f2b31f3d555a" BLOCK_SIZE="1024" TYPE="ext4" PARTLABEL="ubuntu-save" PARTUUID="905e9a27-7173-1c46-ba05-88653f6c9dd7"
/dev/nvme0n1p2: LABEL_FATBOOT="ubuntu-seed" LABEL="ubuntu-seed" UUID="312B-9570" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="ubuntu-seed" PARTUUID="5ab39fc7-7088-451b-8db7-ea97e710e9af"
/dev/loop4: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop0: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"

$ sudo dmsetup ls --target crypt
No devices found

$ lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
NAME SIZE TYPE MOUNTPOINT
loop0 74.2M loop /snap/core22/1122
loop1 1.6M loop /snap/pc/146
loop2 296.3M loop /snap/pc-kernel/1781
loop3 334.8M loop /snap/pc-kernel/1646
loop4 40.4M loop /snap/snapd/20671
nvme0n1 238.5G disk
├─nvme0n1p1 1M part
├─nvme0n1p2 1.2G part /var/lib/snapd/seed
├─nvme0n1p3 750M part /run/mnt/ubuntu-boot
├─nvme0n1p4 32M part /var/lib/snapd/save
└─nvme0n1p5 236.5G part /writable

$ ls -l /sys/kernel/security/tpm0/binary_bios_measurements
-r--r----- 1 root root 0 May 1 13:08 /sys/kernel/security/tpm0/binary_bios_measurements

$ sudo snap install tpm2-tools-alexmurray
tpm2-tools-alexmurray 5.3 from Alex Murray (alexmurray✪) installed

$ sudo snap connect tpm2-tools-alexmurray:tpm
$ sudo tpm2-tools-alexmurray.getcap properties-variable
TPM2_PT_PERMANENT:
  ownerAuthSet: 0
  endorsementAuthSet: 0
  lockoutAuthSet: 1
  reserved1: 0
  disableClear: 1
  inLockout: 0
  tpmGeneratedEPS: 0
  reserved2: 0
TPM2_PT_STARTUP_CLEAR:
  phEnable: 1
  shEnable: 1
  ehEnable: 1
  phEnableNV: 1
  reserved1: 0
  orderly: 1
TPM2_PT_HR_NV_INDEX: 0x2
TPM2_PT_HR_LOADED: 0x0
TPM2_PT_HR_LOADED_AVAIL: 0x3
TPM2_PT_HR_ACTIVE: 0x0
TPM2_PT_HR_ACTIVE_AVAIL: 0x40
TPM2_PT_HR_TRANSIENT_AVAIL: 0x3
TPM2_PT_HR_PERSISTENT: 0x2
TPM2_PT_HR_PERSISTENT_AVAIL: 0x13
TPM2_PT_NV_COUNTERS: 0x2
TPM2_PT_NV_COUNTERS_AVAIL: 0x4
TPM2_PT_ALGORITHM_SET: 0x0
TPM2_PT_LOADED_CURVES: 0x4
TPM2_PT_LOCKOUT_COUNTER: 0x0
TPM2_PT_MAX_AUTH_FAIL: 0x20
TPM2_PT_LOCKOUT_INTERVAL: 0x1C20
TPM2_PT_LOCKOUT_RECOVERY: 0x15180
TPM2_PT_NV_WRITE_RECOVERY: 0x0
TPM2_PT_AUDIT_COUNTER_0: 0x0
TPM2_PT_AUDIT_COUNTER_1: 0x0

From what I can gather based on the output, FDE did not kick in.

Here's the output from the various commands after the reset:

$ sudo blkid
/dev/loop1: TYPE="squashfs"
/dev/nvme0n1p5: LABEL="ubuntu-data" UUID="d751579d-4f5a-4292-9f7f-75b3a3ef40e5" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="ubuntu-data" PARTUUID="f9cdc648-3237-f240-adbf-27a04a35f971"
/dev/nvme0n1p3: LABEL="ubuntu-boot" UUID="e946a179-14a7-4af2-b151-2ff7220a66ec" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="ubuntu-boot" PARTUUID="46c44e68-a578-3e42-8205-2aaf7418b005"
/dev/nvme0n1p1: PARTLABEL="BIOS Boot" PARTUUID="16c60cce-4701-450b-98ce-5404f1897d64"
/dev/nvme0n1p4: LABEL="ubuntu-save" UUID="f9db7166-2b18-4442-9938-f2b31f3d555a" BLOCK_SIZE="1024" TYPE="ext4" PARTLABEL="ubuntu-save" PARTUUID="905e9a27-7173-1c46-ba05-88653f6c9dd7"
/dev/nvme0n1p2: LABEL_FATBOOT="ubuntu-seed" LABEL="ubuntu-seed" UUID="312B-9570" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="ubuntu-seed" PARTUUID="5ab39fc7-7088-451b-8db7-ea97e710e9af"
/dev/loop4: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop0: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"

$ sudo dmsetup ls --target crypt
No devices found

$ lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
NAME          SIZE TYPE MOUNTPOINT
loop0        74.2M loop /snap/core22/1122
loop1         1.6M loop /snap/pc/146
loop2       296.3M loop /snap/pc-kernel/1781
loop3       334.8M loop /snap/pc-kernel/1646
loop4        40.4M loop /snap/snapd/20671
nvme0n1     238.5G disk 
├─nvme0n1p1     1M part 
├─nvme0n1p2   1.2G part /var/lib/snapd/seed
├─nvme0n1p3   750M part /run/mnt/ubuntu-boot
├─nvme0n1p4    32M part /var/lib/snapd/save
└─nvme0n1p5 236.5G part /writable

$ ls -l /sys/kernel/security/tpm0/binary_bios_measurements
-r--r----- 1 root root 0 May  1 13:08 /sys/kernel/security/tpm0/binary_bios_measurements

$ sudo snap install tpm2-tools-alexmurray
tpm2-tools-alexmurray 5.3 from Alex Murray (alexmurray✪) installed

$ sudo snap connect tpm2-tools-alexmurray:tpm
$ sudo tpm2-tools-alexmurray.getcap properties-variable
TPM2_PT_PERMANENT:
  ownerAuthSet:              0
  endorsementAuthSet:        0
  lockoutAuthSet:            1
  reserved1:                 0
  disableClear:              1
  inLockout:                 0
  tpmGeneratedEPS:           0
  reserved2:                 0
TPM2_PT_STARTUP_CLEAR:
  phEnable:                  1
  shEnable:                  1
  ehEnable:                  1
  phEnableNV:                1
  reserved1:                 0
  orderly:                   1
TPM2_PT_HR_NV_INDEX: 0x2
TPM2_PT_HR_LOADED: 0x0
TPM2_PT_HR_LOADED_AVAIL: 0x3
TPM2_PT_HR_ACTIVE: 0x0
TPM2_PT_HR_ACTIVE_AVAIL: 0x40
TPM2_PT_HR_TRANSIENT_AVAIL: 0x3
TPM2_PT_HR_PERSISTENT: 0x2
TPM2_PT_HR_PERSISTENT_AVAIL: 0x13
TPM2_PT_NV_COUNTERS: 0x2
TPM2_PT_NV_COUNTERS_AVAIL: 0x4
TPM2_PT_ALGORITHM_SET: 0x0
TPM2_PT_LOADED_CURVES: 0x4
TPM2_PT_LOCKOUT_COUNTER: 0x0
TPM2_PT_MAX_AUTH_FAIL: 0x20
TPM2_PT_LOCKOUT_INTERVAL: 0x1C20
TPM2_PT_LOCKOUT_RECOVERY: 0x15180
TPM2_PT_NV_WRITE_RECOVERY: 0x0
TPM2_PT_AUDIT_COUNTER_0: 0x0
TPM2_PT_AUDIT_COUNTER_1: 0x0

From what I can gather based on the output, FDE did not kick in.

Revision history for this message

Valentin David (valentin.david) wrote on 2024-05-13:

#21

It looks like the tpm is still in use. If resetting with the command line I gave, could you try to clear TPM the BIOS menu, if that is available?

Also, could you also provide /var/log/install-mode.log.gz ?

Revision history for this message

Viktor Petersson (vpetersson) wrote on 2024-05-15:

#22

install-mode.log.gz Edit (36.4 KiB, application/octet-stream)

Adding install-mode logs

Revision history for this message

Viktor Petersson (vpetersson) wrote on 2024-05-15:

#23

More logs here:
https://gist.github.com/vpetersson/9e945a3a3b1c3012cd458a508aebf982

Eric will provide more info if needed.

Revision history for this message

Valentin David (valentin.david) wrote on 2024-05-15:

#24

I see

```
May 01 13:05:40 ubuntu snapd[1767]: install.go:207: not encrypting device storage as checking TPM gave: the TPM is in DA lockout mode
```

That confirms the issue. I do not understand why the reset did not work. Did you skip the reset on reboot? It might need user interaction during boot to confirm reset.

Revision history for this message

Eric M. (eric-screenly) wrote on 2024-05-15:

#25

David-Output-05152024-408PM.txt Edit (9.0 KiB, text/plain)

Hi David,

I confirmed there is no interaction needed that I can tell. I don't see any other options presented during the reboot that are not usually presented (without the reset). I went through it once more, this time using --install, instead of --factory-reset like yesterday (--install however was done before on 4/30).

The output is attached for you.

Revision history for this message

Eric M. (eric-screenly) wrote on 2024-05-15:

#26

install-mode.log.gz Edit (42.4 KiB, application/octet-stream)

Attaching new install-mode logs as well.

Revision history for this message

Eric M. (eric-screenly) wrote on 2024-05-29:

#27

Hi Valentin,

Was there anything else you could think of on this one? I have a second device now for testing that also exhibits the same symptoms.

Revision history for this message

Valentin David (valentin.david) wrote on 2024-05-30:

#28

I have looked at my NUC and request 5 also does not require user interaction.

But right, the --install does not recreate the partitions. My bad. Though the tpm did not fail this time. So this is good.

I suggest you boot some system from USB, reflash the disk with ubuntu core, or simply remove partitions 3, 4 and 5. Then do the PPI request from that USB booted system. Then reboot without the USB.

# Reminder, the PPI request can be done with:
echo 5 | sudo tee /sys/class/tpm/tpm0/ppi/request

Revision history for this message

Eric M. (eric-screenly) wrote on 2024-06-04:

#29

Hi Valentin,

I booted and ran Ubuntu Desktop 22.04 from a live USB, then completed the TPM request again. I then rebooted and reinstalled Ubuntu Core 22. When I checked again it appeared to still be showing the TPM locked out (`sudo tpm2-tools-alexmurray.getcap properties-variable`), so I moved on to deleting the partitions. Once they were deleted and I rebooted, UC22 came up with a login prompt and didn't recognize my login. So I booted back off the live USB and reinstalled UC22 again (also completing the TPM request from the USB as before). This time when I rebooted, it came up asking for the recovery key for one of the partitions, which I don't have. It automatically starts a reboot cycle if not entered in a certain amount of time. Am I missing a step here?

Revision history for this message

Valentin David (valentin.david) wrote on 2024-06-06:

#30

First, if the tpm shows lockout, but encryption is used, then it is fine. You can always verify in the install-mode.log, if there is a mention "the TPM is in DA lockout mode". It is the best way to detect if it went wrong.

I wonder if the first time you resetted the tpm and reinstalled Ubuntu Core, it might have worked. Did you check if the disks were encrypted?

I wonder why on the second re-install, that did not work. GPT has a backup table in the back of the disk. I wonder if it got confused and kept the old partitions. Though that should not happen. Wiping the last block of the disk before re-installing might help. But I have doubts.

The only way to debug it here would be to build an image with a modified gadget to disable reboots and enable debug shell.

If you download https://github.com/snapcore/models/blob/master/ubuntu-core-22-amd64-dangerous.model, then install ubuntu-image (snap install --classic ubuntu-image). Then download the gadget (snap download pc --channel latest/edge). Unpack the gadget with unsquashfs (unsquashfs -d pc pc*.snap). Add "cmdline.extra" file in it with "dangerous systemd.debug_shell=1" in the unpacked directory. Then repack with "snap pack pc". And then build the image, "ubuntu-image snap ubuntu-core-22-amd64-dangerous.model --snap pc_<version>.snap". You will get an image called "pc.img". Install that. Then on the reboot if it fails because it cannot unlock the disks, you can use "ctrl-alt-f9" to get a shell. Then your can dump the journal (journalctl >/run/mnt/ubuntu-seed/failure.log). From a live USB, mount the seed partition and get the failure.log.

Revision history for this message

Eric M. (eric-screenly) wrote on 2024-06-06:

#31

Hi Valentin,

Looking back on my command output in my message on 5/15, it seems like it reported the ubuntu-data and ubuntu-save partitions were encrypted. I also tested with UC24 yesterday as well, and I was able to get to the same output. I've listed both relevant snippets below. Does this confirm that FDE is working as expected?

NUC13ANBi3 - UC22 (trimmed output from 5/15):

eric-screenly@ubuntu:~$ sudo blkid
/dev/nvme0n1p5: UUID="ef7fb7cf-c39a-43fa-9cff-fb49bbc11dc3" LABEL="ubuntu-data-enc" TYPE="crypto_LUKS" PARTLABEL="ubuntu-data" PARTUUID="034068fb-2b20-6540-911e-dd5a25ad992e"
/dev/nvme0n1p4: UUID="91781f52-bf70-4390-9143-9e769808f66c" LABEL="ubuntu-save-enc" TYPE="crypto_LUKS" PARTLABEL="ubuntu-save" PARTUUID="b871ee9a-a568-8e4c-80f9-f48da0388b26"

eric-screenly@ubuntu:~$ sudo dmsetup ls --target crypt
ubuntu-data-518c0539-709f-4565-95a6-5fbe2603eced (253, 0)
ubuntu-save-bc64ea22-02b2-4f83-9700-2d53b7bd5eae (253, 1)

eric-screenly@ubuntu:~$ lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
NAME SIZE TYPE MOUNTPOINT
nvme0n1 238.5G disk
├─nvme0n1p4 32M part
│ └─ubuntu-save-bc64ea22-02b2-4f83-9700-2d53b7bd5eae 25M crypt /var/lib/snapd/save
└─nvme0n1p5 236.5G part
└─ubuntu-data-518c0539-709f-4565-95a6-5fbe2603eced 236.5G crypt /writable

===================================

NUC13ANBi3 - UC24 (trimmed output from yesterday, 6/5)):

eric-screenly@localhost:~$ sudo blkid
/dev/nvme0n1p5: UUID="e7190957-65f9-4391-9ae7-7b3de25b5ead" LABEL="ubuntu-data-enc" TYPE="crypto_LUKS" PARTLABEL="ubuntu-data" PARTUUID="cccbd6b0-87a4-4f57-8c08-65025aab3caf"
/dev/nvme0n1p4: UUID="2c59de7c-d4cc-4151-8056-3eb5a78fc0e4" LABEL="ubuntu-save-enc" TYPE="crypto_LUKS" PARTLABEL="ubuntu-save" PARTUUID="d26cd312-12a1-4c81-860c-8ac2323bc857"

eric-screenly@localhost:~$ sudo dmsetup ls --target crypt
ubuntu-data-e561e0b8-7b28-4c3d-9bf3-3525e401288d (252, 0)
ubuntu-save-3a64cfbf-326f-4a76-8baf-362fe6dd181c (252, 1)

eric-screenly@localhost:~$ lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE
NAME SIZE TYPE MOUNTPOINT FSTYPE
nvme0n1 238.5G disk
├─nvme0n1p4 32M part crypto_LUKS
│ └─ubuntu-save-3a64cfbf-326f-4a76-8baf-362fe6dd181c 25M crypt /var/lib/snapd/save ext4
└─nvme0n1p5 236.5G part crypto_LUKS
└─ubuntu-data-e561e0b8-7b28-4c3d-9bf3-3525e401288d 236.5G crypt /writable ext4

Hi Valentin,

Looking back on my command output in my message on 5/15, it seems like it reported the ubuntu-data and ubuntu-save partitions were encrypted. I also tested with UC24 yesterday as well, and I was able to get to the same output. I've listed both relevant snippets below. Does this confirm that FDE is working as expected?

NUC13ANBi3 - UC22 (trimmed output from 5/15):

eric-screenly@ubuntu:~$ sudo blkid
/dev/nvme0n1p5: UUID="ef7fb7cf-c39a-43fa-9cff-fb49bbc11dc3" LABEL="ubuntu-data-enc" TYPE="crypto_LUKS" PARTLABEL="ubuntu-data" PARTUUID="034068fb-2b20-6540-911e-dd5a25ad992e"
/dev/nvme0n1p4: UUID="91781f52-bf70-4390-9143-9e769808f66c" LABEL="ubuntu-save-enc" TYPE="crypto_LUKS" PARTLABEL="ubuntu-save" PARTUUID="b871ee9a-a568-8e4c-80f9-f48da0388b26"

eric-screenly@ubuntu:~$ sudo dmsetup ls --target crypt
ubuntu-data-518c0539-709f-4565-95a6-5fbe2603eced	(253, 0)
ubuntu-save-bc64ea22-02b2-4f83-9700-2d53b7bd5eae	(253, 1)

eric-screenly@ubuntu:~$ lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
NAME                                                   SIZE TYPE  MOUNTPOINT
nvme0n1                                              238.5G disk  
├─nvme0n1p4                                             32M part  
│ └─ubuntu-save-bc64ea22-02b2-4f83-9700-2d53b7bd5eae    25M crypt /var/lib/snapd/save
└─nvme0n1p5                                          236.5G part  
  └─ubuntu-data-518c0539-709f-4565-95a6-5fbe2603eced 236.5G crypt /writable

===================================

NUC13ANBi3 - UC24 (trimmed output from yesterday, 6/5)):

eric-screenly@localhost:~$ sudo blkid
/dev/nvme0n1p5: UUID="e7190957-65f9-4391-9ae7-7b3de25b5ead" LABEL="ubuntu-data-enc" TYPE="crypto_LUKS" PARTLABEL="ubuntu-data" PARTUUID="cccbd6b0-87a4-4f57-8c08-65025aab3caf"
/dev/nvme0n1p4: UUID="2c59de7c-d4cc-4151-8056-3eb5a78fc0e4" LABEL="ubuntu-save-enc" TYPE="crypto_LUKS" PARTLABEL="ubuntu-save" PARTUUID="d26cd312-12a1-4c81-860c-8ac2323bc857"

eric-screenly@localhost:~$ sudo dmsetup ls --target crypt
ubuntu-data-e561e0b8-7b28-4c3d-9bf3-3525e401288d	(252, 0)
ubuntu-save-3a64cfbf-326f-4a76-8baf-362fe6dd181c	(252, 1)

eric-screenly@localhost:~$ lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE
NAME                                                   SIZE TYPE  MOUNTPOINT                      FSTYPE
nvme0n1                                              238.5G disk                                  
├─nvme0n1p4                                             32M part                                  crypto_LUKS
│ └─ubuntu-save-3a64cfbf-326f-4a76-8baf-362fe6dd181c    25M crypt /var/lib/snapd/save             ext4
└─nvme0n1p5                                          236.5G part                                  crypto_LUKS
  └─ubuntu-data-e561e0b8-7b28-4c3d-9bf3-3525e401288d 236.5G crypt /writable                       ext4

Revision history for this message

Valentin David (valentin.david) wrote on 2024-06-10:

#32

This looks like it is working.

Do you still have issues where the recovery key is asked on reboot?

Revision history for this message

Eric M. (eric-screenly) wrote on 2024-06-11:

#33

Hey Valentin,

Rebooted and it does not ask for the recovery key any longer. Thanks for the help with this. I'll check back with Viktor and see if he has any comments.

snapd

FDE is still unreliable on UC22

Bug Description

Other bug subscribers

Bug attachments

Remote bug watches