Announcement

**oshunluvr** · Jun 12, 2019, 06:44 AM

Does clonezilla also copy the UUID? Duplicate UUIDs would cause shenanigans like this.

**Snowhog** · Jun 12, 2019, 06:50 AM

Yes, it does. Clonzilla makes a 'bare metal' backup. So in this use case, both drives are reported with the same UUID. It would be interesting to see what sudo blkid reports.

**claydoh** · Jun 12, 2019, 07:10 AM

Did you clone the entire drive, or just the partition?

And to be clear, you cloned from the install on the sda drive to the sdb drive, correct?

If you were going to clone sda to sdb, why bother installing to sdb? You are completely overwriting that fresh install when you clone a full disk image to it, so the install is sort of useless and wasted effort here.

Anyway, let's see what your specific partition list is

Code:

df -h

My guess is that you cloned the entire disk, which includes the /EFI partition, to the other drive, so you know have two /EFI (which is OK), one on each drive.
The /EFI partition is what your systems uefi firmware needs in order to boot an OS, on top of having the boot item registered with it in nvram.
Both of these, being clones of each other, have the exact same boot info, which is for the first Neon, and there is no boot info for the new one. As uefi actually is the part doing the multiboot, it does not matter where you install grub. You can fix it I think by using an advanced features in the boot-repair program run from a live disk (not found in the usual Ubuntu repos, iirc) or some chroot and command line fu.

Not 100% sure in your case at the moment what will be the correct steps to take in your case.

Now, you can use clones of individual partitions as well as whole disk backups, so you could clone just a /home partition. If you install using a custom setup to create a separate /home (as many of us do), then cloning just that bit won't mess around with your efi stuff, and is NOT redundant or useless on a fresh OS install. You get all your data, but no added software or root-level tweaks. Of course you can also clone/restore "/" if you choose, and keep your existing /EFI, if it is working properly.

**Don B. Cilly** · Jun 12, 2019, 09:15 AM

Yes.
Clonezilla duplicated the UUID. Not the PARTUUID, though...

Code:

/dev/sda1: LABEL="K14" UUID="4d8f0727-3f74-46ca-9b8f-bb6aa04ac6f8" TYPE="ext4" PARTUUID="000aef22-01"
/dev/sda2: LABEL="NEON" UUID="[B]879b2424-5b36-49b4-a53b-f51dbde63b30[/B]" TYPE="ext4" PARTUUID="000aef22-02"
/dev/sda3: UUID="d697a1d9-5452-4aba-bb15-0c3103238c71" TYPE="swap" PARTUUID="000aef22-03"
/dev/sda4: UUID="8EF0-A702" TYPE="vfat" PARTUUID="000aef22-04"
/dev/sdb1: LABEL="SSD_Neon" UUID="[B]879b2424-5b36-49b4-a53b-f51dbde63b30[/B]" TYPE="ext4" PARTUUID="6e09a355-01"
/dev/sdb2: LABEL="SSD2" UUID="5c3af4ec-b016-4eea-accd-23d517b87248" TYPE="ext4" PARTUUID="6e09a355-02"
/dev/sdb4: UUID="754B-22C4" TYPE="vfat" PARTUUID="6e09a355-04"
/dev/sdb5: UUID="bbb7dbfc-e767-43c9-8b99-614bbaab2cc5" TYPE="swap" PARTUUID="6e09a355-05"
/dev/sdc1: LABEL="K18" UUID="3733e2b4-b159-434d-a4d2-ab4cb0cfa031" TYPE="ext4" PARTUUID="85e3aaee-01"
/dev/sdc2: LABEL="joey" UUID="13a64598-bbd5-489d-a193-4ebc1cad8072" TYPE="ext4" PARTUUID="85e3aaee-02"
/dev/sdc3: UUID="239B-2FC4" TYPE="vfat" PARTUUID="85e3aaee-03"
/dev/sdc4: LABEL="joey-gnome" UUID="66336795-cced-40b0-93aa-0845872860fc" TYPE="ext4" PARTUUID="85e3aaee-04"
/dev/loop0: TYPE="squashfs"
...
/dev/loop8: TYPE="squashfs"

I only cloned the partition, /dev/sda2 onto /dev/sdb1.
I bothered installing ;·) (from USB) because I tried also cloning the EFI partirion and it didn't (seem to) work, so I thought, hey.

So, can I change the UUID by booting into one of the other distros (or the live) - or, since that disk is not mounted, from this one anyway?
Any command-line magic? Oh, OK, I'll look it up.
Alternatively I can re-clone, it doesn't take that long - "only" some 40G used - but how to avoid the... no, OK, I'll look that up too.
Thanks for the help, you found the culprit, I'll let you know.

BTW, that "joey-gnome" on sdc4 is an old Ubuntu 10.04 I still keep because... oh, I don't know why

