[HowTo] restore the bootloader on MBR-formatted disk if root UUID changes

[Hebgbs]

Difficulty: ★★☆☆☆

Please note that this example was performed on a legacy MBR installation with BIOS system. This may not work exactly as described if using GPT installation with UEFI.

Due to recent replies, this post has been edited from its original copy to reflect new information.

Preface

Root became corrupt, but you have a functional copy of the partition because you backed up like a good user. Problem is, some partition management software might change the UUID of the partition, which means you won’t be able to boot back into it even after you had restored the backup.

Let’s also assume you don’t want to follow the advice on Manjaro wiki because there’s no real need to chroot into your installation just to fix a simple UUID mismatch. There are two ways to deal with it.

The long, hard way

For when manjaro-chroot is unavailable

Doing it live

Where to begin

For this, we’ll assume the following:
Old UUID: ORIGINAL-0000-0000-0000-000000000000
New UUID: DUPEPART-1111-1111-1111-111111111111
Label: manjaro_os

For this, I resolved the problem initially using a live session. First, acquire information:

Find the UUID of the target root media

lsblk -f

Understand this command

From the Feburary 2013 manual for lsblk:
-f: Output info about filesystems.

Best performed in a maximized terminal emulator window for minimizing output height.

The easiest tells from this output is how big the partition is, and what it is labelled. If you chose to label the partition by manually creating partitions this should be easy. If not, then partition size alone is the only option. For a graphical representation, try either of these tools:

Qt (KDE): partitionmanager
GTK: gparted, gnome-disks

Once you figure out which partition is root duplicate on target media (which we will assume in following examples is DUPEPART-1111-111-1111-111111111111), copy that.

Mount the partition in your file explorer (which we will assume is labelled manjaro_os) and perform the following tasks:

Fixing grub.cfg

To fix this, open grub.cfg by applying this example to your system:

Opening grub.cfg to fix UUID:

sudo nano /run/media/manjaro/manjaro_os/boot/grub/grub.cfg

Dislike nano? Use what came with the desktop for your current session! Example for MATE:
pluma admin:///run/media/manjaro/manjaro_os/boot/grub/grub.cfg

If the UUID in menu entry for service 10_Linux is different then what lsblk -f shows:

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Manjaro Linux' --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-ORIGINAL-0000-0000-0000-000000000000' {
	savedefault
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos7'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,msdos7' --hint-bios=hd0,msdos7 --hint-efi=hd0,msdos7 --hint-baremetal=ahci0,msdos7  ORIGINAL-0000-0000-0000-000000000000
	else
	  search --no-floppy --fs-uuid --set=root ORIGINAL-0000-0000-0000-000000000000
	fi
	linux	/boot/vmlinuz-5.7-x86_64 root=UUID=ORIGINAL-0000-0000-0000-000000000000 rw  quiet apparmor=1 security=apparmor udev.log_priority=3
	initrd	/boot/intel-ucode.img /boot/initramfs-5.7-x86_64.img

Then replace ORIGINAL-0000-0000-0000-000000000000 with DUPEPART-1111-1111-1111-111111111111. Easiest done if using find and replace (which will also affect all advanced options).

Rescue it

After sending systemctl poweroff (or shutting down), disconnect all external media save for the device which contains the bootloader, if applicable. Once at GRUB rescue prompt with partition UUID corrected, first try to show all available devices:

In GRUB rescue:

ls

The device you are looking for may not necessarily match the entry in grub.cfg. If there are multiple listings of disk and partition, then try until you find a /boot directory. Example input for showing directories in this limited shell environment:

Showing contents of disk zero, partition one

ls (hd0,msdos1)/

We’ll assume this is correct for the remaining examples.

If you see something like this:

./ ../ bin etc lost+found proc sbin tmp boot home .manjaro-tools root snap usr desktopfs-pkgs.txt lib mnt rootfs-pkgs.txt srv var dev lib64 opt run sys

Then you’re on the right track. To revive the bootloader and access your system, do this:

Bring it back

set root=(hd0,msdos1)
set prefix=(hd0,msdos1)/boot/grub
insmod normal
normal

The short, elegant way

For when Manjaro is an option for live session

Doing it live

Where to begin

If you’re already using a Manjaro system, which you most likely are if you are reading this forum then you have access to a special tool called manjaro-chroot. The first thing you should do is open a terminal and open it.

In xdg-terminal or preferred terminal:

manjaro-chroot -a

Understand this command

-a: Automount detected Linux systems. (Basically does the hard work of changing root for you.)

The fallowing command will eventually produce a menu requesting which system to access. They should show in the order USB devices with subsequent Manjaro installation are shown if more than one exist, else select the only instance labelled ManjaroLinux which will allow you to modify the system partition for that specific instance within the terminal.

In this mode, lsblk will produce near-useless information. An alternative which will permit device names for fixing GRUB can be used as shown.

In xdg-terminal or preferred emulator:

parted -l

Understand this command

-l: [L]ists partition layout on all block devices

Rescue it

As you are manipulating the device partition where manjaro_os is, you can perform commands similarly to if you were booted in an active session, and as such, you should advance to this information underneath the next heading for completing this task. When finished, exit and shut down to remove live session media before powering on once again.

Success?

If this worked (with either method), you will see the bootloader menu as defined by grub.cfg. Wait. Even if you see odd startup messages output to TTY1 during boot you should eventually get to your desktop manager. Once logged in this is the very first command you should do to resolve future issues.

In xdg-terminal or preferred emulator:

sudo update-grub

Subsequent boots should function without error. If issues persist and you need to use GRUB rescue at every boot, try installing the bootloader onto root system device or root bootloader device, whichever is applicable. Follow previous advice about seeing disks in the terminal for which device to install upon, and use that information to complete the following example command below.

This information also applies while using manjaro-chroot.

In xdg-terminal or preferred emulator:

sudo grub-install /dev/sdX --recheck
sudo update-grub

Replace sdX with whatever is shown for boot device relative to your configuration.

Information sources

Error no such device - How to fix this problem in GRUB rescue mode

Special thanks

@Wollie for basically making sport of the initial revision. Thanks for the hot tip.

[Wollie]

For an msdos parted disk (with MBR) and legacy (BIOS) booted system with a grub2 bootloader I did simply

• boot into a live iso
• manjaro-chroot -a … {iselect the Manjaro system, if only one line select 1}
• parted -l … {to find the right device name}
• grub-install /dev/sdx --recheck … {where sdx is the device name of the disk}
• update-grub
• exit

and reboot.

That’s it!

[Aragorn]

@Hebgbs

Mount the partition in your file explorer (which we will assume is labelled manjaro-system ) […]

Perhaps you could change the name of the generic file manager you’re referring to, because there effectively is a package named manjaro-system, and it’s not a file manager.