Cannot boot after update

General system Kernel & Hardware
1

Hi.
I just updated my system after a week since I was away.
After rebooting now I have no entries other than Boot into Firmware Interface on the systemd boot menu.
I tried chrooting from a live usb but I cannot find a way to fix it. I tried to mkinitcpio from chroot, also kernel-install from chroot, none of theose commands seems to work properly.

Please help. I have an assignment submission tomorrow and this is my only computer.

2

You need to use arch-chroot to chroot in and then run reinstall-kernels

Be sure that your EFI partition is mounted inside the chroot at /efi(or /mnt/efi if you are outside the chroot)

1 Like
3

By efi partition you mean /boot right?
I had that mounted in /mnt/boot

4

I chrooted using arch-chroot.
Ran reinstall-kernels (got an error - initrd /boot/*-ucode.img not a file.)
Then ran mkinicpio -P (image generation successful).
Then ran bootctl install.

I still do not have any entries in the systemd boot menu, only Reboot into Firmware Interface.

5

Unless you did a custom install, we mount that ESP at /efi, not /boot. Did you a custom conversion?

Eh? That is interesting.

What does ls /boot in the chroot show?

6

ls /boot gives -
b273010132… EFI loader

Further, I’ve attached an image of the output of bootctl list

20230710_222311~2
20230710_222311~23024Ă—1779 902 KB

7

It looks like you have your EFI partition mounted over /boot. Are you sure it shouldn’t be mounted at /efi and not /boot?

The issue is that reinstall-kernels is failing. That is what creates those entries.

8

Im sure it wasn’t/efi because if I mount it on /mnt/efi, running mkinitcpio -P gives

IMG_20230710_222938~2
IMG_20230710_222938~21920Ă—363 73.6 KB

9

That may be because you ran bootctl install while you had it mounted at /boot

If you unmount /boot what does ls /boot show?

Also, take a look in /etc/fstab from the chroot.

10

Just mounting the root partition to and arch-chrooting in and running ls /boot gives -
initamfs-custom.img intel-ucode.img

While /efi is empty.

11

That probably means it should be mounted on /efi. Check /etc/fstab

12

Sht fck.
It was mount on /efi

13

Mount it on /efi in the chroot, then run bootctl install and then run reinstall-kernels

1 Like
14

Thanks a TON !!!
Its solved. Back into my PC.
Gotta crunch that assignment now <3 <3 <3

2 Likes
15

A question to the experts here:
Can systemd-boot have such issue as Grub?

What can cause it?
Is there something to do to be sure it dies not happen?

This was a big surprise for me!

16

If you consider this Topic as resolved, please go to the post that helped the most to solve your problem. Click on the icon at the bottom ( check mark in a box) to mark that post as the solution.

Pudge

1 Like
17

There are two common causes for this issue:

  • An update isn’t allowed to finish for whatever reason(User cancels in the middle, battery dies, forget the update is running and shutdown the system, etc)
  • The packages dracut, kernel-install-for-dracut or kernel-install-mkinitcpio are removed from the system

Pay attentions to the update process and be sure there are no errors reported.

2 Likes
18

Thanks a lot @dalto
So, generally speaking it is something form outside, something outside a normal update, or something the user did! It is not like the Grub update that breaks if the user was not alert to do what is needed.

So, no worries from a just normal update provided that I won’t do something silly like turning off the machine while updating.

Thanks a lot.

19

Here is my non-expert two cents.

Systemd being a piece of software, and quite complicated at that, it is not immune to having bugs. There is always a probability that a new bug is crept into it in a future update.

Nobody could tell how probable that would be but the best “preemptive” course of action is to learn how to rescue the system if/when such “breakdown” happens.

20

How come you say you are non-expert. I have been here for a year, and I count you an expert. No complements. This is what I think.

This a rule of thumb for any software. Software = Bugs no matter what.

This goes without saying,

What I meant -with all my due respect- to all developers, all software and all users, was that Grub by design will cause a problem if the user was not completely alert and do what is required if Grub got an update that requires the user to … do a few things to avoid having an unbootable system.

But as @dalto explained, the issue in this topic is outside systemd-boot and its design. That is if updated normally or system updated, or kernel updates it does not require anything to be done by the user. It just works and it will just work. That is it just works by design.

Thank you for caring to comment @pebcak