[SOLVED] initramfs outdated & not updated after package upgrade

mgb · 2014-11-25 17:43:32

I upgraded kmod:

[2014-11-24 21:23] [PACMAN] upgraded kmod (18-2 -> 19-1)

kmod is include in initramfs:

$lsinitcpio initramfs-linux.img | grep kmod
./usr/bin/kmod
./usr/lib/libkmod.so.2

initramfs is from:

$ls -al /boot/initramfs-linux.img 
-rw-r--r-- 1 root root 3202807 Nov 22 01:56 /boot/initramfs-linux.img

/usr/bin/kmod has changed:

$stat $(which kmod) | grep -e File -e Change
  File: '/usr/bin/kmod'
Change: 2014-11-24 21:23:23.728539871 +0100

But initramfs was not updated / mkinitcpio was not called.

From my understanding initramfs should contain actual binaries and should be updated when binaries form real file system (& included in initramfs) are updated.

Am I missing something? Should I run mkinitcpio after every upgrade - or compare real file system vs. initramfs after every upgrade?

From a short check these /usr/bin files are outdated in my current initramfs:

/usr/bin/kmod
/usr/bin/systemctl
/usr/bin/systemd-tmpfiles
/usr/bin/udevadm

Last edited by mgb (2014-11-26 22:44:23)

Scimmia · 2014-11-25 18:04:41

mgb wrote:

From my understanding initramfs should contain actual binaries and should be updated when binaries form real file system (& included in initramfs) are updated.

Not exactly. The only time the initramfs gets automatically regenerated is when the kernel gets updated; it's required then for module compatibility. Any other updates don't generally matter much, so it's most likely not worth regenerating it until the next kernel update.

nomorewindows · 2014-11-25 21:49:12

Probably didn't mount /boot.

Scimmia · 2014-11-25 22:24:56

nomorewindows wrote:

Probably didn't mount /boot.

I'm curious, why would that matter?

nomorewindows · 2014-11-26 00:49:03

Some people forget to make a separate entry in /etc/fstab for /boot. Then when they mkinitcpio they don't mount the original /boot that they started with, and the new files are on /.

Scimmia · 2014-11-26 00:55:07

nomorewindows wrote:

Some people forget to make a separate entry in /etc/fstab for /boot. Then when they mkinitcpio they don't mount the original /boot that they started with, and the new files are on /.

OK, but how does that apply here?

nomorewindows · 2014-11-26 02:01:40

OP is probably a noob. Only one post. This is a common mistake and the initramfs is in /boot. When there is an inconsistency between /usr and /boot files, this would probably be it. OP is welcome to try mkinitcpio -p linux, to see if that's all they need here.

mgb · 2014-11-26 02:54:03

Scimmia wrote:

Any other updates don't generally matter much, so it's most likely not worth regenerating it until the next kernel update.

But what about systemd & udev - when used in early userspace?

Background / details / my configuration:

mkinitcpio uses systemd in initramfs

$grep ^HOOKS mkinitcpio.conf 
HOOKS="systemd autodetect modconf block filesystems sd-vconsole fsck"

some systemd / udev related binaries and unit files in initramfs:

