systemd-boot updater

Can you show me what a working line looks like? If it is detectable, I should be able to add support.

Well, it is quite simple and looks like the following:
cryptdevice=deviceUUID:lvmNAME:allow-discards.
What I also noticed is rw option. For rEFInd I have to use ro, because with rw fsck systemd skips root partition. As far as I know, only grub allows using rw and it does not affect fsck checking of a root partition. Maybe I am wrong and systemd boot also allows this, could you please check? I have a screenshot in order to show what I mean:


The last log entry was generated when booting with ro (rEFInd), all the previous ones are rw/systemd.

systemd-boot-manager 0.8 has been released and includes the following changes.

  • General reformatting and code cleanup(Radoslav Georgiev, dalto)
  • Better support for crypt devices(Radoslav Georgiev, dalto, Rumo)
  • Updated hooks to support changes in mkinitcpio(saedler93, dalto)
  • Added optional support for resume devices(Radoslav Georgiev)
  • Added the ability to customize the title of the entry(Radoslav Georgiev)
  • Fixed a bug that caused entries to not be removed on kernel deletion by default(dalto)
  • Prioritize UUID for device identification(Radoslav Georgiev)
6 Likes

Dalto, where is the repo for systemd-boot?

I want to fix a bug with

            # Search for a crypt device
            while read -r devname devtype; do
                if [[ $devtype == crypt ]]; then
                    # handle cryptdevice
                    sdoptions="${sdoptions} cryptdevice=UUID=$(blkid -o value -s UUID "$(cryptsetup status "${devname}" | grep device | awk '{print $2}')"):${devname}"
                fi
            done < <(lsblk -nslo NAME,TYPE /dev/disk/by-uuid/"${srcdev_uuid}" 2> /dev/null)

the cryptdevice= portion breaks booting if the user has sd-crypt setup with something like rd.luks.uuid=long-string-here on the kernel cmdline

Thanks

What would you think about adding an option to use the current Linux cmdline options for more complex setups?

There is a file /usr/lib/kernel/install.d/90-loaderentry.install ( I think it comes with GRUB) that has something that could be an example:

declare -a BOOT_OPTIONS

if [[ -f /etc/kernel/cmdline ]]; then
    read -r -d '' -a BOOT_OPTIONS < /etc/kernel/cmdline
fi

if ! [[ ${BOOT_OPTIONS[*]} ]]; then
    read -r -d '' -a line < /proc/cmdline
    for i in "${line[@]}"; do
        [[ "${i#initrd=*}" != "$i" ]] && continue
        BOOT_OPTIONS+=("$i")
    done
fi

if ! [[ ${BOOT_OPTIONS[*]} ]]; then
    echo "Could not determine the kernel command line parameters." >&2
    echo "Please specify the kernel command line in /etc/kernel/cmdline!" >&2
    exit 1
fi

As long as it is optional and off by default I would be fine with adding support for it. That being said, what would be the application for that? What is the situation in which the kernel command line would be different from what you had in your entry to begin with?

Sure, let me give you some more context and you can decide.

I have an encrypted drive and setup the sd-encrypt hook in mkinitcpio.conf to unlock it.

The proper cmdline for this includes rd.luks.uuid=long-uuid-here rather than the older cryptdevice=...

I had all of that setup in systemd-boot manually, went to update, couldn't boot, and found that my ESP/boot/loader/entries/*.conf changed unexpectedly, leading me here.

I now have the autogen flag disabled, and am ok with that, but as I was unaware that Manjaro auto-generated systemd-boot entries until I worked my way backwards, I could see someone else breaking their boot process. I figured I'd raise it up.

That is basically the same situation with grub. If you edit the actual grub config instead of /etc/default/grub your changes will get blown away.

Maybe we should put comments in all the entries that note that they shouldn't be edited but instead edit the config file?

Also, if we need a different config for that, we should probably try to detect when we need sd-crypt and manage it automatically.