**Don B. Cilly** · Jun 12, 2019, 10:04 AM

O. My. Dog.
It is a mystery.
I changed the disk's UUID. With gparted, easy peasy. Look:

Code:

/dev/sda2: LABEL="NEON" UUID="879b2424-5b36-49b4-a53b-f51dbde63b30" TYPE="ext4" PARTUUID="000aef22-02"
...
/dev/sdb1: LABEL="SSD_Neon" UUID="3331581b-e3a3-4976-86a3-bbfc025262be" TYPE="ext4" PARTUUID="6e09a355-01"

I updated grub:

Code:

Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.18.0-21-generic
Found Ubuntu 14.04.6 LTS (14.04) on /dev/sda1
Found KDE neon Unstable Edition (18.04) on /dev/sdb1
...
Adding boot menu entry for EFI firmware configuration
done

So, I tell it to boot KDE neon Unstable Edition (18.04) on /dev/sdb1.
It boots the one on sda2.
So, hmmm...,I have grub set to boot the last booted entry. Maybe it got "confused" in some other way. So I reboot with the default Neon. Re-update grub. Re-reboot and tell it please, the sdb1 Neon. It boots the sda2 one.
Annoying annoying.
I'll keep trying :·/

**claydoh** · Jun 12, 2019, 11:00 AM

you need to recover grub, or rather, create the boot entry in your system's bios efi setup, which you can't do from different running OS.

The grub menu must passes things to the efi boot manager for booting the other Neon. You still need the correct info to be created in an /EFI folder for that other Neon, no matter what you do with grub. uuids don't matter if they are not set up in an /EFI folder.

If we can see the partition layout, we should be able to recreate the needed config for it.,

What is needed is the output of:

$ dh -f

and

$ efibootmgr

**Don B. Cilly** · Jun 12, 2019, 11:59 AM

dh -f basically returns "huh?" so, assuming you meant:

Code:

not@all:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            3.9G     0  3.9G   0% /dev
tmpfs           795M  1.4M  793M   1% /run
/dev/sda2       178G   39G  131G  23% /
tmpfs           3.9G   48M  3.9G   2% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/loop1       89M   89M     0 100% /snap/core/6964
/dev/loop0      128K  128K     0 100% /snap/cnctsun/58
/dev/loop2       54M   54M     0 100% /snap/core18/970
/dev/loop4       36M   36M     0 100% /snap/gtk-common-themes/1198
/dev/loop5      457M  457M     0 100% /snap/wine-platform/128
/dev/loop7       90M   90M     0 100% /snap/core/6818
/dev/loop6       74M   74M     0 100% /snap/wine-platform-3-stable/6
/dev/loop8      128K  128K     0 100% /snap/cnctsun/59
/dev/loop3      217M  217M     0 100% /snap/wine-platform-runtime/6
/dev/sda4       212M  6.0M  206M   3% /boot/efi
tmpfs           795M   12K  795M   1% /run/user/1000
/dev/sdb1       252G   39G  201G  16% /media/not/SSD_Neon

