Amber → Byzantium Upgrade / LibremKey

Software PureOS
1

On a Librem 13v4 using a LibremKey to decrypt the root filesystem I upgraded from Amber to Byzantium.

After the upgrade was done I could only decrypt my root fs using the (emergency) passphrase, but not using my LibremKey as before in Amber.

I found the follwoing issues:

→ GRUB_CMDLINE_LINUX_RECOVERY not used by grub-mkconfig

@Kyle_Rankin script to install disk decryption using the libremkey (smartcard-key-luks) puts information into /etc/default/grub that should be used when booting into a recovery session using grub.

It also patches /etc/grub.d/10_linux to use the content of GRUB_CMDLINE_LINUX_RECOVERY when generating grub.cfg using grub-mkconfig.

But grub-mkconfig does not export the variable GRUB_CMDLINE_LINUX_RECOVERY (anymore?) and the value from /etc/default/grub is not used.

I made a merges request to add the functionality (back) to grub-common.

I also opened an issue for smartcard-key-luks to mention the problem there.

→ LibremKey for rootfs decryption not supported by dracut

In Byzantium the initrd images in /boot/ are generated by dracut (an alternative to update-initramfs). dracut does not put the files necessary for decryption of the rootfs using the LibremKey into the initrd files.

The package initramfs-tools in the Byzantium repo does not contain /usr/sbin/update-initramfs. To me it seems uncomplete and/or broken. Is is installed alongside with dracut which seems not to be possible in debian bullseye.

I installed initramfs-tools and initramfs-tools-core from the debian bullseye repositories. The dracut package has been deinstalled by this automatically. update-initramfs generated a initrd which included the missing files for disk decryption using the LibremKey and disk decryption using the LibremKey does work again like in Amber.

Created an issue for smartcard-key-luks for this problem.

2 Likes
2

First, I’m sorry you hit this issue during the upgrade, but I’m glad that recovery mode worked (that’s why it’s there!) You might be the first person to have tried this combination. I haven’t yet had a chance to test this script on Byzantium or what happens when someone upgrades after having set it up.

Ultimately I had hoped when I first created the script that much of it would be made unnecessary by the time Debian’s new release (and Byzantium) came out, but unfortunately that’s not the case. In particular I had hoped GRUB changes would have made it in since it’s a simple patch.

Yes I filed a wishlist issue years ago with grub-common to fix this issue but they have yet to incorporate it, and it looks like during the upgrade it overwrite the hard-coded change my script makes to the grub-mkconfig file.

Hmm, I also didn’t realize this switch made its way into Byzantium (this is the problem with having me be one of the primary testers for Qubes support on my work laptop). I’ll have to look into this and figure out whether we wholesale switch back to update-initramfs, or whether I put some logic into the script to adapt itself to dracut.

1 Like
3

that’s wierd.
i just isntalled pureos 10 byzantium
then i invoked smarcard-key-luks, and it works.
only thing that i see in cmdline of kernel is nosplash directive that disables splash boot as it not works with pinentry.
all files required to cryptsetup working were added to initrd correctly…
however plain install of PureOS 10 don’t use dracut, it uses regular update-initrd, so probably upgrade path 9->10 need to be fixed.

@Kyle_Rankin FYI issue is related probably with direct upgrade 9->10 ,
on oem install / livecd install , regular mkinitramfs is being used, and dracut is not installed at all.

also worth noting is that gnome-oem images are broken - they are removing phaseparse , but not putting key to initrd , so user whom installed from gnome-oem image will not able to decrypt drive at all :wink:
reported a month ago to @joao.azevedo …

4

Interesting finding! That does change things, if the current PureOS 10 install works with the script and doesn’t install dracut…

5

It’s not been the recovery mode that helped. I had a key slot in luks with a conventional password as a fallback in case the LibremKey would break or not work.

On first reboot I’ve been asked to enter a passphrase to unlock the drive. Simple as that.

I guess the recovery mode would not have worked as expected, because I first had to patch grub-mkconfig to re-enable the usage of GRUB_CMDLINE_LINUX_RECOVERY from /etc/default/grub.