It seems like the issue isn't that you edited the wrong file. The issue is that systemd-boot-updater doesn't handle your setup. Fixing the latter seems more worthwhile.

That's true; I knew to edit /etc/default/grub in the past.

Now I know it's taboo to say that I read the Arch Wiki about systemd-boot, but I did (I couldn't find information about setting it up in Manjaro), and followed some of the purported best practices there. It seems that they default to managing systemd-boot entries manually; I doubt I'll be the last one to make the mistake of editing them.

Anyhow, that just supports your idea. I think comments in the entries would be excellent, they could point to the config and a (man page?) help file.

I think we should do both.

We can add logic that looks at mkinitcpio.conf to decide the correct cmdline for encrypted partitions. It'll be tough to get advanced setups, but I think I can envision how it might work for simpler setups. Reference -- HOOKS="base systemd autodetect modconf block keyboard sd-vconsole sd-encrypt filesystems"

FWIW, I actually decrypted my /boot/ partition (I have the full disk setup from the Manjaro installer) to install systemd-boot, all with the intention to speed up my boot time. GRUB is really slow. That means at boot I just have to unlock the root partition and swap (/dev/urandom).

5 posts were split to a new topic: Is the "base" hook needed?

Recently I noticed that Updating systemd-boot entries runs twice every time kernels are updated and the first one always fails with the message failed to execute command so I checked pacman log and it seems that the remove hook is the one failing.

[2020-02-05T17:12:20+0000] [ALPM] running 'sdboot-kernel-remove.hook'...
[2020-02-05T17:12:20+0000] [ALPM] running 'sdboot-kernel-update.hook'...

Why is the Remove hook running on upgrades?

I tested the command in a terminal and the return status is always 1

❯❯❯❯ sudo /usr/bin/sdboot-manage remove                                                                                                  ~
❯❯❯❯ echo $?                                                                                                                             ~
1

The only changes I made to the config file are PRESERVE_FOREIGN="yes" to prevent my grml entry from being removed at every update and LINUX_OPTIONS.

Also, in the hooks, File is being deprecated and replaced with Path link1/link2

Good question. It looks like it started happening for me in early November. Did something change with pacman 5.2 in how those hooks are handled or is it a side effect of some other change?

Hmm.....

Interesting. I am not seeing this on any of my physical machines or virtual machines. It does run the extra hook but I don't get any errors, it just doesn't do anything since all the kernels are still there.

1 Like

OK, that was something obvious that I did. I fixed the remove hook being called on update.

However, I still can't reproduce the error you are getting.

1 Like

I did some digging and it seems that because your script assumes name "vmlinuz-*-*", it doesn't detect my grml vmlinuz file that doesn't follow that naming convention.
I think the error is caused by line 48, the return status if PRESERVE_FOREIGN="yes"would be 1, making pacman think that the hook failed to execute.

According to the documentation

Hooks are triggered using the file list of the installed, upgraded, or removed package.

and boot/vmlinuz* isn't owned by any package, so I think you just disabled that hook completely

1 Like

Well, in that case it definitely won't be called on an update. :face_with_monocle:

I pushed another change that hopefully will work. I will test it this weekend and if all is good we can do another release.

I think, generally, I am not paying much attention to return values in the script. It may be doing the right thing but not returning the right value. I will probably have to think through that a little.

1 Like

It seems that it's the intended behavior, see this and this part of the arch wiki

  1. pacman deletes all the files from a pre-existing version of the package (in the case of an upgraded or removed package).

systemd-boot-manager 0.9 has been released and includes the following changes.

  • Added option for continuous discard(Jesai Langenbach)
  • Added support for zfs on luks(dalto)
  • Replaced the deprecated 'File' hook(dalto/saedlar93)
  • Added an exit code if 0 if we reach the end of the script without detecting errors(dalto)
  • Added a workaround for an apparent bug in comm which would cause all entries to be deleted in certain circumstances(dalto)
  • Updated the Manjaro kernel detection pattern to be more specific and made the pattern configurable(dalto)
2 Likes

Forum kindly sponsored by