TeraByte Unlimited

Brian K wrote:
> 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.


OK. sorry. for mixing Paul and David there.
and that's something you helped me realize....is that when adding a new OS partition to a system, if you add a /ubuntu/ folder without a number on the end, BIU or something else changes it to a numbered /ubuntu/ partition....and simultaneously creates a new boot menu item.

Now, something else I've thought of.
After manually changing UUID and updating on the clone partition's /boot/grub/grub.cfg and /etc/fstab, why would the cloneOS still be remembering to boot the originalOS partition?
So I did a search of cloneOS /boot/ for the old UUID within any files using the old UUID

sudo grep -rnw /media/bruce/Mint9/boot -e fc44c5f4-ed74-47f7-9a61-06dc14ed9f77

and the only results was a file /boot/grub.bak/grub.cfg

So it is possible, the reason cloneOS is not booting when using local core.efi or grub.efi is because some error throws the boot process back to using /boot/grub.bak/grub.cfg.

So I am now going to run this cloning procedure again, and delete /boot/grub.bak/ folder from the cloneOS before booting.

Bruce, if you don't have licensed versions of IFL and BIU then you can't do what I'm doing. Consider the TeraByte Special Bundle. It really is great value...

https://www.terabyteunlimited.com/index.htm

Brian K wrote:
> Bruce, if you don't have licensed versions of IFL and BIU then you can't do
> what I'm doing. Consider the TeraByte Special Bundle. It really is great
> value...
>
> https://www.terabyteunlimited.com/index.htm

There's three criteria I am looking for in BIU:
- imaging
- partition manipulation
- boot manager

BIU currently
- succeeds in imaging
- fails on partition manipulation (due to the unacceptably slow performance on the Dell Latitude 5289.....Gparted is better, though would mean doing operations from a bootable USB drive in many instances)
- fails on Linux boot management due to all the issues apparently related to GRUB.... whereas rEFInd makes trouble free boot menu items from
/boot/vmlinuz-4.15.0-20-generic
which apparently circumvent reliance on /EFI/.

An advantage of BIU is all three criteria can be done from an installed application, without booting an OS.
However, at this point, I am leaning towards using rEFInd as my boot manager and Gparted for partition manipulation.
I have an older license which I can do imaging with.

edit:

Another issue with BIU, is often when I switch between UEFI and LEGACY BIOS mode, BIU is kicked from top position in BIOS boot order, and needs to be reset.
BIU also often needs to be reactivated when installing Linux OSs.
Granted I won't be doing OS testing on an ongoing basis, but these limitations have me looking at other options.

>- fails on partition manipulation (due to the unacceptably slow
>performance on the
> Dell Latitude 5289.....Gparted is better, though would mean doing
> operations from a
> bootable USB drive in many instances) "

The speed is related to your BIOS. You can boot IFL full version and use
partwork included with it to bypass a slow BIOS.

>- fails on Linux boot management due to all the issues apparently related
>to GRUB.... "

You simply install a linux distro and a boot item shows up that you boot.

Your wanting to do things manually means you need to update some values
manually. If you copy a partition, it will make a copy, if you choose to
set a new GUID (which you should), it will, if you change the uuid, it will
update the uuid and references within the partition if at standard
locations, but won't search out all the items in \efi\ to change it because
it will end up changing ones that boot the copied partition so those would
end up booting the copy as well (for windows users in partition work copy,
there is an option to create the boot item automatically, but not for
linux). Instead, you'll need to update what you want when copying over the
\efi\ directory for the distro. Some distros use the GPT entry number, some
GUID, some UUID.

Of course, you have the complete flexibility to point your boot item to boot
using the kernel loader within the partition if it exists and works.

If there is no reference to the GPT GUID in the kernel loader, you can also
setup a new boot item that uses the existing item in \efi in the ESP, by
using the hiding and position options.

>>Another issue with BIU, is often when I switch between UEFI and LEGACY
>>BIOS mode,
>> BIU is kicked from top position in BIOS boot order, and needs to be
>> reset.
>> BIU also often needs to be reactivated when installing Linux OSs.

That's your BIOS or the installer changing the order, any boot manager or OS
would be the same.

I timed a Mint copy using the IFL 2.26 method. Start to finish was 2.5 minutes. (BIU desktop to BIU desktop)

The clone booted normally.

TeraByte Support wrote:

>
> The speed is related to your BIOS. You can boot IFL full version and use
>
> partwork included with it to bypass a slow BIOS.
>

Thanks for your considered replies.

Partition work with Gparted is not slowed by BIOS.

Image for UEFI, or Image for Dos are by no means slow.
In fact they are brilliantly fast.

How does that reconcile with BIU partition work being hobbled by BIOS?



