[SOLVED] Systemd upgrade from 256.9-1 to 257-1 failure

zpg443 · 2024-12-16 15:17:00

Failed to boot after this upgrade, as systemd-modules-load failed to find several modules including crypto_user. Should I downgrade systemd until I can troubleshoot this is more detail? I am able to chroot in and pacman shows system is up to date.

Last edited by zpg443 (2024-12-17 15:52:01)

cryptearth · 2024-12-16 15:23:38

have you updated the kernel along systemd?
sounds like boot kernel + initrd are out of sync with rest of the system

zpg443 · 2024-12-16 15:38:12

Yes the kernel was upgraded at the same time to 6.6.65-1-lts and image generation was successful. Usually Timeshift can restore to a previous state but it will not recognize the device with the backups.

Last edited by zpg443 (2024-12-16 15:46:00)

V1del · 2024-12-16 16:57:06

You didn't have your boot partition mounted when the kernel updated, or the inverse you did originally install the kernel without a boot partition but are now mounting over that.

What's the case? That timeshift doesn't work in a ESP as /boot constellation is normal and if that's the case, you need to make sure that is mounted when installing a kernel update.

zpg443 · 2024-12-16 17:44:02

Maybe the boot partition was not mounted, but I don't recall unmounting it. It is definitely not installing without a boot partition.Although /efi is a replacement for the historical and now discouraged ESP mountpoint /boot/efi, this is how I had set it up.

Here is the boot log from when the first fail happened 0x0.st/XFGp.txt
It says in part: /boot/efi failed to mount.

Last edited by zpg443 (2024-12-16 19:48:41)

cryptearth · 2024-12-16 20:19:30

zpg443 wrote:

Although /efi is a replacement for the historical and now discouraged ESP mountpoint /boot/efi

do you have any sources for this?

Scimmia · 2024-12-16 20:29:35

cryptearth wrote:

zpg443 wrote:
Although /efi is a replacement for the historical and now discouraged ESP mountpoint /boot/efi
do you have any sources for this?

https://wiki.archlinux.org/title/EFI_sy … unt_points with sources

Scimmia · 2024-12-16 20:36:59

zpg443 wrote:

Here is the boot log from when the first fail happened 0x0.st/XFGp.txt
It says in part: /boot/efi failed to mount.

First line shows that it is booting the 6.6.63-1-lts kernel, which is not what you have installed. No question, it's as V1del said, nothing to do with systems.

Edit: the kernel command line also shows that it's loading the initramfs from a /boot dir, so you are *not* using a /boot partition. If you had something mounted there, that's a problem. An alternative is that if the preset file in /etc/mkinitcpio.d/ is wrong or empty, you could see this, too.

Last edited by Scimmia (2024-12-16 20:52:54)

cryptearth · 2024-12-16 23:23:41

Scimmia wrote:

cryptearth wrote:
zpg443 wrote:
Although /efi is a replacement for the historical and now discouraged ESP mountpoint /boot/efi
do you have any sources for this?
https://wiki.archlinux.org/title/EFI_sy … unt_points with sources

I had a look at it and ... well, for the sake of not hijacking this topic with an opinionated argue - let me just thank you for sharing your sources

zpg443 · 2024-12-16 23:52:00

Giving up for today after 10+ hours of troubleshooting without resolution. The current kernel is installed. It was downloaded last night, and the shutdown log verifies it was updated.

Scimmia · 2024-12-17 00:00:53

The *package* was updated. The image where the bootloader is getting it from was not.

zpg443 · 2024-12-17 00:34:58

It was successful when running mkinitcpio -P.

seth · 2024-12-17 08:27:18

The problem isn't the initramfs generation, but where it (and the kernel) were stored.

findmnt -T /boot
file /boot/vmlinuz-linux-lts
ls -l /boot

zpg443 · 2024-12-17 15:51:42

Thanks to all for this help. What solved it was removing rEFInd and replacing it with systemdboot. Having a separate /efi instead of /boot/efi apparently matters, as per the wiki.

V1del · 2024-12-17 22:19:10

It doesn't matter, assuming you're configuring things correctly.

The only path that actually matters assuming a default setup is whether you mount the ESP to /boot or anywhere else. If anywhere else you need a bootloader that can read the kernels from your root partitions /boot directory (refind qualifies for this and I'm assuming this was actually your original setup) if you after the fact configure the ESP to get mounted to /boot you are masking that path, and kernels aren't generated into the correct spot because they will now land on your /boot partition instead of the directory they were originally configured for.

You can always configure bootloaders and mkinitcpio image generation to deviate from this, but that would be explicit setup.

Arch Linux

#1 2024-12-16 15:17:00

[SOLVED] Systemd upgrade from 256.9-1 to 257-1 failure

#2 2024-12-16 15:23:38

Re: [SOLVED] Systemd upgrade from 256.9-1 to 257-1 failure

#3 2024-12-16 15:38:12

Re: [SOLVED] Systemd upgrade from 256.9-1 to 257-1 failure

#4 2024-12-16 16:57:06

Re: [SOLVED] Systemd upgrade from 256.9-1 to 257-1 failure

#5 2024-12-16 17:44:02

Re: [SOLVED] Systemd upgrade from 256.9-1 to 257-1 failure

#6 2024-12-16 20:19:30

Re: [SOLVED] Systemd upgrade from 256.9-1 to 257-1 failure

#7 2024-12-16 20:29:35

Re: [SOLVED] Systemd upgrade from 256.9-1 to 257-1 failure

#8 2024-12-16 20:36:59

Re: [SOLVED] Systemd upgrade from 256.9-1 to 257-1 failure

#9 2024-12-16 23:23:41

Re: [SOLVED] Systemd upgrade from 256.9-1 to 257-1 failure

#10 2024-12-16 23:52:00

Re: [SOLVED] Systemd upgrade from 256.9-1 to 257-1 failure

#11 2024-12-17 00:00:53

Re: [SOLVED] Systemd upgrade from 256.9-1 to 257-1 failure

#12 2024-12-17 00:34:58

Re: [SOLVED] Systemd upgrade from 256.9-1 to 257-1 failure

#13 2024-12-17 08:27:18

Re: [SOLVED] Systemd upgrade from 256.9-1 to 257-1 failure

#14 2024-12-17 15:51:42

Re: [SOLVED] Systemd upgrade from 256.9-1 to 257-1 failure

#15 2024-12-17 22:19:10

Re: [SOLVED] Systemd upgrade from 256.9-1 to 257-1 failure

Board footer