$lsinitcpio initramfs-systemd.img | grep -e udev -e init -e systemd
./init
./usr/bin/udevadm
./usr/bin/systemd-tmpfiles
./usr/lib/udev
./usr/lib/udev/scsi_id
./usr/lib/udev/ata_id
./usr/lib/udev/rules.d
./usr/lib/udev/rules.d/99-systemd.rules
./usr/lib/udev/rules.d/80-drivers.rules
./usr/lib/udev/rules.d/64-btrfs.rules
./usr/lib/udev/rules.d/60-persistent-storage.rules
./usr/lib/udev/rules.d/50-udev-default.rules
./usr/lib/systemd
./usr/lib/systemd/systemd-vconsole-setup
./usr/lib/systemd/systemd-udevd
./usr/lib/systemd/systemd-journald
./usr/lib/systemd/systemd-hibernate-resume
./usr/lib/systemd/systemd-fsck
./usr/lib/systemd/system
./usr/lib/systemd/system/systemd-vconsole-setup.service
./usr/lib/systemd/system/ctrl-alt-del.target
./usr/lib/systemd/system/default.target
./usr/lib/systemd/system/timers.target
./usr/lib/systemd/system/systemd-udevd.service
./usr/lib/systemd/system/systemd-udevd-kernel.socket
./usr/lib/systemd/system/systemd-udevd-control.socket
./usr/lib/systemd/system/systemd-udev-trigger.service
./usr/lib/systemd/system/systemd-tmpfiles-setup-dev.service
./usr/lib/systemd/system/systemd-journald-dev-log.socket
./usr/lib/systemd/system/sockets.target.wants
./usr/lib/systemd/system/sockets.target.wants/systemd-udevd-kernel.socket
./usr/lib/systemd/system/sockets.target.wants/systemd-udevd-control.socket
./usr/lib/systemd/system/sockets.target.wants/systemd-journald-dev-log.socket
./usr/lib/systemd/system/sockets.target.wants/systemd-journald.socket
./usr/lib/systemd/system/systemd-journald.socket
./usr/lib/systemd/system/systemd-journald.service
./usr/lib/systemd/system/systemd-hibernate-resume@.service
./usr/lib/systemd/system/systemd-fsck@.service
./usr/lib/systemd/system/swap.target
./usr/lib/systemd/system/sockets.target
./usr/lib/systemd/system/slices.target
./usr/lib/systemd/system/paths.target
./usr/lib/systemd/system/local-fs-pre.target
./usr/lib/systemd/system/emergency.service
./usr/lib/systemd/system/emergency.target
./usr/lib/systemd/system/local-fs.target
./usr/lib/systemd/system/sysinit.target.wants
./usr/lib/systemd/system/sysinit.target.wants/systemd-vconsole-setup.service
./usr/lib/systemd/system/sysinit.target.wants/systemd-udevd.service
./usr/lib/systemd/system/sysinit.target.wants/systemd-udev-trigger.service
./usr/lib/systemd/system/sysinit.target.wants/systemd-tmpfiles-setup-dev.service
./usr/lib/systemd/system/sysinit.target.wants/systemd-journald.service
./usr/lib/systemd/system/sysinit.target.wants/kmod-static-nodes.service
./usr/lib/systemd/system/kmod-static-nodes.service
./usr/lib/systemd/system/sysinit.target
./usr/lib/systemd/system/basic.target
./usr/lib/systemd/system/initrd.target
./usr/lib/systemd/system/initrd-udevadm-cleanup-db.service
./usr/lib/systemd/system/initrd-switch-root.service
./usr/lib/systemd/system/initrd-switch-root.target
./usr/lib/systemd/system/initrd-root-fs.target
./usr/lib/systemd/system/initrd-parse-etc.service
./usr/lib/systemd/system/initrd-fs.target
./usr/lib/systemd/system/initrd-cleanup.service
./usr/lib/systemd/systemd-sysctl
./usr/lib/systemd/system-generators
./usr/lib/systemd/system-generators/systemd-gpt-auto-generator
./usr/lib/systemd/system-generators/systemd-fstab-generator
./usr/lib/systemd/system-generators/systemd-hibernate-resume-generator
./etc/initrd-release

systemd was upgraded (lines from pacman.log):

[2014-11-24 21:23] [PACMAN] upgraded libsystemd (217-6 -> 217-7)
[2014-11-24 21:23] [PACMAN] upgraded systemd (217-6 -> 217-7)
[2014-11-24 21:23] [PACMAN] upgraded systemd-sysvcompat (217-6 -> 217-7)

e.g. systemd, udevadm have changed:

$stat /usr/bin/init /usr/bin/udevadm | grep -e File -e Change
  File: '/usr/bin/init' -> '../lib/systemd/systemd'
Change: 2014-11-24 21:23:25.748659824 +0100
  File: '/usr/bin/udevadm'
Change: 2014-11-24 21:23:24.321908543 +0100

As far as I understand the startup process the kernel runs /sbin/init from real file system after switch root. So I assume the new systemd version runs after reboot (but old systemd version runs in early userspace) - but I am not sure about that ...

mgb · 2014-11-26 03:02:34

nomorewindows wrote:

OP is probably a noob. Only one post. This is a common mistake and the initramfs is in /boot. When there is an inconsistency between /usr and /boot files, this would probably be it. OP is welcome to try mkinitcpio -p linux, to see if that's all they need here.

