#3656 PR `merged`: BLOCKCLONE: support GPT disks, and fix two unset variables and a silent sfdisk failure¶

Labels: enhancement, minor bug, ready-to-merge?

abdelhaleemahmed opened issue at 2026-10-16 17:11:¶

Relax-and-Recover (ReaR) Pull Request Template¶

Pull Request Details:¶

Type: Bug Fix
Impact: Normal
Reference to related issue (URL): https://github.com/rear/rear/issues/3655
How was this pull request tested?

On Ubuntu 24.04.4 (kernel 6.8.0-107-generic), ReaR 2.9, BACKUP=BLOCKCLONE with BACKUP_URL="file://...", both partition table types, with the exact files in this branch:

GPT, 1 GB loop device, 64 MiB ESP + NTFS partition. Before the change, rear mkbackuponly aborts with BUG ... Unknown partition table on /dev/loop0. After it:
```
Copying /var/lib/rear/layout/testvol_partitions.conf to /var/lib/rear/gpttest/<host>
Creating /var/lib/rear/gpttest/<host>/testvol.ntfsclone.img from /dev/loop0p2 using ntfsclone
```
Restoring onto a second, blank 1 GB loop device reproduced the layout with both partition GUIDs intact, and a marker file inside the NTFS volume came back with the same md5 it went in with.

msdos, same shape, to confirm nothing regressed: the layout is still saved as an sfdisk -d text dump, mbrvol_boot_strap.img is still written and still copied, the restore still takes the sfdisk branch, and the round trip is byte-identical.

A real machine: a UEFI Windows Server 2022 guest (GPT, 128 GiB, ESP + MSR + NTFS) was imaged from a Linux system with these changes, its disk destroyed, and the GPT, the ESP and the NTFS volume restored onto an empty 128 GiB disk. It booted unaided with the same MachineGuid, the same three partition GUIDs, the same filesystem serials, byte-identical registry hives and a clean NTFS dirty bit. ntfsclone put the 136,778,350,592-byte partition into 8,269,323,012 bytes (6.0% in use) and restored it in 92 seconds.
Description of the changes in this pull request:

Three commits, one problem each. All of them are in the BLOCKCLONE paths; both msdos paths are unchanged and were re-tested as described above.

1. BLOCKCLONE: save the partition layout of GPT disks

layout/save/default/350_save_partitions.sh had the ("gpt") case present but commented out with #~, so a GPT disk fell through to the BugError. This enables it using the sgdisk -b call that was already written there, and removes the # TODO: @gozora add gpt support above it. No bootstrap code area is saved in that branch, deliberately: on a GPT disk the boot loader is a file in the EFI System Partition rather than code in the MBR gap.

2. BLOCKCLONE: set the URL scheme and path before computing the backup path

backup/BLOCKCLONE/default/400_copy_disk_struct_files.sh used $scheme and $path without ever assigning them, so backup_path() was called with two empty arguments and returned a different directory from the one 200_make_prefix_dir.sh had just created:
```
cp: cannot create regular file '/var/tmp/rear.XXXXXXXX/outputfs/<hostname>': No such file or directory
```
It now assigns both the way the sibling script that creates the directory does. This also drops the local backup_path=..., which shadowed the name of the backup_path function called on the next line. The same two lines appear in restore/BLOCKCLONE/default/390_create_partitions.sh and are fixed there in commit 3.

3. BLOCKCLONE: restore GPT layouts, and do not copy a bootstrap that was not saved

390_create_partitions.sh always restored the layout with sfdisk. For a GPT disk the saved file is an sgdisk binary backup, and feeding that to sfdisk does not fail — it declines and exits 0:
```
# sfdisk /dev/loop1 < testvol_partitions.conf
>>> line 1: unsupported command

New situation:
Leaving.
# echo $?
0
```
so StopIfError never fires and the restore continues against a disk that still has no partitions. The tool is now chosen from what was actually saved rather than from a new configuration variable, since 350_save_partitions.sh writes a text dump beginning label: for msdos and a binary backup for GPT. sgdisk -l restores the disk GUID and the partition GUIDs along with the sizes, which matters because a UEFI boot configuration can name the partition it boots from by GUID.

The same commit guards the BLOCKCLONE_MBR_FILE copy in 400_copy_disk_struct_files.sh, since that file only exists for msdos labelled disks.

Note on scope¶

doc/user-guide/12-BLOCKCLONE.adoc lists GPT and UEFI as unsupported work in progress, so parts 1 and 3 could reasonably be called a feature rather than a fix, and I am happy to split them out if you would prefer the variable fix on its own. Part 2, and the silent exit 0 in part 3, look like plain bugs independent of that decision.

I have not touched doc/user-guide/12-BLOCKCLONE.adoc, since what to say about GPT support there seemed better decided by the maintainers than by me. Restoring a UEFI system still needs one BLOCKCLONE configuration per partition — one for the ESP with BLOCKCLONE_PROG=dd and one for the NTFS volume — and that is worth documenting if these changes are taken.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KqVBvx74iXKfBoQ9F1RhxL

codacy-production commented at 2026-10-16 17:12:¶

Not up to standards ⛔¶

🔴 Issues 2 medium

>
> > **Alerts:** > ⚠ 2 issues (≤ 0 issues of at least minor severity) > > **Results:** > `2` new issues > > > > > > > > > > > > > > >

Category	Results
BestPractice	`2` medium

> > [View in > Codacy](https://app.codacy.com/gh/rear/rear/pull-requests/3656/issues) >

_{NEW Get contextual insights on your PRs based on Codacy's
metrics, along with PR and Jira context, without leaving GitHub. Enable
AI
reviewer}
_{TIP This summary will be updated as you push new changes.}

gdha commented at 2026-10-26 11:28:¶

@abdelhaleemahmed See comments https://app.codacy.com/gh/rear/rear/pull-requests/3656/issues

gdha commented at 2026-11-02 14:25:¶

@rear/contributors if there are no objections would like to merge this PR by then end of this week.

[Export of Github issue for rear/rear.]

#3656 PR merged: BLOCKCLONE: support GPT disks, and fix two unset variables and a silent sfdisk failure¶