Skip to main content
Topic: [SOLVED] unable to generate new initcpio's (Read 1767 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

[SOLVED] unable to generate new initcpio's

So I precompiled `linux-mainline` including all docs and headers on a separate machine I have running Artix OpenRC, and then uploaded that to a [GitLab repo](https://gitlab.com/SimPilotAdamT/SimPilotAdamT-Arch-Repo) to install it onto my laptop (also running Artix OpenRC).  Now, every time I try to make use `mkinitcpio` to allow my system to boot, it fails on my `lvm2` and `encrypt` hooks (I need those as my install is encrypted with luks 2) with the error `/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found`. Any ideas?

My initcpio hooks are `base udev autodetect keyboard keymap modconf block lvm2 encrypt filesystems fsck`. I have the latest versions of `lvm2` and `cryptsetup` installed.

NOTE: `mkinitcpio` fails to work properly on all kernels I have, not just `linux-mainline`. I am having issues with `linux-zen`, `linux`, and `linux-xanmod`.

EDIT: just realised markdown doesn't work here lul
Running Artix Linux OpenRC.

Laptop system is a Lenovo/IBM ThinkPad T580 with an i5-8350U, integrated graphics, 32GB of DDR4-2666 memory, and a 1TB WD SN850.

Desktop system is custom built, with an i9-10900K, RTX3080, 32GB of DDR4-3500 16-19-20-37 memory, and a 2TB Samsung 970 Pro.

Re: unable to generate new initcpio's

Reply #1
You could try installing eudev-git from the AUR, it might fix this if it was a udev problem, this has a very small risk of creating an unbootable system, in which case you might need to revert from a chroot, but it's probably going to be fine especially at this precise moment, there have been no commits since the new stable release just over a week ago.
(But I don't really know where the add_udev_rule is supposed to come from,  that line just says:
Code: [Select]
    for _ in "${@:2}"; do
        "$1" "$_" || (( $# > 255 ? r=1 : ++r ))
so it is constructed as required at runtime)

No, forget eudev-git, actually that add_udev_rule appears here:
/usr/lib/initcpio/install/sd-vconsole
41:    add_udev_rule 90-vconsole.rules
but nowhere else... unlike the functions called on the lines above, which appear in the functions file. So I guess your best chance of a quick fix is either add the missing add_udev_rule function to /usr/lib/initcpio/functions by copying it out of some older / newer version of mkinitcpio or delete / comment out the line referencing it in sd-vconsole and hope it works... make sure to copy /boot first because mkinitcpio overwrites the image files in there if you did try something, because working wrong could be worse than not working at all.

Re: unable to generate new initcpio's

Reply #2
You could try installing eudev-git from the AUR, it might fix this if it was a udev problem, this has a very small risk of creating an unbootable system, in which case you might need to revert from a chroot, but it's probably going to be fine especially at this precise moment, there have been no commits since the new stable release just over a week ago.
(But I don't really know where the add_udev_rule is supposed to come from,  that line just says:
Code: [Select]
    for _ in "${@:2}"; do
        "$1" "$_" || (( $# > 255 ? r=1 : ++r ))
so it is constructed as required at runtime)

No, forget eudev-git, actually that add_udev_rule appears here:
/usr/lib/initcpio/install/sd-vconsole
41:    add_udev_rule 90-vconsole.rules
but nowhere else... unlike the functions called on the lines above, which appear in the functions file. So I guess your best chance of a quick fix is either add the missing add_udev_rule function to /usr/lib/initcpio/functions by copying it out of some older / newer version of mkinitcpio or delete / comment out the line referencing it in sd-vconsole and hope it works... make sure to copy /boot first because mkinitcpio overwrites the image files in there if you did try something, because working wrong could be worse than not working at all.

1) can confirm eudev-git was not the issue.....
2) deleting that line still produces that error... Maybe it's also somewhere else?
Running Artix Linux OpenRC.

Laptop system is a Lenovo/IBM ThinkPad T580 with an i5-8350U, integrated graphics, 32GB of DDR4-2666 memory, and a 1TB WD SN850.

Desktop system is custom built, with an i9-10900K, RTX3080, 32GB of DDR4-3500 16-19-20-37 memory, and a 2TB Samsung 970 Pro.

Re: unable to generate new initcpio's

Reply #3
https://bbs.archlinux.org/viewtopic.php?id=183045
https://bugs.archlinux.org/task/60937
The answer there seems to be:
"The systemd hook was not included before the sd-vconsole hook."
But that doesn't sound too encouraging on a non-systemd distro!
Downloading the mkinitcpio repo, $ git grep 'add_udev_rule' $(git rev-list --all) seems to say that line has been there since 2016 and not anywhere else.
It might be worthwhile opening an issue here, unless anyone else here can come up with some better suggestions:
https://github.com/archlinux/mkinitcpio/issues


Code: [Select]
commit 8d1d5cce87cec6038dfc42c93e1c65b486bff16f (HEAD)
Author: Jan Alexander Steffens (heftig) via arch-projects <[email protected]>
Date:   Tue Nov 22 20:34:39 2016 +0100

    sd-vconsole: Use udev activation
   
    systemd v232 only activates systemd-vconsole-setup via udev. Follow this
    to make sure things work properly. This also obsoletes the modules-load
    hack.
   
    https://github.com/systemd/systemd/issues/4699

$ git diff 8d1d5cce87cec6038dfc42c93e1c65b486bff16f^
diff --git a/install/sd-vconsole b/install/sd-vconsole
index 93cbbcd..8c01ffb 100644
--- a/install/sd-vconsole
+++ b/install/sd-vconsole
@@ -34,10 +34,11 @@ add_keymap_file() {
 }
 
 build() {
-    add_systemd_unit systemd-vconsole-setup.service
+    add_binary /usr/lib/systemd/systemd-vconsole-setup
     add_binary loadkeys
     add_binary setfont
     add_file /etc/vconsole.conf
+    add_udev_rule 90-vconsole.rules
 
     # subshell to avoid namespace pollution
     (
@@ -56,12 +57,6 @@ build() {
             done
         fi
     )
-
-    # Set up the console only after any manually loaded GPU drivers (e.g. i915)
-    add_systemd_drop_in systemd-vconsole-setup.service after-modules <<EOF
-[Unit]
-After=systemd-modules-load.service
-EOF
 }
 
 help() {

Re: unable to generate new initcpio's

Reply #4
It might be worthwhile opening an issue here, unless anyone else here can come up with some better suggestions:
https://github.com/archlinux/mkinitcpio/issues

Since it hinders ability to use the distro looks like I'll have to....
Running Artix Linux OpenRC.

Laptop system is a Lenovo/IBM ThinkPad T580 with an i5-8350U, integrated graphics, 32GB of DDR4-2666 memory, and a 1TB WD SN850.

Desktop system is custom built, with an i9-10900K, RTX3080, 32GB of DDR4-3500 16-19-20-37 memory, and a 2TB Samsung 970 Pro.

Re: unable to generate new initcpio's

Reply #5
Two solutions.
The first is to roll back cryptsetup one version back (cryptsetup 2.4.1-1 from cryptsetup 2.4.1-3)
The second is to fix install hook (/usr/lib/initcpio/install/encrypt).
Code: [Select]
    add_binary 'cryptsetup'

    map add_udev_rule \
        '10-dm.rules' \
        '13-dm-disk.rules' \
        '95-dm-notify.rules' \
        '/usr/lib/initcpio/udev/11-dm-initramfs.rules'

    # cryptsetup calls pthread_create(), which dlopen()s libgcc_s.so.1
    add_binary '/usr/lib/libgcc_s.so.1'

    add_runscript
to
Code: [Select]
add_binary "cryptsetup"
    add_binary "dmsetup"
    add_file "/usr/lib/udev/rules.d/10-dm.rules"
    add_file "/usr/lib/udev/rules.d/13-dm-disk.rules"
    add_file "/usr/lib/udev/rules.d/95-dm-notify.rules"
    add_file "/usr/lib/initcpio/udev/11-dm-initramfs.rules" "/usr/lib/udev/rules.d/11-dm-initramfs.rules"

    # cryptsetup calls pthread_create(), which dlopen()s libgcc_s.so.1
    add_binary "/usr/lib/libgcc_s.so.1"

    add_runscript
After fixing the hook, create a new initramfs (mkinitcpio -p yourkernel).
Unfortunately, I have no time to create commits, I hope it will be done by someone who has time and the developers will fix the cryptsetup package in their repository.

Re: unable to generate new initcpio's

Reply #6
Brilliant answer, thanks! The only other thing I could think of was switch to dracut and see if that helped ;D 
That file is not a part of cryptsetup upstream, it's a script included with the Arch package. It's been copied across to the latest Artix version:
https://gitea.artixlinux.org/packagesC/cryptsetup/src/branch/master/x86_64
At  this precise moment the problem version is still in the 'testing' dir at that url, later it will be merged into 'core' and the 'testing' entry will disappear until some new version joins the queue. No need to worry about PR's there as only Artoo and friends have the keys to that repo.
Actually I suspect that missing add_udev_rule could cause other problems from it being referenced elsewhere. The function comes from here:
https://github.com/archlinux/svntogit-packages/blob/packages/systemd/trunk/initcpio-install-udev
But you see there's already an unmerged pr to include it in mkinitcpio which might result in an upstream fix:
https://github.com/archlinux/mkinitcpio/pull/54
Another option could be to add that pr (if it fixes the issue) as an Artix patch.

Re: unable to generate new initcpio's

Reply #7
Noted, cryptsetup and lvm2 won't move stable until fixed, probably tonight.

Re: unable to generate new initcpio's

Reply #8
Should be fixed with eudev-249.5-2 in gremlins.
I opted to wait for arch including the function upstream mkinitcpio, which then needs an artix patch anyway. ;)
Atm, eudev initcpio has the function.

Re: unable to generate new initcpio's

Reply #9
Closing this topic as the issue as been resolved.

Should be fixed with eudev-249.5-2 in gremlins.

This indeed was what fixed it.

Note to anyone of the future having the same error message: this thread will be a dead end for you as this was an issue with the actual eudev package in the Artix repo's, not something that could be fixed using a few commands.
Running Artix Linux OpenRC.

Laptop system is a Lenovo/IBM ThinkPad T580 with an i5-8350U, integrated graphics, 32GB of DDR4-2666 memory, and a 1TB WD SN850.

Desktop system is custom built, with an i9-10900K, RTX3080, 32GB of DDR4-3500 16-19-20-37 memory, and a 2TB Samsung 970 Pro.