Boot fails after bios update lenovo

Hi, I just updated the bios on my lenovo ideapad 5 14 are05. I did it using the lenovo bios update tool on my dual boot windows. Unfortunately after the update the bios boot entry for manjaro is no more present so I am unable to boot manjaro. How can I restore my system? I know I need to do sone kind of chroot, but just running update-grub in a chroot environment on an installation medium does not fixthe problem even though the command finishes without any error…

The update-grub command just updates the configuration file.
All it does is run: grub-mkconfig -o /boot/grub/grub.cfg

What you want to do but didn’t is to actually reinstall grub.
See the Manjaro wiki, for instance - about 3/4 of the page down.
The command starts with grub-install and is different for Bios and EFI systems.

Thank you! Unfortunately I get stuck in the “grub-install”-command. It sais that efi variables are not supported and “grub-install: error: efibootmgr failed to register the boot entry: no such file or directory”
If I just continue with the commands the “ls /sys/firmware/efi” output is “no such file or directory”.
Also I did not find my bot partition. In the Wiki it sais it is optional, but maybe this would fix it?
Any ideas?

This is not confirmed, but just my guess:

you’d need to know/be sure whether your system actually is UEFI and is installed that way or whether it is Bios.
The procedure, once in chroot, is slightly different for both.

If the automatic chroot doesn’t work
there is always the manual method of mounting the partitions in order, then mounting /dev /proc and /sys and / and /boot/efi and then chroot …

The installation medium is booted with “legacy support” which I guess is bios. However I believe the system itself was an uefi system when it worked. I just tried running the bios commands which threw no error but when I try to boot to it I get to the recovery mode. When I type “ls” it returns the folders “MICROSOFT” and another one I forgot… Also in the bios there does not show anything up related to manjaro, I just booted from the ssd manjaro is installed on (windows is on another ssd)

I have here a Manjaro Architekt bootable medium and a Manjaro Xfce bootable medium.
I can boot my machine using either one -
With that I mean:
I’m booting my own system,
using the options available in Manjaro’s installation medium’s boot screen,
bypassing my system’s own (working) grub bootloader.
(and it’s not even Manjaro - but Arch …)

… as I’m writing this, my (Arch) system is booted using the Manjaro Xfce installation medium …

So this should be possible for you, too.
You can try.

There is an option in the boot menu “detect boot loaders” or something similar on the Xfce boot medium.
From the names it finds you should be able to figure out what to use - or just try each one …

The Manjaro Architekt boot medium has a slightly different menu.
Scroll down past memtest - there is more options not immediately visible.

That way you might be able to boot the original system without the need to chroot.

If that doesn’t work.
boot the installation medium and use the filemanager there to inspect your partitions -
to find out which is / and which is /boot or /boot/EFI
lsblk -f
in a terminal also helps to find out which is which
and thus enables you to correctly chroot
probably the manual way - since the automatic procedure doesn’t seem to work for you.

Thank you, this is a really cool feature! I found out that my live medium was unable to boot via Uefi which gets me to the same point as your method. I was trying to do the instructions from the website while booting via legacy even though I boot my normal system via Uefi. With the correct stick I can do the instructions without any error and now my manjaro entry is back in the bios. However I still get stuck booting: I get an error that that /boot/efi could not be mounted and some other errors, but less severe sounding (has to to with some applications I installed, flutter ect.). See the screenshot I appended. I am afraid I destroyed my system while trying to repair it with the instructions for legacy instead of bios, is that possible?

Updated your bios? It most likely got reset to default. Check for any changes that need redoing.

From what’s in that screen shot, It doesn’t appear that you have mounted /boot/efi successfully
… or that you “destroyed” anything

Boot the live medium - any way you can. So you are at a normal, graphical Desktop.
If that’s possible.
Then you can use whatever file manager there is available in that live system to explore your harddrive(s) and partitions on them.
and/or
issue (in a Terminal):
lsblk -f
and perhaps:
sudo fdisk -l
these will give you an overview on what partitions there are, on which disk they are and what filesystem is on them

