I was able to fix this using
chroot from a live OS, using a bootable USB stick. I will now describe step by step of what I did in order to fix this issue.
1. Get a bootable USB stick
Any Linux based OS will do, as long as it has basic utilities (which most of them do) such as
2. Boot the live OS
Insert the USB stick, or wherever you have your live OS, in your computer and boot from it, either from your bootloader or from your BIOS.
3. Chroot into your broken system
Now that we are working in an external system we're going to use to get access to our broken system, directly from a terminal.
3.1. The manual way
This process is more or less universal and you might have to make changes depending on your partition layout and will require privileged access, in this example using
First of all let's create a directory where we will mount our broken system
Now we have to mount the file system into that folder. Using any tool that will allow you to look for all available partitions which should come preinstalled in your live OS (e.g.: gparted), look for the root partition of your broken OS. In this example let's consider the root partition is
sudo mount /dev/sda2 broken-root
Now we have to mount the boot partition as well. This step will depend on how you boot your system. If you are using EFI, and assuming that your boot partition is given by
/dev/sda1 then mount it with:
sudo mount /dev/sda1 broken-root/boot/efi
If your system is not using EFI then look for the proper way of mounting your boot partition.
We must also bind system directories:
sudo mount --bind /proc /broken-root/proc
sudo mount --bind /dev /broken-root/dev
sudo mount --bind /sys /broken-root/sys
And finally enable networking:
sudo cp /etc/resolv.conf /broken-root/etc/
We can now
chroot into the system:
sudo chroot broken-root
3.2. The automated way
There are tools that will automate this process for you. The ones that I found were arch-chroot and manjaro-chroot, but there might be more automated tools available for different OS's.
4. Check file system for errors
sudo fsck /dev/sda2 to check for errors in your root partition and repair them. I did this after updating, but I found some errors while updating, so it's probably a better idea to do this before.
5. Perform the update
Now that you are inside your broken system, you can now update. Because my system hibernated mid update, pacman locked itself, and so you must remove the file located at
/var/lib/pacman/db.lck to proceed.
After removing the lock, force the update with a
sudo pacman -Syu.
Even after this there might be issues, at least there were with me, so I ran
sudo pacman -Qkk to list packages with issues and, naturally, the kernel was one of them. Then reinstalling all packages which showed issues.
-Qkk flag is very verbose and it lists things which are to be expected, only look for the most relevant ones!
6. Wipe the swap clean
I forgot to do this and was greeted with a system that was trying to resume its previous state, but with changes done while it was sleeping, and ended up with a black screen full of errors and forced my computer to shutdown by pulling the power from it.
To fix this, while still in your live OS, either disable resuming from swap, which was what I did, or wipe your swap file or partition clean. It should work either ways, but I recommend disabling the resume from swap and then wiping it clean when you are in your now repaired OS, simply because it worked for me.
7. That's it!
Now after booting up my computer again, Manjaro was showing in my bootloader. I booted from it as usual and it showed no errors and everything seems to be working just as expected.
ArchWiki - chroot
Manjaro Wiki - Grub/Restore the GRUB bootloader
TecMint - How to Use ‘fsck’ to Repair File System Errors in Linux
Arch Forums - Questions about pacman -Qk and -Qkk output