Hot to clone a gpt drive?

[starshipeleven]

from here https://www.phoronix.com/forums/foru...95#post1072695

Because you know better than the Internet, post clear and 100% working instructions how to clone an efi disk to a new one with dd

Same disk size = same as copying a MBR drive.

Different disk size (partitions can actually fit) use dd to copy it over, then run a GPT-aware disk partitioning tool to fix the secondary GPT partition table (as now you either have it in the wrong place, or is missing. fdisk or gdisk or parted or whatever. Just start them up and then have them "write the changes to disk" will fix the secondary GPT partition table.
I use

gdisk /dev/sdX

Then I see that it complains on startup about missing or misplaced secondary GPT partition table, I proceed with "w" and confirm with "y"

As an aside, I use pv instead of dd as it can actually show progress and MB/s, while not requiring me to specify things like "block size" which make no sense at all outside of the ancient tape media that dd was originally designed for.

and make it boot with grub.

I guess this is your actual issue. The average GRUB install for Debian does not place GRUB in a standard location for the UEFI firmware (see here https://wiki.debian.org/UEFI ) and relies on setting up the UEFI to boot from their custom location, and the UEFI links this configuration to the drive's ID.
Cloning the drive will break this as the new drive will have a different ID.

Ubuntu, Fedora, OpenSUSE and others install their GRUB in the standard location for "removable media" so even if you clone a drive it will still boot from it automatically.

Debian does not do it by default the last time I checked.

While I never did it myself as all my remaining Debian systems are not even x86 devices at all, according to the Debian Wiki https://wiki.debian.org/GrubEFIReins...ack_bootloader
you have to enable this functionality BEFORE you clone the drive by writing

echo "grub-efi-amd64 grub2/force_efi_extra_removable boolean true" | sudo debconf-set-selections

and then reinstall grub so it is installed in the right place.

update-grub ; grub-install /dev/sdX

Or you can also do it manually, you need to mount the EFI partition (by default this partition is mounted inside /boot/efi if you installed in UEFI mode), then copy /EFI/debian/grubx64.efi into /EFI/boot/bootx64.efi
Assuming standard Debian installed as UEFI, you need to do this BEFORE you clone the drive with dd:

sudo cp -Rf --parents /boot/efi/EFI/debian/* /boot/efi/EFI/boot/

Then after you booted successfully from this drive you have to reinstall grub with grub-install /dev/sdX so it sets the UEFI configuration to boot from this drive.

I personally ditched GRUB on my x86 systems because it's prehistoric clunky trash and replaced it with rEFInd bootloader (with a beautiful theme) placed in the standard "removable media" location in the EFI partition.
rEFInd is 0 mainteneance and does not need to be reconfigured and reinstalled every time you update your kernel. Also this setup will boot automatically in UEFI mode as it does not rely on setting the UEFI to boot from a specific file in a specific drive.

[starshipeleven]

Your essay proves that cloning uefi disks are from hell. Much simpler is to use mbr.

My essay proves that Debian on UEFI is from hell. Much simpler is to use OpenSUSE on UEFI.

[towo2099]

He is a MSC software developer, simple activities are below his level.

[towo2099]

If you have no clue, STFU.

[starshipeleven]

OpenSuse has no resources to make dependencies work in tumbleweed. Install it with custom settings to prove that. Debian has most software packages, f.ex zynaddsubfx-dssi is missing from many distributions.
. Debian distributions are Steam games compatible. No OIbaf ppa and Padoka ppa that has latest Mesa git and updates every day.

Does not change one bit what I said. Default config of GRUB in Debian UEFI is shit and requires you to go and change configuration of stuff if you want to be able to clone your fucking drives in a UEFI system. This is fucking bad.

But of course you are debianxfce. For you it's not a Debian issue, not even a GRUB issue.

For you this Debian-specific GRUB configuration default becomes a GPT/UEFI issue, and NO ONE has ever found a way to clone a drive on UEFI/GPT so people should use MBR drives and boot in legacy mode.

[starshipeleven]

Debian has most software packages, f.ex zynaddsubfx-dssi is missing from many distributions.

Available on Opensuse https://pkgs.org/download/zynaddsubfx-dssi

Debian distributions are Steam games compatible.

So is OpenSUSE

No OIbaf ppa and Padoka ppa that has latest Mesa git and updates every day.

There are OpenSUSE OBS repos for latest kernel and mesa-git for OpenSUSE

[starshipeleven]

No, see Steam games system requirements.

https://store.steampowered.com/app/203160/Tomb_Raider/

"
OS:Ubuntu 14.04 or Steam OS 2.0 (64 bit)

I don't see Debian there. You also said "steam games compatible", and OpenSUSE is compatible.
"

Oibaf ppa is the only repo that it is updated every day.

Wrong.

[Kano]

For UEFI Linux only installs I just fake Windows - a bootloader with is always found even when connected to a different system. Basically cloning with dd/buffer should work with NVME too (if same or bigger size) but I never saw /dev/sdX for such a drive. The Debian/Ubuntu kernels always used /dev/nvme*. There are m.2 drives with SATA protocol only too, those show up as /dev/sdX of course.

[Slithery]

The procedure for cloning a UEFI installation is identical to the procedure for cloning a BIOS installation, with the one caveat that you may need to recreate the NVRAM entry as well. This is only needed if you haven't configured your preferred EFI executable in the default fallback location.

Obviously cloning to a device that uses a different driver also means that anything in your configs/fstab (if you still use one) that refers to kernel name descriptors will need to be changed, but using them has been bad practice for years now anyway.