Yay and eos-update keep breaking boot

Multiple times over the last few weeks, I’ve run either yay or eos-update to update my computer, had it pop up the “you should reboot since there was an update” notification, but when I rebooted, my BIOS rebooted to the “Reboot into Firmware Interface” being the only option.

Every time I’ve been able to fix it by booting from an Eos installer instead, mounting the drive, and then doing a arch-chroot followed by

pacman -S dracut kernel-install-for-dracut linux linux-api-headers linux-firmware util-linux

as outlined in Reboot into firmware interface problem - #5 by chewie

It gets me back to a working install, but it’s worrying me that seemingly normal updates to my system are regularly forcing me to reinstall all of Linux. That said, I have no idea how to debug what exactly is going wrong here that’s causing Yay to corrupt my install.

Anyone have any tips or tricks to work out how I’ve broken my system? The only other thing I’ve noticed being odd or broken is that I’ll regularly have new package installs fail to install because they got a 404 on every single mirror, and re-ranking the mirrors hasn’t been able to fix it reliably.

You don’t need all that. Probably just the kernel would be sufficient.

When the notification comes up to reboot, the update may not be complete yet. Be sure to wait until the update is finished before actually rebooting.

I’ve definitely been waiting for the command to finish, so it shouldn’t be that. I’ve been meaning to test the reinstall of a more limited set of the stuff from that command, but I’m usually in a hurry to fix my system, so hadn’t been taking the time to attempt it one-at-a-time.

You only need linux and maybe linux-headers. Not the rest of that stuff.

This is caused because either the kernel, the boot images or both are missing.

As far as I can tell, there are only two possible causes of this, the update doesn’t fully complete so the post transaction hooks don’t finish or one of the hooks fails. In that latter case, there would be errors reported as part of the update process.

If this is happening frequently, you may want to start reviewing the text from the output and checking for errors before rebooting.

I’ll try to keep a closer eye on it next time - part of the issue is, for instance, it just happened in the last hour, but a run of yay right now doesn’t want to update anything. So the chroot reinstall seems to make it happy.

I’m looking back through the pacman logs in /var/log/pacman.log and I’m seeing this:

[2023-08-09T16:29:38-0500] [ALPM-SCRIPTLET] Running in a chroot, skipping cmdline generation
[2023-08-09T16:29:38-0500] [ALPM] running 'eos-reboot-required.hook'...
[2023-08-09T16:29:38-0500] [ALPM-SCRIPTLET] /usr/bin/id: ‘’: no such user
[2023-08-09T16:29:38-0500] [ALPM-SCRIPTLET] su: user  does not exist or the user entry does not contain all the required fields
[2023-08-09T16:29:38-0500] [ALPM] running 'rebuild-detector.hook'...
[2023-08-09T16:29:38-0500] [ALPM-SCRIPTLET] fatal library error, lookup self

Which looks odd, but seems like it’s just failing to trigger a notification? The dracut logs above it look like they’re fine outside of things like:

[2023-08-09T16:29:34-0500] [ALPM-SCRIPTLET] dracut: dracut module 'memstrack' will not be installed, because command 'memstrack' could not be found!
[2023-08-09T16:29:34-0500] [ALPM-SCRIPTLET] dracut: memstrack is not available
[2023-08-09T16:29:34-0500] [ALPM-SCRIPTLET] dracut: If you need to use rd.memdebug>=4, please install memstrack and procps-ng

Yeah, those are not fatal.

That is normal. It is just letting you know that you don’t have something installed on your system so it won’t be included in your dracut image.

Pay special attention to the last couple of lines of the dracut output where it writes the final output file. Sometimes that can fail and there will be an error there.

The end of my dracut seems normal enough:

[2023-08-09T16:29:35-0500] [ALPM-SCRIPTLET] dracut: Mode:                     real
[2023-08-09T16:29:35-0500] [ALPM-SCRIPTLET] dracut: Method:                   sha256
[2023-08-09T16:29:35-0500] [ALPM-SCRIPTLET] dracut: Files:                    801
[2023-08-09T16:29:35-0500] [ALPM-SCRIPTLET] dracut: Linked:                   3 files
[2023-08-09T16:29:35-0500] [ALPM-SCRIPTLET] dracut: Compared:                 0 xattrs
[2023-08-09T16:29:35-0500] [ALPM-SCRIPTLET] dracut: Compared:                 43 files
[2023-08-09T16:29:35-0500] [ALPM-SCRIPTLET] dracut: Saved:                    356.78 KiB
[2023-08-09T16:29:35-0500] [ALPM-SCRIPTLET] dracut: Duration:                 0.004168 seconds
[2023-08-09T16:29:35-0500] [ALPM-SCRIPTLET] dracut: *** Hardlinking files done ***
[2023-08-09T16:29:35-0500] [ALPM-SCRIPTLET] dracut: *** Generating early-microcode cpio image ***
[2023-08-09T16:29:35-0500] [ALPM-SCRIPTLET] dracut: *** Constructing AuthenticAMD.bin ***
[2023-08-09T16:29:35-0500] [ALPM-SCRIPTLET] dracut: *** Store current command line parameters ***
[2023-08-09T16:29:35-0500] [ALPM-SCRIPTLET] dracut: *** Stripping files ***
[2023-08-09T16:29:35-0500] [ALPM-SCRIPTLET] dracut: *** Stripping files done ***
[2023-08-09T16:29:35-0500] [ALPM-SCRIPTLET] dracut: *** Creating image file '/efi/f4a231fb77284ee4849438eba9c2c33b/6.1.44-1-lts/initrd' ***
[2023-08-09T16:29:38-0500] [ALPM-SCRIPTLET] dracut: *** Creating initramfs image file '/efi/f4a231fb77284ee4849438eba9c2c33b/6.1.44-1-lts/initrd' done ***
[2023-08-09T16:29:38-0500] [ALPM-SCRIPTLET] Running in a chroot, skipping cmdline generation

It’s part of what’s throwing me - I’m the type to over-inspect logs and output usually, and the installs always look fine, and then I reboot and evidently everything’s broken.

That is the log from when you fixed it, not from where it failed.

The failure would be an earlier run.

Oh, I may have found it:

[2023-08-09T16:07:21-0500] [ALPM-SCRIPTLET] dracut: *** Creating image file '/efi/f4a231fb77284ee4849438eba9c2c33b/6.1.44-1-lts/initrd' ***
[2023-08-09T16:07:24-0500] [ALPM-SCRIPTLET] dracut: *** Creating initramfs image file '/efi/f4a231fb77284ee4849438eba9c2c33b/6.1.44-1-lts/initrd' done ***
[2023-08-09T16:07:24-0500] [ALPM-SCRIPTLET] unknown command: python3. Perhaps you have to reshim?
[2023-08-09T16:07:24-0500] [ALPM-SCRIPTLET] /usr/lib/kernel/install.d/60-ukify.install failed with exit status 1.

It seems odd to me that it’s failing to install the kernel because the symlink from python3 to python is dead though? I just fixed that, but I’m suspicious that it’s not the issue.

We should see what happens going forward.

Yea, I’ll try to keep a closer eye on it next time I notice a kernel update. It also just seems weird that it would have a installation failure like that and yay wouldn’t throw up a more obvious “Hey, something went super wrong here”. It’s buried deep in the output around other stuff.

1 Like

Do you use asdf by any chance? I keep having this same problem, and I wonder if it’s caused by asdf.


Looks like it’s asdf fault indeed, see

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.