Moving automatic mkinitcpio into a hook, for extra initcpio modules

SAL9000 · 2016-06-29 08:36:52

I'm running an Arch system with root on ZFS.
This means that during a kernel upgrade, the mkinitcpio run which occurs as part of the package install script is "wasted", as it occurs before the DKMS modules for ZFS are built for the new kernel.

In order to reduce administrative burden and duplicate operations, I believe that mkinitcpio should run as a Pacman hook, after DKMS modules are built.

As an interim or alternative solution, I'd like some advice on how to implement such a hook myself; it should run in two cases -- a kernel install/upgrade or a DKMS module install/upgrade.

P.S: This is also applicable to non-DKMS external kernel modules -- there's a pretty good chance of the kernel install (and thus mkinitcpio) running before external kernel module packages are updated.

Edited (Wed Jun 29 11:29 UTC 2016): 2s/after/before/ thanks @Lone_Wolf!

Last edited by SAL9000 (2016-06-29 11:31:15)

Lone_Wolf · 2016-06-29 10:53:36

In the first paragraph, i think you meant before instead of after ?

In arch-dev-public thread, it was concluded that a general mkinitcpio hook wouldn't work.
every kernel should use it's own customized hook.

man alpm-hooks has details about pacman hooks.

SAL9000 · 2016-06-29 11:52:11

Lone_Wolf wrote:

In the first paragraph, i think you meant before instead of after ?
In arch-dev-public thread, it was concluded that a general mkinitcpio hook wouldn't work.
every kernel should use it's own customized hook.
man alpm-hooks has details about pacman hooks.

Thanks for the catch; edited.

Having looked at that mailing-list link, I now realise that the mkinitcpio calls are, in fact, under the control of mkinitcpio itself rather than the kernel packages; thus, my idea can be implemented without changes to the kernel packages (by masking the mkinitcpio script).

% pacman -Qo /usr/lib/kernel/install.d/50-mkinitcpio.install
/usr/lib/kernel/install.d/50-mkinitcpio.install is owned by mkinitcpio 19-1

I've looked at that man-page -- I'm asking for advice concerning the choice of suitable triggers etc. for this particular purpose, as the man-page does not provide any relevant recommendations or examples.

Here's my first attempt.

[Trigger]
Operation = Install
Operation = Upgrade
Type = Package
Target = linux
Target = linux-lts
Target = linux-zen
Target = *-dkms
[Action]
Description = Build initcpio
When = PostTransaction
Depends = mkinitcpio
Exec = /usr/bin/mkinitcpio -P

Last edited by SAL9000 (2016-06-29 12:17:14)

Lone_Wolf · 2016-06-30 20:14:33

SAL9000,

I feel you are be moving to fast and need to do some analysis before starting on .service files .

Is this intended to be a general solution or a custom one tailored for a specific setup ?
The first is much much harder then the last, i'll assume a custom solution for now.

delaying the rebuilding of mkinitcpio is only needed if things that are needed in initramfs are not included in the kernel.
(example : virtualbox modules are rarely used in initramfs, no need to build it when they are updated.)

mkinitcpio allows 3 kinds of inclusions: modules , binaries and files .
Whether they are updated from binary packages, dkms-builds , manual editing , usb sticks , superheroes or BEMs is not important.

Analyse your setup and show us which changes should trigger mkinitcpio rebuild for you.

SAL9000 · 2016-07-01 14:55:34

Lone_Wolf wrote:

Is this intended to be a general solution or a custom one tailored for a specific setup ?
The first is much much harder then the last, i'll assume a custom solution for now.

I'm aiming for a custom solution, but I hope that this would eventually progress to a more general solution.

Lone_Wolf wrote:

delaying the rebuilding of mkinitcpio is only needed if things that are needed in initramfs are not included in the kernel.
(example : virtualbox modules are rarely used in initramfs, no need to build it when they are updated.)

As I stated in my first paragraph, I'm running with root on ZFS (and no boot partition, thanks to grub-git). This means that the ZFS modules must be in the initramfs, and I am assuming that they must be the same version as those outside of initramfs (at least due to possible compatibility issues with the respective userspace utilities).

Lone_Wolf wrote:

mkinitcpio allows 3 kinds of inclusions: modules , binaries and files .
Whether they are updated from binary packages, dkms-builds , manual editing , usb sticks , superheroes or BEMs is not important.
Analyse your setup and show us which changes should trigger mkinitcpio rebuild for you.

I'd like to:

1) Avoid mkinitcpio rebuild as part of kernel install, because it usually (when part of -Syu) makes an unbootable or outdated initramfs

This can be done by disabling/removing the upon-kernel-install script installed by the mkinitcpio package

% pacman -Qo /usr/lib/kernel/install.d/50-mkinitcpio.install
/usr/lib/kernel/install.d/50-mkinitcpio.install is owned by mkinitcpio 19-1

2) Trigger mkinitcpio upon kernel upgrade after DKMS builds the ZFS modules for the new kernel (instead of #1 above)
3) Trigger mkinitcpio upon updates of the DKMS packages, after DKMS builds them

These two goals can be achieved via a pacman hook (my initial implementation thereof is in my previous post).

Lone_Wolf · 2016-07-13 13:47:01

about 1)

I've looked /usr/lib/kernel/install.d and i don't see how the helper scripts there are triggered.
Checking linux, linux-lts & linux-zen they still use *.install files executed by pacman during package install/upgrade/removal phase before hooks are run.
those *.install files call mkinitcpio command directly.

Afaik there's no way to tell pacman to ignore/block the execution of .install files.

about 2) and 3) :
you want the mkinitcpio build to happen AFTER dkms has finished rebuilding the zen modules.

Something like target = zfs-dkms should do that, however there's a catch :

dkms builds for multiple kernels, mkinitcpio only builds initramfs for the running kernel.

You could get around this by using a wrapper to execute mkinitcpio for all installed kernels, but using kernel-specific user supplied customized hooks seems cleaner.

Arch Linux

#1 2016-06-29 08:36:52

Moving automatic mkinitcpio into a hook, for extra initcpio modules

#2 2016-06-29 10:53:36

Re: Moving automatic mkinitcpio into a hook, for extra initcpio modules

#3 2016-06-29 11:52:11

Re: Moving automatic mkinitcpio into a hook, for extra initcpio modules

#4 2016-06-30 20:14:33

Re: Moving automatic mkinitcpio into a hook, for extra initcpio modules

#5 2016-07-01 14:55:34

Re: Moving automatic mkinitcpio into a hook, for extra initcpio modules

#6 2016-07-13 13:47:01

Re: Moving automatic mkinitcpio into a hook, for extra initcpio modules

Board footer