0

Unfortunately my laptop hibernated on low battery while performing an update, during the installation part of the update.

On booting up rEFInd shows only Windows and not Manjaro.

The update was of decent size and included among many things,the Linux Kernel.

After reading the documentation for rEFInd the author states that it does a pretty good job of finding kernels. I also know that Linux can update itself while running and that for most, if not all, programs can keep running and will start using the updated files after rebooting.

My idea is that the running system, i.e. the pre-update system, was in memory while the updates were being written to disk and installed in their right place. Knowing that hibernation would write RAM to my swap partition the system I am trying to boot, the one that should be in RAM, is now swapped out.

My question is, knowing that I have Linux based distros on a USB, is it possible to boot in such a way as to restore the previous session and the update resumes as if nothing had happened?

If not, will I be able to chroot into Manjaro safely, update it, clear the swap and then start it normally, since everything is half installed? And how will Pacman react to that?

0
0

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 chroot and fsck.

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

First of all let's create a directory where we will mount our broken system / directory:

mkdir broken-root

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 /dev/sda2:

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

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

Note: the -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.

References

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.