Recent updates are resetting Systemd-boot bootloader entries for a LUKS and LVM install

I posted the issue in the Stable Updates threads, but was told to post here for more troubleshooting. I was able to fix the issue on my end, but I do not know the root cause.

Problem:
This issue occurred twice: once after the 2019-10-10 and again after 2019-10-14 update. My bootloader entry, /boot/loader/entries/manjarolinux4.19.conf, was seemingly reset after each update and removed my cryptdevice in options of the entry conf. Adding the cryptdevice back into the conf fixed it, but this is very annoying if this occurs every time I update the application in question.

Technical details:

/boot/loader/entries/manjarolinux4.19.conf BEFORE update
title   Manjaro Linux 4.19
linux   /vmlinuz-4.19-x86_64
initrd  /amd-ucode.img
initrd  /intel-ucode.img
initrd  /initramfs-4.19-x86_64.img
options root=UUID=bdb75391-ab56-45eb-8389-a4da73ba888b rw cryptdevice=UUID=614d4999-66da-48c1-9185-c33355ae3f59:cryptroot:allow-discards
/boot/loader/entries/manjarolinux4.19.conf AFTER update
title   Manjaro Linux 4.19
linux   /vmlinuz-4.19-x86_64
initrd  /amd-ucode.img
initrd  /intel-ucode.img
initrd  /initramfs-4.19-x86_64.img
options root=UUID=bdb75391-ab56-45eb-8389-a4da73ba888b rw
blkid
/dev/nvme0n1p1: UUID="2BB7-5B1F" TYPE="vfat" PARTUUID="99e00a78-207b-47fb-a3a2-c8599fbecab9"
/dev/nvme0n1p2: UUID="614d4999-66da-48c1-9185-c33355ae3f59" TYPE="crypto_LUKS" PARTUUID="e0fb919b-11b2-4a85-8fee-00c93cdbdcb7"
/dev/mapper/cryptroot: UUID="51cOfE-RNIG-5eor-dDjH-AWE3-rud3-q8iIAW" TYPE="LVM2_member"
/dev/mapper/vgspace-lvswap: UUID="cc1e7880-eea4-4b0c-a0c7-3543904cf720" TYPE="swap"
/dev/mapper/vgspace-lvroot: UUID="bdb75391-ab56-45eb-8389-a4da73ba888b" TYPE="ext4"
lsblk
NAME                 MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
nvme0n1              259:0    0 465.8G  0 disk  
├─nvme0n1p1          259:1    0   512M  0 part  /boot
└─nvme0n1p2          259:2    0 465.3G  0 part  
  └─cryptroot        254:0    0 465.3G  0 crypt 
    ├─vgspace-lvswap 254:1    0    17G  0 lvm   [SWAP]
    └─vgspace-lvroot 254:2    0 448.3G  0 lvm   /

/etc/mkinitcpio.conf
MODULES=(i915)
BINARIES=()
FILES=()
HOOKS=(base udev autodetect modconf block consolefont keymap keyboard encrypt lvm2 filesystems fsck)

please post also your /etc/default/grub file

If there is no GRUB_CMDLINE_LINUX_DEFAULT with your cryptdevice it's normal to reset.

I don't use grub. I use systemd-boot as my bootloader.

Then you might like sdboot package in repos. You should've begun with the fact that you are using systemd-boot. It is a halfway supported configuration, that requires some technical expertise.

As a matter of fact, I did preface it with me using systemd-boot as you can see in the thread title.

I had no issues with with this bootloader until the recent updates.

2 Likes

@Chrysostomus
Previously, entries.conf needed to be set up manually upon a new kernel. If I am not mistaken, @dalto and you worked on automatic updates of systemd-boot and refind.

I did not follow the process as I needed a manual change to both my systemd-boot and my refind boot entries.

Any idea on this?
If I'm mistaken, apologies.

There is another topic here where the OP needed to copy kernels and initrd files to a user created directory and do mkinitcpio once again.

I suggested the entries.conf is wrong ( which happen here) but the OP there is of the opinion that the boot and $esp structure is set up wrong.

I forgot the entries are now automatically created and did not occur to me that is the issue.

from the entry name I'm assuming you're using systemd-boot-manager from the community repository, if so, you should add your options to /etc/sdboot-manage.conf under

LINUX_OPTIONS="cryptdevice=UUID=614d4999-66da-48c1-9185-c33355ae3f59:cryptroot:allow-discards"
4 Likes

Thank you, @saedlar93! I believe this will fix the issue for me in the future. I did not know Manjaro had our own special sdboot manager.

Here are my steps to reproduce this :

  1. sdboot-manage gen to generate new entries. They do not have the cryptdevice in options.
  2. Add LINUX_OPTIONS="cryptdevice=UUID=614d4999-66da-48c1-9185-c33355ae3f59:cryptroot:allow-discards" to /etc/sdboot-manage.conf
  3. Rerun sdboot-manage gen and confirmed they now have the cryptdevice options.

This led me to consider that systemd-boot-manager may have been updated recently. And it looks like there was a recent commit about 2 weeks ago. It looks like the changes (particularly on line 105-106 of sdboot-manage) changed how it handles LUKS, especially with "ext4 on LVM on LUKS." Could someone else that is smarter than me take a look at this (ie @dalto)?

That should be handled automatically but I just merged a bunch of fixes for crypt devices a couple of weeks ago in master. I haven't had time to fully test them though so they haven't been released yet.

Dalto, are you talking about this commit that you merged into systemd-boot-manager a few weeks ago?

If so, it looks like this has already been released in stable. My /bin/sdboot-manage is exactly the same as the one on gitlab. And according to my pacman logs, was most recently updated on 10/10.

pacman -Si systemd-boot-manager
Repository      : community
Name            : systemd-boot-manager
Version         : 0.7-2
Description     : A simple tool to maintain systemd-boot & systemd-boot entries for
                  Manjaro
Architecture    : any
URL             : https://gitlab.com/dalto.8/systemd-boot-manager
Licenses        : GPL2
Groups          : None
Provides        : None
Depends On      : systemd  findutils  grep  gawk
Optional Deps   : None
Conflicts With  : None
Replaces        : None
Download Size   : 18.77 KiB
Installed Size  : 40.00 KiB
Packager        : Philip Mueller <philm@manjaro.org>
Build Date      : Mon 30 Sep 2019 09:12:50 AM EDT
Validated By    : MD5 Sum  SHA-256 Sum  Signature

Hmm...well, I guess someone packaged the latest code from master that I hadn't tested yet. Seems like it still needs some adjustments on the luks/lvm side.

I guess that may have happened because when I did the first release I hadn't tagged anything so the PKGBUILD was pointed at master and it got rebuilt. We probably should update it to pull off the release tags.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by