TeraByte Unlimited

TeraByte Support wrote:
> 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 appreciate your interest, as I am sure Brian does.



> 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.


Excellent.
Some points of clarification:

- My issue has been with a laptop with one drive so not a multi-drive scenario....though obviously it is good to work towards being able to move partitions around to some pragmatic end..

- When you say you fired up disk imaging, then you copied......did you copy/paste the partition in work with partitions? ... or use "Image for Dos/Linux/UEFI" to make an image, then restore it to a different location?

- that all makes sense, apart from choosing the option "assume original hd", when you are pasting to another.

I am still on a BIU trial and don't have the 'change guid' and 'change volume sn' options for copy/paste operation in Work with Partitions.
Though if I can get most issues sorted, I'll certainly buy a BIU license.


_____________________________________________


Re the other issues:

The slow copy operation on the Dell Latitude:

This morning, I tried the copy operation with BIBM on USB.
The usb stick needs booting in Legacy mode.
I timed the copy operation to same drive (internal to laptop)

A 13.3GB partition took 3 minutes to clone.

I then ran BIU from a stick, and from an installation:

Both ways this same copy operation in 3 minutes, completed only 3% of the copy process.

The fact that BIBM doesn't have this slow copy issue, indicates the BIU copy problem cannot be solely due to the computer BIOS.
However, I don't have the slow copy issue on a Lenovo Yoga.

____________________________________________

brucebne wrote:

>
> I am still on a BIU trial and don't have the 'change guid' and 'change volume sn'
> options for copy/paste operation in Work with Partitions.
>
Bruce,

Those 2 options are not in Work with Partitions. They are in Disk Imaging (Image for UEFI). Your trial has Disk Imaging.

If I copy a Linux OS partition in Work with Partitions it takes 8 times longer than copying in Disk Imaging (Image for UEFI). Your computer could be different.


>> A 13.3GB partition took 3 minutes to clone.

That sounds like a Work with Partitions copy.


An IFL copy of Mint (7 GB resized partition) from one NVMe M.2 to another NVMe M.2 took 6 seconds. IFL is the fastest.

TeraByte Support wrote:
> 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.

TeraByte Support,

Thanks for that tutorial and I understand the exercise was to do everything from BIU. I know you won't mind if I do it in IFL as I can copy/paste the uuid.

You mentioned "also changed the "hd0,11" to "hd0,13" (point of view from grub) since the new gpt slot it's in is 13"

All of my grub.cfg have this format...

search.fs_uuid <uuid> root

They all finish with root although a few months ago I recall some finishing with a partition reference. But not now.

I've done several copies of Mint from Hard Drive 5 (in BIU) which contains the ESP and my other OS. I've copied to other drives without using "assume original hd" and the copied Mint has booted.

Sounds like BIU is missing the linux fs support on the build, will note to
check.

"Brian K" wrote in message news:[email protected]...
If I copy a Linux OS partition in Work with Partitions it takes 8 times
longer than copying in Disk Imaging (Image for UEFI). Your computer could be
different.

"Brian K" wrote in message news:[email protected]...

>>All of my grub.cfg have this format...
>>
>>search.fs_uuid root

This one had:
search.fs_uuid root hd0,11 for the original, 11 is is the gpt slot of
the original, new one was in gpt slot 13.

>>I've done several copies of Mint from Hard Drive 5 (in BIU) which contains
>>the ESP and my other OS. I've copied to
>> other drives without using "assume original hd" and the copied Mint has
>> booted.

As long as BIU and the Linux boot environment have the same drive ordering,
then the assume original hard drive isn't needed, with that, as long as it's
on the same hard drive, you can use it, if you moved it and the two didn't
agree, you'd have to reinstall grub.

Brian K wrote:
> brucebne wrote:
>
> >
> > I am still on a BIU trial and don't have the 'change guid' and 'change volume
> sn'
> > options for copy/paste operation in Work with Partitions.
> >
> Bruce,
>
> Those 2 options are not in Work with Partitions. They are in Disk Imaging (Image for
> UEFI). Your trial has Disk Imaging.
>
> If I copy a Linux OS partition in Work with Partitions it takes 8 times longer than
> copying in Disk Imaging (Image for UEFI). Your computer could be different.
>
>
> >> A 13.3GB partition took 3 minutes to clone.
>
> That sounds like a Work with Partitions copy.
>
>
> An IFL copy of Mint (7 GB resized partition) from one NVMe M.2 to another NVMe M.2
> took 6 seconds. IFL is the fastest.


Yes thanks Brian.
I am aware of Work with Partitions copy processes being slower than IFL/IFD imaging....but then you have to restore!
And I found when I use copy in WwP, I don't get the occasional error I did when using image/restore then booting a restored Linux OS partition.

I can accept copy function being 6x slower than imaging.....but not 60x slower!

Point noted about those 2 new options being in IFL.
I will check again.
(I try to be disciplined to only use 'copy' for the copy function withiin work for partitions.,,,,and I use imaging/restoring for IFL, IFD operations.

brucebne wrote:


> I am aware of Work with Partitions copy processes being slower than IFL/IFD
> imaging....but then you have to restore!

Bruce, I'm not sure what you mean as you are not restoring in Disk Imaging. You are using Copy.

OK, I think I understand the issue with the missing 2 new options in BIU.

Brian, you must be solely using BIBM, not BIU.

On the Terabyte website, on 7/2/19, BIBM was updated.
https://www.terabyteunlimited.com/bootit-bare-metal.htm

Whereas the last update for BIU was 8/12/19.
https://www.terabyteunlimited.com/bootit-uefi.htm
I have BIU installed.

I'll run BIBM and see what I get re the two new options.

brucebne wrote:
> OK, I think I understand the issue with the missing 2 new options in BIU.
>
> Brian, you must be solely using BIBM, not BIU.

No, I'm using BIU on a UEFI system.


>
> Whereas the last update for BIU was 8/12/19.

Last update was a few days ago. Feb 7

https://www.terabyteunlimited.com/upgra ... t-uefi.htm

Edit ... I think your page has an incorrect date

Brian K wrote:
> brucebne wrote:
>
>
> > I am aware of Work with Partitions copy processes being slower than IFL/IFD
> > imaging....but then you have to restore!
>
> Bruce, I'm not sure what you mean as you are not restoring in Disk Imaging. You are
> using Copy.

OMG!!!
OK, penny finally dropped.

Historically, I never recall a 'copy' button being in Image for Dos/Linux.
I have always always used IFD/IFL to create and restore images.

To make copies, I have always used "Work with Partitions", where you do the copy and paste operation all on the one Work with Partitions window (it's not a sequence of steps through multiple windows as IFD presents.

So now I get it.
Work with Partitions does not present the new copy options (change uuid, etc).

BUT
Image for Dos does.

And get this!!!!
In IFD, copying a 11/25GB Mint partition took 1m20s.
In Work with Partitions, the copy process is too slow to be useful (the progress bar had not even reached 1% after 1 minute).

So I'm exicted!!!
That means I can copy/clone partitions at lightening speed.

However I still have to do resizing and sliding in WOrk with Partitions....and this suffers from the 'slow' bug.

Sorry for all the confusion fellas.....but I'm a long time user of Boot It (pre BING), and just automatically presumed IFD didn't have a copy function.

So this brings us back to the issue of why IFD is lightening fast doing copies.....but Work with Partitions is the opposite (at least on my Dell Latitude)