Arch Linux User Repository

The kernel module folder is left behind after removal of the kernel by pacman, because the initrd is left behind, so we need to remove the folder

With 0.5.3-1, in dracut-remove, are you deleting the user's entire kernel with rm -rf "/usr/lib/modules/${kver}"? Did you mean to delete "/usr/lib/modules/${kver}/initrd" (which would not require --recursive)?

Right now I'm pretty sure if someone uninstalls dracut-hook they'll lose their kernel and corrupt the pacman database.

EDIT: I misunderstood the hook, I see it fires when the pkgbase file is removed by pacman, not when dracut-hook is removed.

True, I removed a comment last-minute and forgot to update the checksum

True, I was sending my test paths though echo with a pipe but I had the leading slash already while pacman doesn't do that. The slash matters for the copying of the kernel and locating the pkgbase file. dracut itself only needs the part about the kernel version.

${lines[-1]} is just to avoid the step of removing /vmlinuz from the path again, before appending /pkgbase. Since I want it without /vmlinuz in the array anyway, let's reuse that.

I know of kernel-modules-hook which actually got promoted to community but uses plain cp, kernel-modules-hook-reflink, which uses reflink but I think that's a BTRFS-only thing, saved-kernel-modules, which uses hardlinks, and mkmm which does the same but I like its structure so I'm testing it out.

Looks good to me, except for: I think the dracut-install hash is wrong (failing check with makepkg), and should the $ in line 13 be prepended by a /?

lines+=("${line%/vmlinuz}") looks like it will fill the array with values like usr/lib/modules/5.16.10-arch1-1, which isn't a valid path, so the for loop will never do anything (and if it did the pkgbase var would not be set properly). I would have thought it would need to be lines+=("/${line%/vmlinuz}"). Unless I misunderstand what the Target is sending as stdin.

Also not that it matters but why did you use ${lines[-1]} instead of just ${line} (which you used for the pkgbase variable below)? I'm pretty sure this makes absolutely no difference for the end product though.

And yes, both of mkmm's methods seem much more efficient than kernel-modules-hook.

You're right, the pacman check should be what solves the issue with having 2 kernel versions with the same pkgbase file.

Also, I'd been looking for a kernel module backup solution that uses hardlinks or something like that, since recreating the files while on the same disk is inefficient. Maybe I'll switch to mkmm

If noone wants it I guess I could append it to the first (hostonly) build as an option. Probably the fallback one disables all hostonly stuff when you pass --no-hostonly. What's your opinion on this?

I'm not too fussed if the --no-hostonly-cmdline is included or not. As you said, it can be disabled with a config option if it's not, though it's probably a better default for most people to append it to the --hostonly line like you're suggesting. You're probably right that --no-hostonly implies it also, though the man page doesn't say as much.

As for pkgbase, doesn't seem bad, what if instead of pacman, I checked whether the pkgbase file exists and if it does, go ahead with dracut? Even if it's not a pacman package, having the files vmlinuz and pkgbase there pretty much conforms to the standard needed here right?

Not quite. Simply checking if the pkgbase file exists isn't good enough because of how (some?) module backup/restore hooks work, ie. copying the /usr/lib/modules/$(uname -r) kernel somewhere while pacman removes it, then copying/linking the directory back in afterwards. As far as I can tell both kernel-modules-hook AND mkmm do this. The pkgbase file still exists, and its contents clashes with the newly installed kernel's.

There's also no reason a user can't have installed a kernel manually and put a pkgbase file and/or the vmlinuz image in the modules directory for some reason (organization, use of a similar script, who knows, maybe a mistake but not one we need to punish them for needlessly).

As I said I can't really see any downside with using a pacman ownership check like I'm using in the script linked in [4] previously, I don't think the pacman hook should be trying to build images for any kernels pacman is not personally managing. It helps that booster's hook is doing exactly this, and that hook is (for whatever reason) included in an official package, so I can't imagine it's 'bad'.

The systemd targeting was already there from the previous commit, not authored by me. That said I kept it because I think dracut uses systemd by default, whereas mkinitcpio in the default configuration doesn't use sd-hooks.

https://aur.archlinux.org/cgit/aur.git/commit/?h=dracut-hook&id=be899e329766f883972335729c709da2c0dbb8ab

I'm with you in that I don't like hostonly-cmdline and always disable it, but I didn't know if the hook should force it on people. I thought maybe everyone who doesn't want it can disable it like so in their dracut configuration:

$ cat /etc/dracut.conf.d/mine.conf 
hostonly_cmdline="no"

Though I do see about the duplication mentioned in the Archwiki Talk thrread. If noone wants it I guess I could append it to the first (hostonly) build as an option. Probably the fallback one disables all hostonly stuff when you pass --no-hostonly. What's your opinion on this?

As for pkgbase, doesn't seem bad, what if instead of pacman, I checked whether the pkgbase file exists and if it does, go ahead with dracut? Even if it's not a pacman package, having the files vmlinuz and pkgbase there pretty much conforms to the standard needed here right?

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?