6

I checked it and I can confirm this.

After reinstalling initramfs-tools the missing update-initramfs appeared on my harddrive.

After the upgrade the package initramfs-tools seems to be incomplete/broken even though it is not marked as such.

7

I sent a patch to GNU grub. Any support for it is welcome :wink: !

I hope that - if the patch makes it into the source - it will be easier to have it in Debian and if they’d not backport it, we’d just have to wait…

1 Like
8

Just had to enter my emergency passphrase again, because dracut had replaced initramfs-tools on my system without me taking notice. While fixing it (re-installing initramfs-tools) I found the reason for dracut being installed:

# apt-cache show btrfs-progs
Package: btrfs-progs
Version: 5.10.1-2
Installed-Size: 3959
Maintainer: Adam Borowski <kilobyte@angband.pl>
Architecture: amd64
Depends: libblkid1 (>= 2.17.2), libc6 (>= 2.8), libcom-err2 (>= 1.43.9), libext2fs2 (>= 1.42), liblzo2-2 (>= 2.02), libmount1 (>= 2.24.2), libuuid1 (>= 2.16), libzstd1 (>= 1.4.0), zlib1g (>= 1:1.2.0), libgcc-s1 (>> 10-20200211)
Suggests: duperemove
Breaks: btrbk (<= 0.25.0), initramfs-tools (<< 0.137~), libgcc-s1 (<< 10-20200211)

byzantium does only offer initramfs-tools=0.132pureos1 while bullseye offers initramfs-tools=0.140 . So if I install btrfs-progs initramfs-tools gets removed and is replaced by dracut.

Why is initramfs-tools in byzantium not the same version as in bullseye?

@Kyle_Rankin @jeremiah

P.D. corrected a typo and an error in this message: it is not btrfs-progs that is too old in byzantium, but initramfs-tools

P.P.D added tracker issue T1087

9

The patch has been accepted at GNU Grub. I also offered a patch to Debian, but there is no reaction to it until now. Maybe someone is willing to support my argument that it would be good to have this feature?

10

I successfully tested:

  • Installed debians initramfs-tools=0.140
  • rebuild initramfs
  • rebooted to check - no problem
  • installed btrfs-progs: initramfs-tools gets not replaced by dracut
11

Did a fresh install of Byzantinum, then tried the smardcard-key-luks script and had the same problem as described in the initial post here by @ChriChri
I’m falling directly into the shell where it asks me for my passphrase, no Smartcard unlock. Is there any news on this / any proposed fix strategy that you would recommend for me? I figured I ask first before I start fiddling with it myself :slight_smile:

12

Did you update the system before using the smardcard-key-luks script?

13

All packages on Byzantinum claim to be up to date. I’ve been running on the system for ~ a week already.

14

Looked a bit more into this:

  • initramfs-tools is not installed on my installation, but apparently was at some point. it says [residual-config]
  • btrfs-progs and dracut are installed.

@ChriChri: If I understand you correct, you uninstalled btrfs-progs and dracut, installed initramfs-tools 0.140 from the debian repos, ran the update-intramfs -u, rebooted to check all fine, adn then installed btrfs-progs?

15

Sorry, it is not really prominent in this thread: There is an issue in tracker describing the problem: https://tracker.pureos.net/T1087

Just remembered…

I’m a bit astonished that the problem is not solved, yet.

16

Did you solve the issue?

17

On a virtual machine, I went through the same process and tested it out. One potential workaround to solve the issue seems to be what you more or less describe:

  • Install initramfs-tools version 0.140 from the debian repos, which does not interfer with btrfs-progs.
  • Run update-initramfs -u as described in the setup routine

That seems to work on the virtual machine, not surprising since you have already declared success with this approach above :slight_smile: Any downsides to this?

18

Yes. The behaviour on an update of one of the packages involved is not determinend. If there’s an update to one of the packages part of the problem you could run into a regression.

I opted to define a pinning for apt to keep initramfs-tools from the debian repository. But that also could lead to a regression I guess.