System won't boot after error during update

Hello,
While I was applying the latest update through the graphical package manager, Gnome showed the Oh no! Something went wrong screen and I had to log out. After I tried to login the error screen appeared immediately again. Since then I can no longer boot the system. I use rEFInd boot loader and with dualboot setup and after I select to boot Manjaro the screen stays gray and the fans start spinning (~75%). The update consisted of roughly 150 packages and a kernel update was included.

My setup is Manjaro with GNOME and kernel 5.7 on Xiaomi Notebook Pro with Intel i5-8250U, Nvidia MX150 and NVME SSD. The primary graphics card was the integrated Intel GPU and it was set to switch Nvidia GPU using Bumblebee. Previously it run without any problems.

How can this be resolved? I would really like to avoid reinstalling the system.

Thank you

Welcome to the forum! :slight_smile:

The advice I give to everyone ─ and most experienced Manjaro users will agree with me on this ─ is to always apply major updates by way of the command line in a tty, and while completely logged out of the graphical environment.

The graphical package managers are convenient for installing individual software titles, or for looking for the name of a package, but when it comes to a full system update, you really don’t want to have any shared libraries in use that are going to be overwritten by the update process.

That all said, let’s get down to business. :wink:

Boot up from the live medium ─ preferably the latest, which you can find here (for GNOME) ─ and open up a terminal window. In that terminal window, you enter the following command… :arrow_down:

su -

Enter the root password of the live medium. Now enter the following command… :arrow_down:

manjaro-chroot -a

This will detect your root filesystem ─ it will offer you a menu if you have more than one GNU/Linux distribution installed ─ and it’ll perform a chroot into it.

Next, issue the following command… :arrow_down:

pacman-mirrors -f 5 && pacman -Syyu 

Let it finish, however long it takes. When it has finished updating the system, type…

exit

Now you should be able to reboot the system and boot up into your updated system. Don’t forget to remove the install medium, of course. :slight_smile:

I’m using Manjaro KDE without dual boot. immediately after installing it yesterday I got around 500 packages or something like that Kernel was included too. so I did like what you did and installed them through the graphical package manager and every thing was fine until I rebooted. it got stuck in bios loop. after asking in this forum and googling around I found a solution which is to use

$ sudo pacman -Syyu

to update through the terminal. but obviously after re installing Manjaro all over again. without using the graphical package manager.

I’m really novice in the Linux world but this is what worked for me.

Thank you for the answer. I will try that but I have a question. My system kernel version is 5.7 but the latest live medium you linked has kernel 5.8. Shouldn’t be the kernel version for chroot the same as the target system?

No, that’s not important, as long as it’s a Manjaro kernel. :wink:

Okay, so I succesfully chrooted into my system and pacman-mirrors command executes ok but running pacman -Syyu results in the following error:

:: Synchronizing package databases...
error: failed to update core (unable to lock database)
error: failed to update extra (unable to lock database)
error: failed to update community (unable to lock database)
error: failed to update multilib (unable to lock database)
error: failed to synchronize all databases

What can I do next?

As your update has not been completed, the lock file has not been deleted as it would have been usually at the end of the update process. The database lock file can be manually deleted. To do so, open up a terminal and enter the following command:

sudo rm /var/lib/pacman/db.lck
1 Like

Thank you, now pacman is working but it only synchronizes databases and then outputs “there is nothing to do” and the boot problem was still not resolved.

If you’re still in the chroot, try this…

grub-install --recheck --no-rs-codes --modules="zstd part_gpt part_msdos"
update-grub
1 Like

Won’t this overwrite my current boot manager? I use refind. As far as I know it is supposed to scan for all boot options at startup.

Yes, it will. I was under the assumption that you were using GRUB ─ sorry.

Yes, but I don’t know anything about refind, and so I don’t know whether anything needs to be done to configure it after an update. Doesn’t it require the kernels to reside in the EFI system partition? If so, copy the kernel images and the initramfs over manually. :arrow_down:

cd /boot && for i in *linu* *.img ; do cp $i ./efi/ ; done

Refind shouldn’t require any configuration after update. I never had an issue with it before.
The boot partition contains following files:

-rw-r--r--  1 root root  40K Sep  1 16:26 amd-ucode.img
drwxr-xr-x  3 root root 1.5K Jan  1  1970 efi
-rw-r--r--  1 root root 3.1M Jun 16 19:50 intel-ucode.img
-rw-r--r--  1 root root   21 Aug 28 22:21 linux57-x86_64.kver
drwxr-xr-x  2 root root 4.0K Jun  3 23:53 memtest86+
-rw-r--r--  1 root root  267 Oct 27  2019 refind_linux.conf
-rw-r--r--  1 root root 6.4M Sep  8 18:35 vmlinuz-5.7-x86_64

Maybe the initrd is missing? It should be there and it isn’t in the nested folders.
Can the kernel file be corupted? Is the file size of kernel correct?
How can I regenerate initrd?

After start no text or a text cursor appear on the screen.

There’s your problem, right there. You cannot boot without an initramfs ─ well, you can, but only with a custom kernel, and only under certain conditions.

I don’t have a 5.7 kernel here ─ I’m on 5.4 LTS ─ but the size seems about right.

mkinitcpio -g

The -g option didn’t work so I used a preset:

mkinitcpio -p linux57

Now it is all working again!!
Thank you for your help.

2 Likes

Please, mark the post helping you most as solution. :innocent:

1 Like

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