"depmod: WARNING" after kmod update

[Haagen-Dazs]

Is this a new report?

Yes

System Info

Void 5.18.14_1 x86_64 AuthenticAMD uptodate FFF

Package(s) Affected

kmod-30_1

Does a report exist for this bug with the project's home (upstream) and/or another distro?

https://groups.google.com/g/linux.debian.bugs.dist/c/7hZiQYDXaiI

Expected behaviour

No errors given after sudo xbps-reconfigure -fa

Actual behaviour

depmod: WARNING: could not open modules.builtin.modinfo at /var/tmp/dracut.../initramfs/lib/modules/5.18.14_1: No such file or directory

Steps to reproduce

sudo xbps-install -Su sudo xbps-reconfigure -fa

[Haagen-Dazs]

Latest dracut v.056 seems to have this covered, not tested though:

dracut-init.sh line 1001:

dracut_kernel_post() { for _f in modules.builtin modules.builtin.alias modules.builtin.modinfo modules.order; do [[ -e $srcmods/$_f ]] && inst_simple "$srcmods/$_f" "/lib/modules/$kernel/$_f" done

[TeusLollo]

Could have sworn it was me causing this due to messing with the /etc/modprobe.d/ directory, but it appears not. Here's my output when I updated to package linux5.15-5.15.59_1:

linux5.15-5.15.59_1: configuring ...
Executing post-install kernel hook: 10-dkms ...
Available DKMS module: vhba-module-20211218.
Building DKMS module: vhba-module-20211218... done.
Installing DKMS module: vhba-module-20211218... done.
Executing post-install kernel hook: 20-dracut ...
depmod: WARNING: could not open modules.builtin.modinfo at /var/tmp/dracut.FBnZ1r/initramfs/lib/modules/5.15.59_1: No such file or directory
Mode:                     real
Method:                   sha256
Files:                    2380
Linked:                   190 files
Compared:                 0 xattrs
Compared:                 3398 files
Saved:                    17.43 MiB
Duration:                 0.231233 seconds
Executing post-install kernel hook: 50-efibootmgr ...
Executing post-install kernel hook: 50-grub ...
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.15.59_1
Found initrd image: /boot/initramfs-5.15.59_1.img
Found linux image: /boot/vmlinuz-5.15.57_1
Found initrd image: /boot/initramfs-5.15.57_1.img
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
done
linux5.15-5.15.59_1: updated successfully.
linux5.15-headers-5.15.59_1: configuring ...
linux5.15-headers-5.15.59_1: updated successfully.

Using the following packages:

dracut-053_2
kmod-30_1

This output was generated circa 24 hours ago. Feel free to delete this if it's not relevant anymore

[Haagen-Dazs]

This output was generated circa 24 hours ago. Feel free to delete this if it's not relevant anymore

It is still relevant, dracut is still not patched for the kmod update. mkinitcpio is already patched though.

[TeusLollo]

I guess the needs-testing label could be removed then, since there's at least two users with this problem (I guess that is the practice around here, correct me if I'm wrong).

Honestly, I hope Void devs could eventually join forces with Alpine/Devuan/Gentoo devs and maintain mkinitcpio together, since dracut is going deeper into systemd hard-requirements.

[Haagen-Dazs]

Honestly, I hope Void devs could eventually join forces with Alpine/Devuan/Gentoo devs and maintain mkinitcpio together, since dracut is going deeper into systemd hard-requirements.

Booster is also a great alternative written in Go, I personally use it on Arch and so far I did not have any issues with it.

[ahesford]

