Arch Linux User Repository

Please add some sort of conditional check in the for loop that checks if the kernel has been installed by pacman, similar to https://github.com/anatol/booster/blob/efa0d40e5d5e0d83cdcfd84e3e64c25994d41200/packaging/arch/booster-install#L23

Not having this can cause issues with manually installed kernels (that may have a pkgbase file with strange or conflicting contents, or simply not have one at all), or kernels restored by hooks that work to preserve the active kernel modules until reboot like https://archlinux.org/packages/community/any/kernel-modules-hook/ or https://aur.archlinux.org/packages/mkmm (because it contains a pkgbase with the same name as the pacman installed kernel). EDIT: I only just realized this topic has been brought up in prior comments, well the modified script I have linked below[4] has a solution. Works for me with mkmm, though I can't say I've tested it with kernel-modules-hook.

If someone has installed a kernel by hand (or rather, not through a pacman package) then it is not the job of a pacman hook to build images for it, imo, so this should have no downsides.

I have been using a modified version of the dracut-install script[1] until now that handles this problem, mostly based on booster's version (seen above), though I'll obviously have to rewrite it now to take into account the new vmlinuz Target.

EDIT: Rewritten[4], kept '--no-hostonly-cmdline' based on [5], but I could be wrong in doing so, I don't really understand why someone would want its inverse.

Also, neither the official booster[2] or mkinitcpio[3] install hooks Target systemd updates, I assume your goal is to make sure updated modules like sd-encrypt are embedded in the initramfs? I only mention it because it can cause a lot of rebuilds of images that would otherwise continue to work fine as far as I can tell, and neither of the other initramfs builders seem to care. But I could be wrong, and this is actually a good idea.

[1] https://0x0.st/oX6o.sh

[2] https://github.com/anatol/booster/blob/master/packaging/arch/90-booster-install.hook

[3] https://github.com/archlinux/mkinitcpio/blob/master/libalpm/hooks/90-mkinitcpio-install.hook

[4] https://0x0.st/o8y9.txt or https://gist.github.com/Ghosthree3/5dc926e7f064c8932c5e91563fc886cf

[5] https://wiki.archlinux.org/title/Talk:Dracut#What_is_the_reason_for_--no-hostonly-cmdline?

@tinywrkb Interesting, I'll look into it

any updates on this?

Dracut 054 (package is still outdated) is now also looking in /lib/modules/${KERNEL_VERSION}/initrd when it mounts the initramfs on shutdown.
It might be a good idea to have the hook create the initramfs image in /lib/modules/${KERNEL_VERSION}/initrd and then copy it to /boot.
There are couple of reasons why this might be a good idea:

• System can still complete the shutdown correctly even if something was wrong and /boot wasn't mounted correctly.
• initramfs image will be included in snapshots even if /boot is the EFI partition.
• The kernel image is already installed in /lib/modules/${KERNEL_VERSION}/vmlinuz so it only fits that the initramfs image will also be there.

https://github.com/dracutdevs/dracut/commit/33e27fab59db60b1ca05a0c5b8a51fccb98578e5

p.s. This doesn't affect me directly as I maintain my own dracut hook but it should also be fixed here.

Tested yours and it works for me, granted my situation isn't that complex, I'm only using the linux package. In any case your solution looks a lot cleaner :P

The solution for kernel-modules-hook would be to keep track of the kernel versions to be updated, in the array, instead of the kernel names:

right now we might do kernels+=("linux-zen") but this is inneficient because n line 25 we are looking again for information we have already (looking to get the kernel version), from the kernel name. And it presents a problem when there might be multiple versions of linux (or linux-zen, whatever) because of kernel-modules-hook. In that case we'll have the updated kernel, and the running kernel modules, both having the same pkgbase.

As such, we ignore pkgbase, and use kernel versions instead, ignoring the running one (uname -r). I have a GitHub gist with some proposed modifications to this script. I haven't tested this on my machine with linux-zen and linux-ck. Though I only had one of them installed at a time, it should work with multiple kernels (with different pkgbases)

https://gist.github.com/JpegXguy/c721d345857b45ce84a2e9bf7f023090

I created a kinda hacky workaround for making this work with kernel-modules-hook.
This probably won't be acceptable to add in as it only is aware of use of the linux package (Edit: Though it occurs to me pacman_kver=$(pacman -Q linux) could be changed to pacman_kver=$(pacman -Q ${kernel}, not certain if that would work though) but for anyone who wants to adapt it to their use here's the patch:

--- dracut-install  2021-04-10 15:21:55.000000000 -0500
+++ /usr/share/libalpm/scripts/dracut-install   2021-04-10 15:21:31.426586318 -0500
@@ -25,6 +25,16 @@
 for kernel in "${kernels[@]}"; do
    path="$(grep -lE "^${kernel}\$" /usr/lib/modules/*/pkgbase)"
    version=$(basename "${path%/pkgbase}")
+   path=$(echo ${path} | tr ' ' '\n' | grep ${version})
+   running_kver=$(uname -r)
+   pacman_kver=$(pacman -Q linux)
+   pacman_kver=${pacman_kver:6}
+
+   if [[ ${running_kver} == ${version} ]]; then
+       if [[ ${pacman_kver} != ${running_kver} ]]; then
+           continue
+       fi
+   fi
     read -r pkgbase < "$path"

     install -Dm0644 "/${path%'/pkgbase'}/vmlinuz" "/boot/vmlinuz-${pkgbase}"

Do yourself a favor and add

omit_dracutmodules+=" brltty "

to /etc/dracut.conf.d/yourconf.conf if you are not blind.

Qemu's newly added brltty dependency broke my encrypted ZFS completely and I could not boot due to dracut-pre-mount.service not completing.

Might do the same to LUKS.

my self had issues with systemd-shutdown with that i added rd.brltty=0 in kernel line and added something in cmdline but im not sure atleast shutdown time gone

@merlock Thanks, I read the conversation you linked. But as far as I can tell these files dracut complains about have pretty much always resided at /usr/share/brltty/Input/, so it's not as if something changed between 6.1 and 6.2 with the brltty package adding dracut as an optional dependency; it's just that the brltty-lsinc binary in 6.2 is now looking for these files at /etc/brltty/Input/ and is failing to find them, while in 6.1 it apparently looks for them in the correct place and silently succeeds.

So it still seems to me that either the brltty-lsinc binary has been misconfigured, or that these files had been intended to be moved from /usr to /etc during the update from 6.1 to 6.2, but for some reason the maintainer failed to do so (somewhat more doubtful as the files are read-only).