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
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.
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.
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
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.
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.
[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.
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.