(yes, I mounted /dev/sdb1 to check things, usually it's not).
and

Code:

not@all:~$ efibootmgr
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0000,0001
Boot0000* opensuse-secureboot
Boot0001* Hard Drive 
Boot0003* neon

**claydoh** · Jun 12, 2019, 12:48 PM

Cool. The disk layout would be shown, mounted or not.
Only one efi partition, that's good.

Now, I messed up a little, I should have had you run the efi manager command with the -v option, to see more info

Code:

efibootmgr -v

Now:

Code:

not@all:~$ efibootmgr
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0000,0001
Boot0000* opensuse-secureboot
Boot0001* Hard Drive 
Boot0003* neon

So far, this looks OK, except for the "hard Drive", the extra info requested will help figure that out.
Is the opensuse entry still still in use?

What the plan is, we will delete any useless entries, if any.
Then we will mount some directories from the 'missing' Neon in a chroot so we can run commands on them like it was a running OS. We'll then run some commands to rebuild the missing Neon boot stuff.

One thing we didn't check, as this is a uefi system is to see if the missing Neon could be booted from your computer's built in efi boot selection menu. I doubt it would, without seeing more info. Grub only comes into play *after* the bios/efi loads the boot info from the /EFI partition and loads info from its nvram. So , it is often possible to boot an OS even if another OS's grub doesn't know about it.

**Don B. Cilly** · Jun 12, 2019, 03:19 PM

Code:

not@all:~$ efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0000,0001
Boot0000* opensuse-secureboot   HD(3,MBR,0x85e3aaee,0x12c1a000,0x9ff800)/File(\EFI\opensuse\shim.efi)
Boot0001* Hard Drive    BBS(HD,,0x0)..GO..NO...o.C.T.5.0.0.M.X.5.0.0.S.S.D.1...A...>..Gd-.;.A..MQ..L.9.1.3.1.1.E.6.F.3.C.5.4. . . . . . . . ...BO..NO...u.W.D.C. .W.D.3.2.0.0.A.A.J.S.-.0.0.L.7.A.0...A...>..Gd-.;.A..MQ..L.

. . . .W. .-.D.C.W.V.A.J.2.9.2.7.2.9.4...BO..NO...o.W.D.C. .W.D.1.0.E.Z.E.X.-.2.2.M.F.C.A.0...A...>..Gd-.;.A..MQ..L. . . . .W.

.-.D.C.W.6.C.5.Y.N.X.J.V.F.A...BO
Boot0003* neon  HD(4,MBR,0xaef22,0x7369b000,0x6b800)/File(\EFI\neon\shimx64.efi)

Ugly, eh? ;·)
The opensuse entry is still there (somewhere in the EFI, but it's not in use as the opensuse system is not anywhere anymore.
The "hard drive" is the oldest of the tree drives and is seen "as that" by the BIOS.
Still, I think I have three EFI partitions, sda4, sdb4 and sdc3...

**jlittle** · Jun 12, 2019, 03:24 PM

Originally posted by claydoh View Post

... this looks OK, except for the "hard Drive"...

Something adds a "Hard Drive" boot entry to the EFI boot list on my system. If I delete it with efibootmgr it reappears later, maybe after the next boot. I presume it's the UEFI on the motherboard, a Gigabyte. It's a nuisance because it shows several lines of junk with efibootmgr -v.

Sent from my VFD 822 using Tapatalk

**Qqmike** · Jun 12, 2019, 03:35 PM

Yep, I've always noticed such entries in the UEFI boot list. Like right now, though I have only one hard drive and one OS, efibootmgr included this strange entry:

Code:

Boot0008* Hard Drive    BBS(HD,,0x0)..GO..NO........O.W.D.C. .W.D.5.0.0.3.A.Z.E.X.-.0.0.M.K.2.A.0.................>..Gd-.;.A..MQ..L. . . . .W. .-.D.C.W.3.C.5.F.F.X.2.6.F.K........BO

I always ignore these things, instead focusing on what I do recognize and need.

**claydoh** · Jun 13, 2019, 07:53 AM

We will need to know which partition is /EFI on the sdb drive

Code:

sudo mount /dev/sdb1 /mnt
sudo mount /dev/[B]sdb4[/B] /mnt/boot/efi <<<<<<substitute the correct drive here if necessary
for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
sudo cp /etc/resolv.conf /mnt/etc/
sudo chroot /mnt
apt-get install --reinstall grub-efi-amd64

Now, exit out of this, and run sudo update-grub on your running system.

Reboot and try booting to the new Neon via the computer's boot menu (not via the grub menu). If it does not show, you may have to go into the bios and turn off fast-boot, and look at the boot settings to see if it shows there.
There should be a grub menu, but do realize that this is the Grub for the SDB Neon. Each Linux will have its own grub.

Now boot normally, and see if the original, SDA Grub boots the new Neon.

Now, if things are working fine all around, and all Grubs are booting all the OSs you want them to, you are good to go.

Now, if SDB Neon is going to be your main OS, then you will want to make that disk the first boot disk, so if you decide to format the other drive for storage, or something, your normal OS is not touched.
if you decide to dual boot, just remember that each one has its own grub. If you install say, Arch, Neon's grub won't know about it until you manually update grub there.

**Don B. Cilly** · Jun 13, 2019, 08:07 AM

OK. Because I tried re-installing grub to sda - after changing the sdb UUID.
It said:

Code:

Installing for x86_64-efi platform.
GUID Partition Table Header signature is wrong: be5608740128e852 != 5452415020494645
GUID Partition Table Header signature is wrong: 0 != 5452415020494645
GUID Partition Table Header signature is wrong: be5608740128e852 != 5452415020494645
GUID Partition Table Header signature is wrong: 0 != 5452415020494645
GUID Partition Table Header signature is wrong: be5608740128e852 != 5452415020494645
GUID Partition Table Header signature is wrong: 0 != 5452415020494645
Installation finished. No error reported.

So, lots of errors but no errors. Oh Well. Anyway, it didn't work because it still boots the sda Neon (when I tell it to boot the other one).

So, I'll happily try all that, just... when you say
sudo mount /dev/sdb4 /mnt/boot/efi <<<<<<substitute the correct drive here if necessary
you mean the EFI partition on the SSD, right?

**claydoh** · Jun 13, 2019, 08:44 AM

So, I'll happily try all that, just... when you say
sudo mount /dev/sdb4 /mnt/boot/efi <<<<<<substitute the correct drive here if necessary
you mean the EFI partition on the SSD, right?

yes, that's correct

Announcement

Grub mystery

[SOLVED] Grub mystery

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment