How to boot from an EUFI original or clone Linux partition

[Brian K]

brucebne wrote:

>
> recheck none of your BIU boot menu item changes were overwritten.
>

Just checked them. All are OK.

I tried to boot the original Mint from its ubuntu.xxx. It now won't boot. But the 2 clones boot using their ubuntu.xxx Boot Files.

Bed time too.

[brucebne]

Brian K wrote:
> brucebne wrote:
>
> >
> > recheck none of your BIU boot menu item changes were overwritten.
> >
>
> Just checked them. All are OK.
>
> I tried to boot the original Mint from its ubuntu.xxx. It now won't boot. But the 2
> clones boot using their ubuntu.xxx Boot Files.
>
> Bed time too.


LOL.... time for hot coffee. then bed.
I think there's things about the /ubuntu.00x/ folders that are not stable.
Their numbers change when other OSs are added.
This is why I'd prefer to use the *.efi on the partition being booted.
At least you know it isn't going to be changed like that.

I've just triple checked my clone, and it is definitely booting after following the steps I outlined.
Go over it again in the morning when you are fresh.....and make sure you are doing all the changes in the clone partition.
Too easy to be in the wrong partition with this exercise.

[TeraByte Support]

Changing the UUID will update items in /boot/grub and /boot/grub2 but it's
not going to find grub.cfg in other directories. You can script that, or in
fact the whole thing can be scripted to match your distro.



PartWork, Edit File, paste the uuid into ubuntu\grub.cfg (ctrl-v). Save

[Brian K]

brucebne wrote:

> I think there's things about the /ubuntu.00x/ folders that are not stable.
> Their numbers change when other OSs are added.

Now I'd remember that. It has never happened to me. Not once.


> Go over it again in the morning when you are fresh.....and make sure you are doing
> all the changes in the clone partition.
> Too easy to be in the wrong partition with this exercise.


I checked it today, Partitions and Boot File OK. I even tried core.efi again. No go. I get the grub boot menu, then error text and no Mint. I can't boot the original Mint (not a copy) via ubuntu.xxx. Whatever I did corrupted the original Mint.

[Brian K]

Restored an ESP image, restored the original (not a copied partition) Mint image. All OK again.

[Brian K]

brucebne wrote:
>
>
> Thanks. where do the upgraded versions have their changes listed....can't find them
> on the website.
>

https://www.terabyteunlimited.com/upgra ... -metal.htm

[brucebne]

Brian K wrote:
> Restored an ESP image, restored the original (not a copied partition) Mint
> image. All OK again.

Wise man to have all backed up

OK, I realized last night I am the one deluded.
The changes I made to grub.cfg I believe won't mean anything unless "sudo update-grub" is done.

I tried my method on my 2nd laptop and it didn't work. I got a similar outcome to you. Couldn't boot into the clone, only the original.

However, I installed rEFInd and it can boot the clone with a boot menu item that lists /cloneOS/boot/vmlinuz-4.15.0-20-generic as the boot loader file.

[Brian K]

This is a fascinating thread. I'm much more knowledgeable now.

[brucebne]

OK OK OK.

Another small step in the right direction here after contemplating Paul's input above.

I pondered what might be different about my latest method vs the one from a day or two ago.
and realized I am using two different means to change UUID.
In the first, I used command line, and last night was using Gparted's shortcut.
I figured maybe the command line method updates some of the grub files, and Gparted doesn't.

So what I have just done now resulted in a BIU boot menu item using CloneOS/ /boot/grub/x86_64-efi/grub.efi booting the clone partition..... which is an improvement on last night.

Steps:

boot up a Mint partition, not the clone.
do not mount the clone
in command line run
blkid (to get clone partition number if not already known) = /dev/nvme0n1p9
sudo e2fsck -f /dev/nvme0n1p9
sudo tune2fs -U random /dev/nvme0n1p9

confirm new UUID via disks software.
mount clone partition

in clone partition, put new UUID in /etc/fstab and /boot/grub/grub.cfg

Now, this is the bit that I am foggy about.... for the cloneOS grub changes to be 'dispersed', I'd imagine a sudo update-grub command would have to be made FROM the clone OS.
This is a step I was missing last night.
However, this morning, I just did sudo update-grub from the OS partition I did all the changes, but I can't imagine how this would effect the cloneOS.

Anyway, I rebooted using a BIU boot menu item edited as
BOOT : clone partition
BOOT FILE: /boot/grub/x86_64-efi/grub.efi

and it successfully booted the cloneOS.

So I can only imagine that doing a command line UUID change, is different to doing this change from within Gparted.

---------------------------------------------

edit:
using core.efi does not boot into the clone partition....but the original.

further, Paul's comment above about having to manually change /ubuntu/grub.cfg is a reason I'd prefer to use cloneOS /boot/grub/x86_64-efi/grub.efi
as I presume it will be referencing grub.cfg on cloneOS, and not on ESP/ubuntu/

[Brian K]

brucebne wrote:

> further, Paul's comment above about having to manually change
> /ubuntu/grub.cfg is a reason I'd prefer to use cloneOS
> /boot/grub/x86_64-efi/grub.efi
> as I presume it will be referencing grub.cfg on cloneOS, and not on
> ESP/ubuntu/

That was David but "PartWork, Edit File, paste the uuid into ubuntu\grub.cfg (ctrl-v). Save" was quoting my post. In IFL, as I was using, EFI\ubuntu\grub.cfg is the clone. I deliberately used ubuntu instead of ubuntu.xxx so that a Boot Item would be created.