> >- fails on Linux boot management due to all the issues apparently related
>
> >to GRUB.... "
>
> You simply install a linux distro and a boot item shows up that you boot.
>
> Your wanting to do things manually means you need to update some values
> manually. If you copy a partition, it will make a copy, if you choose to
> set a new GUID (which you should), it will, if you change the uuid, it will
>
> update the uuid and references within the partition if at standard
> locations, but won't search out all the items in \efi\ to change it because
>
> it will end up changing ones that boot the copied partition so those would
>
> end up booting the copy as well (for windows users in partition work copy,
>
> there is an option to create the boot item automatically, but not for
> linux). Instead, you'll need to update what you want when copying over
> the
> \efi\ directory for the distro. Some distros use the GPT entry number, some
>
> GUID, some UUID.
>
> Of course, you have the complete flexibility to point your boot item to
> boot
> using the kernel loader within the partition if it exists and works.
>


Giving BIU the capacity to boot kernel stubs would seem the most parsimonious path to me.
i.e. being able to create a boot menu item that uses the kernel file as the BOOT FILE, as I presume happens in rEFInd....or have I got that wrong?

When rEFInd boots using the Linux kernel stub of a cloned partition, it boots the cloned partition,



> If there is no reference to the GPT GUID in the kernel loader, you can also
>
> setup a new boot item that uses the existing item in \efi in the ESP, by
> using the hiding and position options.
>
> >>Another issue with BIU, is often when I switch between UEFI and LEGACY
> >>BIOS mode,
> >> BIU is kicked from top position in BIOS boot order, and needs to be
> >> reset.
> >> BIU also often needs to be reactivated when installing Linux OSs.
>
> That's your BIOS or the installer changing the order, any boot manager or
> OS
> would be the same.


Thanks...I'll try to understand the above over the weekend and consider it in a few trials.

Brian K wrote:
> I timed a Mint copy using the IFL 2.26 method. Start to finish was 2.5
> minutes. (BIU desktop to BIU desktop)
>
> The clone booted normally.

Yes if there is no duplication of UUIDs on a machine, then I presume you have eliminated the issues of cloning onto the same drive.

What's apparent is to remove all association of a clone with the UUID of the original partition requires more than editing grub.cfg and fstab.

But I am exhausted from digging around in the dark, and there's no documentation on the net of how to dual boot a clone.
And this is not an issue for rEFInd.

brucebne wrote:

>
> Image for UEFI, or Image for Dos are by no means slow.
> In fact they are brilliantly fast.
>

IFL is at least 3 times faster again. On my computers.

OK, over home made vietnamese chicken salad, I just cloned Mint.
WIthout changing UUID I tried to boot into original and clone using both BIU and refind. neither were successful at correctly discriminating the two partitions.

Then I just changed the UUID....once again neither was consistent in discriminating which it booted into.

Then I changed clone's grub.cfg and fstab.

Both BIU and refind were able to boot into each successfully multiple times.

Interestingly Brian, I think we both ahd experiences last night where we couldn't do this.

I am thinking maybe it something to do with the order of the clone on the drive, relative to the original, and their allocated /dev/ numbers

Or maybe booting both OS with refind is changing some flag on the clone that helps BIU not get confused.

With such a long thread, I decided to do what it looked like someone was
trying to do, copy an installed mint partition on gpt using uefi boot. I
had a system handy with 3 hard drives (scsi, nvme, and sata) where
everything was installed on HD1 (sata) from point of view of BIU; including
mint 18.3. I fired up disk imaging, copied the single mint partition to
the end of the drive using the option to change guids, change volume sn, new
name of "mint copy", when done, exit and went to scripting and did a "list
hd 1" and can see the copy is now entry D (13), so I get the UUID, "list
volsn 1 0xd" (or "list volsn 1 13") and copy that down (no copy/paste
available, dang, a tbs script could automate all this), while there, I also
"md \efi\ubuntu.100" and "copy \efi\ubuntu.001 \efi\ubuntu.100 /s". Then
exit that and go to Edit File, open up the \efi\ubuntu.100\grub.cfg file and
change the UUID reference to the one I copied down, also changed the
"hd0,11" to "hd0,13" (point of view from grub) since the new gpt slot it's
in is 13. Save changes, setup boot item matching the other one, booting hd
1, boot file is now "\efi\ubuntu.100\grubx64.efi", enable rename directory
option, save. Attempt to boot, and goes to grub rescue, using camera on
phone, capture the error messages saying it can't read some sectors from
HD2, so that tells me right away, the drive reference is off, so I go back
to disk imaging, do the copy again using the same options, but adding
"Assume Original HD" option. Once done, had to go get the new UUID again,
apply that change in grub.cfg, then attempt to boot, and it booted right up.
checked the mouse with "mount" command and the copy was root.

So the options to use when doing the copy with multiple hard drives like
that is to use "change guid", "change volume sn", "assume original hd".
Updating grub, you update the uuid and gpt slot number the partition is in,
which is the ID.