How is that related to the question?

Scimmia · 2014-11-26 03:06:50

nomorewindows wrote:

OP is probably a noob. Only one post. This is a common mistake and the initramfs is in /boot. When there is an inconsistency between /usr and /boot files, this would probably be it. OP is welcome to try mkinitcpio -p linux, to see if that's all they need here.

OK, I understand what you're saying and would politely ask you to bow out until you read the OP in detail.

Scimmia · 2014-11-26 03:22:24

mgb wrote:

As far as I understand the startup process the kernel runs /sbin/init from real file system after switch root. So I assume the new systemd version runs after reboot (but old systemd version runs in early userspace) - but I am not sure about that ...

AFAIK, you're absolutely right. The question is, does it matter? I haven't seen a situation where this would make a difference, especially in the short time period between kernel releases. This might be the situation for a couple of weeks, but so what?

nomorewindows · 2014-11-26 03:25:16

His hooks line looks odd to me. Now that he has posted that. Is OP using other options in mkinitcpio in binaries, files, etc? Where is the base hook for example?

Last edited by nomorewindows (2014-11-26 03:25:46)

Scimmia · 2014-11-26 03:29:56

nomorewindows wrote:

His hooks line looks odd to me. Now that he has posted that. Is OP using other options in mkinitcpio in binaries, files, etc? Where is the base hook for example?

base hook is not needed when using the systemd hook. Again, none of this is the issue here, though, it's simply a question of whether the initcpio should automatically be regenerated when other included files are updated.

nomorewindows · 2014-11-26 04:49:31

Scimmia wrote:

nomorewindows wrote:
His hooks line looks odd to me. Now that he has posted that. Is OP using other options in mkinitcpio in binaries, files, etc? Where is the base hook for example?
base hook is not needed when using the systemd hook. Again, none of this is the issue here, though, it's simply a question of whether the initcpio should automatically be regenerated when other included files are updated.

There was one time they updated the kmod when the usr hook was a big thing, that it had to be then. But since then, I haven't had anything like that that I know of. Some modules like nvidia have kmod patched whatever that will rebuild on a new module/kernel combination.

Last edited by nomorewindows (2014-11-26 04:50:33)

mgb · 2014-11-26 09:00:32

Scimmia wrote:

AFAIK, you're absolutely right. The question is, does it matter? I haven't seen a situation where this would make a difference, especially in the short time period between kernel releases. This might be the situation for a couple of weeks, but so what?

OK - I agree. With some more understanding of systemd in early userspace and how switch_root is handled I am now convinced ...

Thank you much for your help & time!

Arch Linux

#1 2014-11-25 17:43:32

[SOLVED] initramfs outdated & not updated after package upgrade

#2 2014-11-25 18:04:41

Re: [SOLVED] initramfs outdated & not updated after package upgrade

#3 2014-11-25 21:49:12

Re: [SOLVED] initramfs outdated & not updated after package upgrade

#4 2014-11-25 22:24:56

Re: [SOLVED] initramfs outdated & not updated after package upgrade

#5 2014-11-26 00:49:03

Re: [SOLVED] initramfs outdated & not updated after package upgrade

#6 2014-11-26 00:55:07

Re: [SOLVED] initramfs outdated & not updated after package upgrade

#7 2014-11-26 02:01:40

Re: [SOLVED] initramfs outdated & not updated after package upgrade

#8 2014-11-26 02:54:03

Re: [SOLVED] initramfs outdated & not updated after package upgrade

#9 2014-11-26 03:02:34

Re: [SOLVED] initramfs outdated & not updated after package upgrade

#10 2014-11-26 03:06:50

Re: [SOLVED] initramfs outdated & not updated after package upgrade

#11 2014-11-26 03:22:24

Re: [SOLVED] initramfs outdated & not updated after package upgrade

#12 2014-11-26 03:25:16

Re: [SOLVED] initramfs outdated & not updated after package upgrade

#13 2014-11-26 03:29:56

Re: [SOLVED] initramfs outdated & not updated after package upgrade

#14 2014-11-26 04:49:31

Re: [SOLVED] initramfs outdated & not updated after package upgrade

#15 2014-11-26 09:00:32

Re: [SOLVED] initramfs outdated & not updated after package upgrade

Board footer