Cloned Mint21 system but couldn't boot to it

[xGuy]

Firstly, may I say that I have found a workaround to this. So please don't anyone spend a lot of time on it. I've seen a number of posts with some similarities to my issue but nothing that quite matches it. So I'm hoping that perhaps someone with expert knowledge will just realise what has happened more or less immediately and can enlighten me!

Secondly my system is MBR based.

I've been running Mint since 17.2 days but have been live on Mint 19 since shortly after its release. Never upgraded on the basis of "if it ain't broke ..."

I decided to start afresh with Mint 21 rather than attempt a convoluted in situ upgrade. The first thing I did was to install from the installation media to a small ext4 root partition. This system is destined to be a backup/recovery system for the Main Mint 21 system - it will use tar to take a compressed archive of the entire contents of a root partition and restore it if needed. (And vice versa the Main System backs up / restores the Recovery System. It's the same set up as I have on Mint 19 and my Bash scripts are well proven). Initially backup/restore of Mint 21 is from Mint 19 as host but that will change.

Building this Mint 21 backup system took quite a bit longer than I'd anticipated but it was worth tailoring it perfectly. So rather than start installing the Main System from DVD media and having to repeat everything I'd done so far, I cloned it from the backup system. It something I've done quite often without issue in the past. I used my backup / recovery scripts just slightly modified to suit the different partition details for the Mint 21 partitions.

The first step was to create a new ext 4 partition - 200 GB. Then do a tar restore of the new Mint 21 backup system into it (using Mint 19 as host). After that mount the new system and edit /etc/hosts and /etc/hostname to change the system name. And most importantly edit /etc/fstab to change the UUID of the root partition to that of the new 200 GB partition.

Next I needed to chroot into the new system and run update-grub and grub-install in the standard way. This was done from Mint 19 using :-

mount -o bind /dev "$TARGETMNT"/dev
mount -o bind /dev/pts "$TARGETMNT"/dev/pts
mount -o bind /proc "$TARGETMNT"/proc
mount -o bind /run "$TARGETMNT"/run
mount -o bind /sys "$TARGETMNT"/sys

chroot $TARGETMNT update-grub

I could be sure that I was running the correct Mint 21 version of grub because it put out the message about invoking OS Prober which would not have happened with the Mint 19 version of grub.

And finally :-

chroot $TARGETMNT grub-install $TARGETDISK

It so happens that $TARGETDISK (/dev/sda) is the BIOS default boot disk but of course this can be overridden by hitting the F8 key.

However I found that when attempting to boot the new Mint 21 system it actually booted the Mint 21 backup/recovery system from which it had been cloned. I tried booting from other Mint systems via chainloading and running update-grub and grub-install any number of times but it was always the same. It seemed that the system was always going to boot with the root partition set to the UUID of the donor system's root partition no matter what.

Finally after much searching I found the workaround. This was to insert an extra line into the cloned system's /etc/default/grub file :-

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# force grub to use the correct root partition - not the m21_recov
# root partition which mint21_root was cloned from
GRUB_DEVICE_UUID=15b5978f-c6e4-42b2-ad64-6f8813034ef7

So my guess is that the UUID of the Mint 21 recovery system's root partition is stored somewhere in the cloned Mint 21's filestore and by default Grub is taking this as the root partition. If that guess is correct, then my next question is where is that UUID stored and can I easily change it so I don't have to rely on the workaround?

I hope I've given sufficient information above without unnecessary detail.

Many thanks for reading this and even more thanks if you can help!

[t42]

Just to be sure, look up sudo lsblk -f

[xGuy]

OK - here's the output - actually the first line is the critical one but I've included it all - looks OK to me :-

NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1 ext4 1.0 mint21_root 15b5978f-c6e4-42b2-ad64-6f8813034ef7 174.4G 6% /
├─sda2 ext4 1.0 mint19_root 2f1c9139-c5d4-4b1d-9d74-af6bdd8261c2
├─sda3
├─sda5 ext4 1.0 m21_recov_bu 9c99ac5c-84b8-41f7-b81b-97d0dc6d259e
├─sda6 ext4 1.0 m21_recov_ts f599688c-7624-4d1e-8868-436d5eeb3d17
├─sda7 ext4 1.0 lx_wksp_b 061c212f-354d-43b6-a764-ff290d5f236e 184.5G 48% /mnt/lx_wksp_b
├─sda8 ext4 1.0 lx_wksp_xa 3dbaf884-f0f1-4aa0-980b-7dcde63d33d1
├─sda9 ext4 1.0 lx_wxp_g 51536171-4ba0-4394-b301-d97964ee4015
└─sda10 ext4 1.0 lx_wxp_rj b2cdaf71-fae2-4626-8e5c-0e7d4789ba58
sdb
├─sdb1 ntfs Win8 1CC4C9BCC4C99882
├─sdb2
├─sdb5 ntfs My Data 01CF62FFDFEB8350
├─sdb6 ntfs WKSP_H 01D239DDEFF67DB0
├─sdb7 ntfs VM_BKUPS 01D239F73A27ADF0
├─sdb8 ntfs G_BKUP_P 01D70616C3B19000
├─sdb9 ntfs J_BKUP_R 01D70616C9B7EBC0
├─sdb10 ntfs Tunes 01D23F2C6BA96460
└─sdb11 ntfs CarTunes 01D23C4DB22E8FF0
sdc
sdd
├─sdd1 ext4 1.0 lx_wksp_c ee288dab-414b-454f-bb27-7c1c02594c86 1.4T 14% /mnt/lx_wksp_c
└─sdd3
sde
├─sde1
├─sde5 ext4 1.0 m21_recov e1628cb5-9184-4b88-91b6-124ebf95ded2
├─sde6 ext4 1.0 lx_wksp_a 3c1e4b32-dc7d-4e44-a3a3-b407c951c498 252.3G 31% /mnt/lx_wksp_a
├─sde7 ext4 1.0 lx_wksp_yb 901f3d3d-b455-451c-a96a-9792b1e11a4a
├─sde8 ext4 1.0 lx_backups 52b1b40d-ba6d-4ac4-b1be-64ddc04ab3d9
├─sde9 ext4 1.0 lx_wxp_j ecd230dd-b62e-4b0d-9b7a-3133a633da44
├─sde10 ext4 1.0 lx_wxp_qh f5eaa331-025d-4e5b-a78d-43faff7da252
├─sde11 ext4 1.0 lx_vm_backups 97b58436-c74d-4bf0-bb89-38c4d92e8703
└─sde12 ext4 1.0 lx_timeshift 3734c7ca-d901-43cb-bb95-79d8e05ddd26
sdf
├─sdf1
├─sdf5 ntfs SWAP 01D23F45F2E4F430
├─sdf6 ntfs WKSP_G 01D23F471DE28CA0
├─sdf7 ntfs WKSP_J 01D23F4720FDD660
├─sdf8 ntfs H_BKUP_Q 01D23F47243078B0
├─sdf9 ntfs VMS 01D23F47A212E1A0
├─sdf10 ntfs WXP_SWAP 01D23F47A65482F0
├─sdf11 ntfs Win8 BackUps 01D23F5DFB803EC0
└─sdf12 ntfs Tunes_Backup 01D23F5A4D597300
sdg
├─sdg1 ext4 1.0 lx_recov aa716ef1-9b4b-4d9c-83e6-967b9055fb0b
├─sdg2 swap 1 67096c21-c8ff-4a2c-b1c8-4775645f9f53 [SWAP]
├─sdg3
├─sdg5 ext4 1.0 lx_vms f3d69676-6d93-4a14-a839-d178f7c2f2b4 13.9G 88% /mnt/vms
├─sdg6 ext4 1.0 lx_wxp_h accd1fcb-1ec0-4ac9-a59a-aa6f8d7b6e5b
└─sdg7 ext4 1.0 lx_wxp_pg 2dad0846-9cc0-4997-83a9-e63afa4f51c6
sr0
sr1
sr2

[t42]

It should be no problem if you have in fstab such line as below, (and if swap partition indicated in fstab than it is sdg2 and 67096c21-c8ff-4a2c-b1c8-4775645f9f53, but most likely swap-file is used)
UUID=15b5978f-c6e4-42b2-ad64-6f8813034ef7 / ext4 errors=remount-ro 0 1
... provided that grub installed in MBR of sda and is pointing to sda1.
If it not the case, boot into sda1 using your workaround and run

Code: Select all

sudo grub-install /dev/sda1
sudo update-grub

[xGuy]

Thanks again.

Perhaps I didn't make it clear enough that actually the system is booting fine. I was trying to understand why it was necessary to force GRUB to use the new root partition - previously on Mint 19 this was never necessary following a similar cloning exercise.

This is the /etc/fstab on the cloned system :-

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sde12 during installation
UUID=15b5978f-c6e4-42b2-ad64-6f8813034ef7 / ext4 errors=remount-ro 0 1
# swap was on /dev/sdg2 during installation
UUID=67096c21-c8ff-4a2c-b1c8-4775645f9f53 none swap sw 0 0

UUID=f3d69676-6d93-4a14-a839-d178f7c2f2b4 /mnt/vms auto nosuid,nodev,nofail,x-systemd.device-timeout-timeout=1 0 0
# comment next six lines out to avoid low space warning prompts
UUID=51536171-4ba0-4394-b301-d97964ee4015 /mnt/lx_wxp_g auto nosuid,nodev,nofail,x-systemd.device-timeout-timeout=1,user,noauto 0 0
UUID=accd1fcb-1ec0-4ac9-a59a-aa6f8d7b6e5b /mnt/lx_wxp_h auto nosuid,nodev,nofail,x-systemd.device-timeout-timeout=1,user,noauto 0 0
UUID=ecd230dd-b62e-4b0d-9b7a-3133a633da44 /mnt/lx_wxp_j auto nosuid,nodev,nofail,x-systemd.device-timeout-timeout=1,user,noauto 0 0
UUID=2dad0846-9cc0-4997-83a9-e63afa4f51c6 /mnt/lx_wxp_pg auto nosuid,nodev,nofail,x-systemd.device-timeout-timeout=1,user,noauto 0 0
UUID=f5eaa331-025d-4e5b-a78d-43faff7da252 /mnt/lx_wxp_qh auto nosuid,nodev,nofail,x-systemd.device-timeout-timeout=1,user,noauto 0 0
UUID=b2cdaf71-fae2-4626-8e5c-0e7d4789ba58 /mnt/lx_wxp_rj auto nosuid,nodev,nofail,x-systemd.device-timeout-timeout=1,user,noauto 0 0
UUID=3c1e4b32-dc7d-4e44-a3a3-b407c951c498 /mnt/lx_wksp_a auto nosuid,nodev,nofail,x-systemd.device-timeout-timeout=1,user 0 0
UUID=061c212f-354d-43b6-a764-ff290d5f236e /mnt/lx_wksp_b auto nosuid,nodev,nofail,x-systemd.device-timeout-timeout=1,user 0 0
UUID=ee288dab-414b-454f-bb27-7c1c02594c86 /mnt/lx_wksp_c auto nosuid,nodev,nofail,x-systemd.device-timeout-timeout=1,user 0 0
UUID=f2bacc74-ab12-466c-8c67-550fc5b00837 /mnt/lx_wksp_d auto nosuid,nodev,nofail,x-systemd.device-timeout-timeout=1,user 0 0
UUID=3dbaf884-f0f1-4aa0-980b-7dcde63d33d1 /mnt/lx_wksp_xa auto nosuid,nodev,nofail,x-systemd.device-timeout-timeout=1,user,noauto 0 0
UUID=901f3d3d-b455-451c-a96a-9792b1e11a4a /mnt/lx_wksp_yb auto nosuid,nodev,nofail,x-systemd.device-timeout-timeout=1,user,noauto 0 0
UUID=01D23F2C6BA96460 /mnt/tunes auto uid=1000,gid=1000,nosuid,nodev,nofail,x-systemd.device-timeout-timeout=1,user,noauto 0 0
UUID=01D23F5A4D597300 /mnt/tunes_bu auto nosuid,nodev,nofail,x-systemd.device-timeout-timeout=1,user,noauto 0 0
UUID=01D23C4DB22E8FF0 /mnt/car_tunes auto nosuid,nodev,nofail,x-systemd.device-timeout-timeout=1,user,noauto 0 0
UUID=F6BE2B29BE2AE23B /mnt/videos_a ntfs uid=1000,gid=1000,nosuid,nodev,nofail,x-systemd.device-timeout-timeout=1,user,noauto 0 0
UUID=5680CF1380CEF90F /mnt/videos_a_bu ntfs uid=1000,gid=1000,nosuid,nodev,nofail,x-systemd.device-timeout-timeout=1,user,noauto 0 0
# next line commented out as Disk Manager can't mount the partition
#UUID=01D157C93738B000 /mnt/WD1TB ntfs uid=1000,gid=1000,nosuid,nodev,nofail,x-systemd.device-timeout-timeout=1,user,noauto,iocharset=utf8 0 0

I also found that having inserted the line :-

GRUB_DEVICE_UUID=15b5978f-c6e4-42b2-ad64-6f8813034ef7

into the cloned system's /etc/default/grub and chrooted to that system it was not sufficient to merely call update-grub. I had to also call grub-install /dev/sda.

There is the slight complication that both mint21root and mint19root reside on /dev/sda in /dev/sda1 and /dev/sda2 respectively. Of course that means that if one system runs grub-install /dev/sda then it becomes the default OS to load off /dev/sda. Then if the other system does the same thing then it becomes the default system. But I'm used to that and I don't think it is relevant here since until my "fix" I couldn't boot the cloned system using chaining off any HDD which had a grub and a Mint OS on it - it always booted the donor system.

I'm still thinking that somewhere in the cloned system perhaps in a file in /etc or /boot there is the character string :-

UUID="e1628cb5-9184-4b88-91b6-124ebf95ded2"

which is the UUID of the root partition of the "donor" system m21_recov and that GRUB, in the absence of the GRUB_DEVICE_UUID directive, is picking this up and using it as the root partition rather than UUID=15b5978f-c6e4-42b2-ad64-6f8813034ef7 as in /etc/fstab.

Another interesting point is that prior to my discovering GRUB_DEVICE_UUID, I tried simply uncommenting GRUB_DISABLE_LINUX_UUID=true in /etc/default/grub :-

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
GRUB_DISABLE_LINUX_UUID=true

and then called sudo update-grub and grub-install /dev/sda. My thinking was that this would mean that the booting process would just pick up the correct root partition ID from /etc/fstab. But it didn't.

A mystery!

[t42]

and then called sudo update-grub and grub-install /dev/sda

Of course first grub-install and second update-grub.

If you want to investigate further install boot-info-script

Code: Select all

sudo apt install boot-info-script

and run

Code: Select all

sudo bootinfoscript ~/Desktop/results.txt

results.txt will contain all relevant information.

[xGuy]

Thanks - I tried bootinfoscript as you suggested .

However it has generated an enormous amount of information and I have no idea what, if any, of it might be relevant!

[t42]

Expected output of the first paragraph of Boot Info Summary for your configuration is

Code: Select all

Grub2 (v2.00) is installed in the MBR of /dev/sda and looks at sector 1 of 
    the same hard drive for core.img. core.img is at this location and looks 
    for (,msdos1)/boot/grub.

If it is not the same then your initial setup process was not what you think it was.

[xGuy]

The first few lines of the file read :-

Boot Info Script 0.78 [09 October 2019]


============================= Boot Info Summary: ===============================

=> Grub2 (v2.00) is installed in the MBR of /dev/sda and looks at sector 1 of
the same hard drive for core.img. core.img is at this location and looks
for (,msdos2)/boot/grub. It also embeds following components:

modules
---------------------------------------------------------------------------
---------------------------------------------------------------------------
fshelp ext2 part_msdos biosdisk
---------------------------------------------------------------------------

I guess the reason why it is saying it looks for (,msdos2)/boot/grub is that although I originally called grub-install /dev/sda from the Mint21 system, I later repeated the call from the Mint19 system. This was because my live system is still Mint 19 and for now I'm happy to load Mint21 from Mint19's grub - obviously that will change at a later date. What i will do is to go back into Mint21 and repeat update-grub and grub-install /dev/sda and rerun bootinfoscript then re-post the results.

[t42]

and repeat update-grub and grub-install

but not in that order

[xGuy]

Thanks for your quick reply but I had already done update-grub followed by grub-install /dev/sda while booted in the Mint21 system, then rebooted it. And the result from bootinfoscript was as expected :-

Boot Info Script 0.78 [09 October 2019]


============================= Boot Info Summary: ===============================

=> Grub2 (v2.00) is installed in the MBR of /dev/sda and looks at sector 1 of
the same hard drive for core.img. core.img is at this location and looks
for (,msdos1)/boot/grub. It also embeds following components:

modules
---------------------------------------------------------------------------
fshelp ext2 part_msdos biosdisk
---------------------------------------------------------------------------

Feeling brave at this point I edited /etc/default/grub to comment out the line :-

#GRUB_DEVICE_UUID=15b5978f-c6e4-42b2-ad64-6f8813034ef7

and reran update-grub again plus grub-install for good measure. I fully expected the system to boot from the mint 21 recovery system (the clone donor) and to have to chroot into the main Mint21 system to re-establish grub. But I didn't - it simply booted perfectly into the correct system.

So something has changed. For the better certainly but it means I can no longer reproduce the original problem. I definitely did not imagine it!

I thank you for all your help but I think it's best to just leave this as unsolved. I think I will uncomment GRUB_DEVICE_UUID again just in case the problem were ever to resurface and catch me unawares sometime in the future.

[t42]

Just for clarity and for the sake of accidental visitor: the problem was solved after booting into the system in question located on sda1 and reinstalling grub2 from within it:

Code: Select all

sudo grub-install /dev/sda1
sudo update-grub

That's it.

[xGuy]

That's unusual to run grub-install before update-grub rather than the other way round. I don't understand the significance!