This is my lsblk output:

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0         7:0    0  55.5M  1 loop /var/lib/snapd/snap/core18/1988
loop1         7:1    0  97.9M  1 loop /var/lib/snapd/snap/core/10583
loop2         7:2    0  64.8M  1 loop /var/lib/snapd/snap/gtk-common-themes/1514
loop3         7:3    0   128M  1 loop /var/lib/snapd/snap/signal-desktop/346
loop4         7:4    0    51M  1 loop /var/lib/snapd/snap/snap-store/518
loop5         7:5    0   219M  1 loop /var/lib/snapd/snap/gnome-3-34-1804/66
loop6         7:6    0 162.9M  1 loop /var/lib/snapd/snap/gnome-3-28-1804/145
loop7         7:7    0 544.3M  1 loop /var/lib/snapd/snap/freecad/19
loop8         7:8    0  31.1M  1 loop /var/lib/snapd/snap/snapd/10707
sda           8:0    0 223.6G  0 disk 
├─sda1        8:1    0    16M  0 part 
├─sda2        8:2    0  98.1G  0 part 
├─sda3        8:3    0   600M  0 part /boot/efi
├─sda4        8:4    0     1G  0 part /boot
└─sda5        8:5    0 123.8G  0 part /home
zram0       252:0    0   3.6G  0 disk [SWAP]
nvme0n1     259:0    0 238.5G  0 disk 
├─nvme0n1p1 259:1    0   300M  0 part 
├─nvme0n1p2 259:2    0 230.4G  0 part 
└─nvme0n1p3 259:3    0   7.8G  0 part 

Some explanations about it: I have two SSDs with basically the following content:

  1. sda: (1. Windows 2. a new fedora installation I made because then my corrupted manjaro stick did not work)
  2. nvme0n1 ( 1. manjaro)
    I believe that the small partition before big partitions always corresponds to a partition needed for booting the next big partition.

Another strange thing I realized is that it does not boot to windows whatever ssd I chose when booting in legacy mode…

No need to post all that - but since you did:

No need to believe.
lsblk -f
and
sudo fdisk -l
will help you to know.

Also use the filemanager to access them and inspect the content -
this will also help you to know.

That’s not strange - it is expected behaviour.
So: don’t use legacy mode.
You can end up in quite a mess if you install one system in legacy and another in UEFI mode and then expect them to still work together.

I just managed to boot again! The error was quite strange: after reinstallibg grub, it was no more configured to show its menu during boot. This means that it just booted to the default kernel. However this is a custom kernel which was trying a fix for a hardware error on my laptop. After the issues were fixed in the normal kernel, the custom kernel was no more needed so I deleted it. Unfortunately I did not do it properly which means the grub option still remains and it is the default option. This means that any time my machine boots with the default settings, the boot fails because the underlying kernel does not exist anymore. Which ways do I have do remove the bad grub option?

Normally, all it takes is to remove initrd
and the kernel itself, which is normally taken care of by the package manager.

So, have a look in /boot and see whether an initrd and/or a kernel is left behind.
The names start with intramfs- for the initial ram disk
and with vmlinuz- for the corresponding kernel
Your custom kernel probably had a distinct name and you’ll recognize it.

ls -hl /boot
rm /boot/the_thing_you_want_gone

(use with sudo)

When a kernel is installed, it gets copied to:
/usr/lib/modules/number_and_name

look there as well

ls -hl /usr/lib/modules
and remove with:
rm -rf /usr/lib/modules/_the_number_and_name

When done and satisfied, run
update-grub
(with sudo, of course)
to ge-generate a new menu

Have a look in /etc/default/grub too -
but you already adapted that one.

As ever so often, because I see people struggling when they have just the command line at their disposal when something went wrong, I suggest installing a terminal file-manager.
I use “mc” - which looks like the Norton Commander from the DOS days, if that is telling you something :wink:
It is keyboard driven, but mouse works, too.
It’s an incredibly useful tool and it makes navigating, viewing, editing, copying, extracting, packing, deleting … stuff so much easier.
Even easier and more efficient than the GUI itself, IMO - I use it all the time.
For me, it is an essential tool, the first thing that I install if it isn’t present.