1. mkinitcpio is an Arch project and works fine with Void as is. I personally use mkinitcpio on most of my systems, even as the foundation of my ZFSBootMenu images, and have a vested interest in making sure it stays that way. But there's no need to attempt to take ownership over from Arch.
2. Has anybody shown that this warning actually indicates a problem with the initramfs image? It says "WARNING" right in the text, and even before I pulled the mkinitcpio patch from upstream, I confirmed that expected kernel modules made their way into initramfs images.
3. Somebody is welcome to PR a backport of the fix to our current dracut pending a full update. (It won't be me because I no longer have installations that will let me meaningfully test the patch.) Otherwise, as I noted when closing an untested PR to bump the dracut package, a full update requires more extensive testing and will hopefully be done once a core member finds some time and interest to take up the matter. (Documenting that this causes a real problem beyond spitting out some warnings will almost certainly increase the sense of urgency there.)

[TeusLollo]

1. I was not suggesting a "takeover", at best a fork. In previous months, although I can't find a link anymore, one of the Void devs was saying that mkinitcpio was under-maintained, thus Arch devs were planning to switch fully to dracut, which however is going deeper into systemd hard-dependencies. That's obviously concerning for Void Linux, and I had never heard of booster.
2. Even then, sometimes dracut, at least on certain of my systems, fails loading the intel_pstate driver, although it's totally random and can't be replicated. This never happened when I used Arch with mkinitcpio, hence I assumed it was further proof of dracut ditching non-systemd support.
3. Hell, I thought mkinitcpio on Void was somewhat of an experimental/it's your problem approach, but it seems I was wrong and it's fully supported instead. I may actually try it.
4. Or I may go with the new boy in town, booster

I just wanted to remark that I was not suggesting any "takeoverist" approach. I was just wishing for developers not to depend upon software that appears to be hostile towards non-systemd approaches. Hell, the whole eudev story is similar, so I was just presuming eventually a similar joint-effort approach would appear for inittramfs generators, which may not be necessary anymore with the arrival of the new boy in town, booster.

[MaMiMa81]

Latest dracut v.056 seems to have this covered, not tested though:

dracut-init.sh line 1001:

dracut_kernel_post() { for _f in modules.builtin modules.builtin.alias modules.builtin.modinfo modules.order; do [[ -e $srcmods/$_f ]] && inst_simple "$srcmods/$_f" "/lib/modules/$kernel/$_f" done

Good Afternoon Regarding this issue and taking into account what has been mentioned by @ahesford that a full update of dracut to v.56 will require extensive testing - especially as it appears that it is moving to be more systemd centric - plus this will also put more demand upon core devs, would not a simple & sensible course of action just be to administer a basic patch to the existing dracut v.53:

    985  - for _f in modules.builtin.bin modules.builtin modules.order; do

    985  + for _f in modules.builtin.bin modules.builtin modules.builtin.modinfo modules.order; do

I wouldn't know how to set this up correctly in a patch & submit it for inclusion as a new 'revision'??? - I could hazard a guess by looking around but that's just what it would be. I am no programmer & this is purely a effort to perhaps solve this in the easiest manner. As, how shall we say a 'lay-person', I shouldn't of thought this wouldn't have too much, if any, ramifications on things - but again quite frankly that is pretty much a guess, the much more knowledgable amongst you here will have more of an idea - I merely put it forward as a suggestion to try and help.

Also regarding @ahesford:

3. ........ (Documenting that this causes a real problem beyond spitting out some warnings will almost certainly increase the sense of urgency there.)

See here:

https://groups.google.com/g/linux.debian.bugs.dist/c/7hZiQYDXaiI

#Michael Biebl unread, Jul 7, 2022, 11:40:03 AM to

Control: severity -1 important

On Mon, 04 Jul 2022 15:01:13 +1000 Konomi Kitten [email protected] wrote:

Package: initramfs-tools Version: 0.141 Severity: minor X-Debbugs-Cc: [email protected]

When update-initramfs runs I receive the following message:

depmod: WARNING: could not open modules.builtin.modinfo at /var/tmp/mkinitramfs_vBlw4a/lib/modules/5.18.0-2-amd64: No such file or directory

Unfortunately this is not a minor issue, as it breaks the autopkgtest suite of initramfs-tools and thus prevents kmod from entering testing (and dependent packages like systemd [1] as well).

It would thus be great to have the patch in [2] applied and uploaded soon. I can offer to NMU if available time is an issue.

Regards, Michael

So it is probably of some importance that this is attended to. Incidently I have currently downgraded to kmod v.29 as alluded to in that linked bug report.

[TeusLollo]

I'm going to leave the following as MY OWN PERSONAL OPINIONS and SUGGESTIONS:

1. It was always known that dracutwas growing more and more systemd-centric. I recall Void Devs having a discussion on github about it (Which I can't find anymore, it would be useful if someone could eventually link it). Eventually, it was anticipated something would break due to some systemd-based mishap.

2. Given the current situation, this dracut update will require extensive testing, putting a lot of pressure on core devs. However, there's no guarantee a further dracut update down the line (Maybe even the next one) will not require another extenuating testing session, further undercutting core dev development time which could be spent anywhere else, assuming also that next version dracut won't be systemd-only at all, knowing also how much of a moving target systemd is.

3. At this point, since mkinitcpio does not seem under-maintained anymore, and since the new booster, although not as minimalist as mkinitcpio, seems also to work reasonably well, I would say to just jump ship, and prepare to switch to a mkinitcpio configuration by default for Void Linux, with boosteras supported yet experimental (It still has some maturing to do, it's very recent), and dracut as unsupported due to excessive systemd dependencies.

4. To me, gradually dropping dracut in favor of alternatives will eventually become necessary anyway due to systemd woes, and this would be a reasonable occasion to jump ship. None will blame Void Devs, since it's known how dracut has grown to become increasingly unresponsive to non-systemd approaches. Also, even should eventually mkinitcpio be dropped by its original author/maintainer, it wouldn't be catastrophically difficult to perform some maintenance along with Alpine/Gentoo/Devuan devs, even if Arch too abandons mkinitcpio. Furthermore, the maturing booster would also provide a further safety net, if not as minimalist.

I would say thus to minimize chances of potentially wasting time, efforts, and energy into something that tomorrow may very well grow into yet another systemd (Sarcasm MODE ON) "non-monolithic binary" (Sarcasm MODE OFF), and concentrate efforts into mkinitcpio and booster. In fact, it probably has not been this favorable switching to less conventional initramfs for Linux Distros in quite a few years, if not decades, thus I would say to just jump ship.

In every case, I would like to thank both Void Devs and the entire Void Community for devoting their time and efforts into something excellent which has earned to only rely on the best.

Now, it would be useful if one of the Core Devs could chime in, possibly. Thanks for reading, and remember: the aforementioned are just MY OWN PERSONAL OPINIONS and SUGGESTIONS.

[MaMiMa81]

Well after what had been mentioned on this thread above by @Haagen-Dazs, @ahesford & @TeusLollo about using mkinitcpio I thought I'd have a go at replacing dracut with it.

Made dracut an ignorepkg, removed it, installed mkinitcpio, did xbps-reconfigure -f linux<X.Y> rebooted & mess - root partitioned would only mount as ro & then it was loop mounted to /media/<OS_LABEL> & I was dumped into the rescue console.

I managed to boot in the system, by repeatedly entering exit & found the other 2 partitions plus swap also mounted the /media/ directory.

Spent best part of a day trying to sort it before restoring from a backup.

So what I have done now,after taking a backup of the file, is manually edit the /usr/lib/dracut/dracut-init.sh:

Replacing line 985

for _f in modules.builtin.bin modules.builtin modules.order; do

with

for _f in modules.builtin.bin modules.builtin modules.builtin.modinfo modules.order; do

I then re-upgraded kmod & libkmod from v.29 to v.30, tested it out with a new install of a kernel & works as normal with no:

depmod: WARNING:

If I find any issues I'll post here - or if anyone has any comment what I've done - good or bad please do likewise.

[ahesford]

Somebody is welcome to PR a fix. But, again, has anybody demonstrated that these warnings actually lead to a problem with the initramfs image? Problems with Debians test suite for initramfs-tools are of no consequence here.

[TeusLollo]

I managed to boot in the system, by repeatedly entering exit & found the other 2 partitions plus swap also mounted the /media/ directory.

Would you care to post more info? The fact that system fstab was ignored, and partitions were mounted into /media/ as RO in loopback, would point towards mkinitcpio initializing your system as if it were a Live Image. Maybe you have void-mklive installed? Maybe there's some other hook at work? Weird.

Anyway, I'm inclined to believe your problem with mkinitcpio was more of a mis-configuration case.

[MaMiMa81]

@TeusLollo

I managed to boot in the system, by repeatedly entering exit & found the other 2 partitions plus swap also mounted the /media/ directory.

Would you care to post more info? The fact that system fstab was ignored, and partitions were mounted into /media/ as RO in loopback, would point towards mkinitcpio initializing your system as if it were a Live Image. Maybe you have void-mklive installed? Maybe there's some other hook at work? Weird.

Anyway, I'm inclined to believe your problem with mkinitcpio was more of a mis-configuration case.

Well wasn't going to stray to much away from the core issue - the dracut depmod warning - but regarding mkinitcpio your conclusion may well be right.

Since I did the mkinitcpio install I have seen this post here:

https://reddit.com/r/voidlinux/comments/ql2les/void_console_font/hj07qmo/#c

Specifically @ahesford :

If you want to use mkinitcpio, we ship a kernel hook to generate the initramfs on kernel upgrades. Just xbps-reconfigure -f linux<X.Y> after installing mkinitcpio. Also, to /etc/default/initramfs-regenerate add INITRAMFS_GENERATOR=mkinitcpio so packages that otherwise trigger initramfs regeneration do the right thing.

While I did xbps-reconfigure -f linux<X.Y> I didn't add INITRAMFS_GENERATOR=mkinitcpio to /etc/default/initramfs-regenerate firstly the file didn't exist & I thought the file /usr/libexec/xbps-triggers/initramfs-regenerate had it covered - but on re-reading the file it states that it uses dracut by default so it looks like it is necessary to specify INITRAMFS_GENERATOR=mkinitcpio at /etc/default/initramfs-regenerate. I assume this should be done before xbps-reconfigure -f linux<X.Y> & perhaps xbps-reconfigure -fa wouldn't hurt actually. So here I may well of not correctly configured mkinitcpio & it lead to the issues I experienced.

Maybe you have void-mklive installed? Maybe there's some other hook at work?

No I don't have void-mkliveinstalled & I am unaware of any other hook at work & from when I checked it appeared that dracut was completely uninstalled.

Upon booting as I said it flagged up the issue that the root partition was only mounted RO & I was dropped into a rescue console with a message that it was unable to carry out fsck on the other partitions (I can't remember whether I stated that the root partition had been subjected to fsckor not - probably not that's maybe why it was mounted RO). After a bit of research I booted from a Live Image to fsck the partitions on my HDD & they were all OK. But as I have stated I spent a considerable amount of time trying to sort the issue without success so I just re-installed from a backup. So it's quite possible that what I have stated above was the issue - maybe @ahesford could add some input here as from what I understand he uses mkinitcpio on his systems?

@ahesford

Problems with Debians test suite for initramfs-tools are of no consequence here.

OK accept that &

has anybody demonstrated that these warnings actually lead to a problem with the initramfs image?

No I haven't - but then again I don't know if it is causing issues I haven't noticed or been subjected to? Or will cause issues going forward. I have have changes to my system now - initially by downgrading kmod to v.29_2 (as it is a similar vintage to dracut v.53_2) but subsequently re-upgrading kmod to v.30 & amending the /usr/lib/dracut/dracut-init.sh file as per posts above - so maybe others may wish to comment here whether or not they have experienced problems?

Somebody is welcome to PR a fix.

Indeed - but for me - please see my first post in this thread.

[TeusLollo]

@ahesford

I believe info regarding initramfs generators, particularly the /etc/default/initramfs-regenerate add INITRAMFS_GENERATOR=mkinitcpio bit posted on Reddit, should go into the Void Handbook. There's no simple way to guess that otherwise, even given we're an "advanced" Linux Distro.

Regardless of that, thanks for all your work, and have a nice day.