Arch Linux User Repository

Wait, did dracut arch package never provided pacman hooks? I used dracut before and it got triggered by the kernel updates just fine but stopped working some time ago. Why did that happened?

@dngray First time I've heard of this tool. Interesting, but personally I like having the one kernel with multiple options for the initrd image.

People here should switch to dracut-ukify which uses systemd's ukify tool and provides similar experience.

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?