#3655 Issue `open`: BLOCKCLONE: GPT disks refused on backup and silently mis-restored; $scheme and $path unset in two scripts¶

Labels: enhancement, fixed / solved / done, minor bug

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

ReaR version¶

2.9 (release 2.9 / 2025-02-13), and all four issues below are still present in master as of today.

Describe the ReaR bug in detail¶

BACKUP=BLOCKCLONE cannot back up or restore a GPT-partitioned disk, and two of its scripts use shell variables that are never assigned. Four distinct problems, in the order you meet them:

1. Saving the layout of a GPT disk aborts with a BugError.

usr/share/rear/layout/save/default/350_save_partitions.sh has the ("gpt") case commented out with #~ markers under # TODO: @gozora add gpt support, so a GPT disk falls through to:

BUG in /usr/share/rear/layout/save/default/350_save_partitions.sh line 45:
Unknown partition table on /dev/loop0

ReaR then prints "Please report it at https://github.com/rear/rear/issues", which is what this is.

2. $scheme and $path are used without being set.

usr/share/rear/backup/BLOCKCLONE/default/400_copy_disk_struct_files.sh:

local backup_path="$( url_path "$BACKUP_URL" )"
local opath="$( backup_path "$scheme" "$path" )"

Neither $scheme nor $path is ever assigned in this script. Its sibling 200_make_prefix_dir.sh (symlinked from backup/NETFS/default/), which computes the same path and creates the directory, sets all three:

local scheme="$( url_scheme "$BACKUP_URL" )"
local path="$( url_path "$BACKUP_URL" )"
local opath="$( backup_path "$scheme" "$path" )"

So the two resolve different directories and the backup fails:

cp: cannot create regular file '/var/tmp/rear.XXXXXXXX/outputfs/<hostname>': No such file or directory

Note also that line 1 declares a local variable named backup_path, which shadows the name of the backup_path function called on line 2.

3. The 446-byte bootstrap file is copied unconditionally.

The same script then copies $BLOCKCLONE_MBR_FILE, but that file is only written in the ("msdos") branch of 350_save_partitions.sh. On a GPT disk it does not exist and there is nothing meaningful to save there, since the boot loader is a file in the EFI System Partition. (Only reachable once problem 1 is fixed.)

4. The restore path does not handle GPT, and fails silently.

usr/share/rear/restore/BLOCKCLONE/default/390_create_partitions.sh repeats problem 2 verbatim (same two lines, same shadowing), and additionally carries the same # TODO: @gozora add gpt support with no GPT branch at all. It unconditionally runs:

sfdisk $BLOCKCLONE_SAVE_MBR_DEV < $opath/$BLOCKCLONE_PARTITIONS_CONF_FILE
dd if=$opath/$BLOCKCLONE_MBR_FILE of=$BLOCKCLONE_SAVE_MBR_DEV bs=446 count=1

For a GPT disk the saved file is an sgdisk -b binary backup. sfdisk cannot read it — but it does not fail either. It declines and exits 0:

# sfdisk /dev/loop1 < testvol_partitions.conf
>>> line 1: unsupported command

New situation:
Leaving.
# echo $?
0

StopIfError therefore does not fire. The restore reports that it created the partition layout, having created no partitions, and continues to look for the target partition on a still-blank disk. This is the one I would consider most serious, because it is silent.

Platform¶

Linux

OS version¶

Ubuntu 24.04.4 LTS, kernel 6.8.0-107-generic, x86_64. ReaR 2.9 installed from the project's own release (ubuntu-24-04.zip), since the distribution ships 2.7.

Backup¶

BLOCKCLONE

Storage layout¶

The reproducer below needs no Windows and no real disk — a 1 GB loop file with a GPT label, an ESP and an NTFS partition is enough:

NAME       SIZE FSTYPE LABEL
loop0        1G
├─loop0p1   64M vfat
└─loop0p2  959M ntfs   TESTVOL

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          133119   64.0 MiB    EF00  EFI system partition
   2          133120         2097118   959.0 MiB   0700  Basic data partition

The original case was an ordinary UEFI Windows Server 2022 guest: GPT, 128 GiB, ESP + MSR + NTFS.

What steps will reproduce the bug?¶

truncate -s 1G /var/tmp/gpttest.img
LOOP=$(losetup -fP --show /var/tmp/gpttest.img)
sgdisk -o -n 1:2048:+64M -t 1:ef00 -c 1:"EFI system partition" \
          -n 2:0:0       -t 2:0700 -c 2:"Basic data partition" $LOOP
partprobe $LOOP
mkfs.vfat -F32 ${LOOP}p1
mkntfs -Q -F -L TESTVOL ${LOOP}p2

cat > /etc/rear/gpttest.conf <<EOF
BACKUP=BLOCKCLONE
BACKUP_URL="file:///var/lib/rear/gpttest"
BACKUP_PROG_ARCHIVE="testvol"
BACKUP_PROG_SUFFIX=".ntfsclone.img"
BACKUP_PROG_COMPRESS_SUFFIX=""
BLOCKCLONE_PROG=ntfsclone
BLOCKCLONE_SOURCE_DEV="${LOOP}p2"
BLOCKCLONE_SAVE_MBR_DEV="${LOOP}"
BLOCKCLONE_MBR_FILE="testvol_boot_strap.img"
BLOCKCLONE_PARTITIONS_CONF_FILE="testvol_partitions.conf"
BLOCKCLONE_STRICT_PARTITIONING="yes"
BLOCKCLONE_ALLOW_MOUNTED="no"
EOF

rear -C gpttest mkbackuponly

Problem 1 aborts the run. Enabling the ("gpt") branch gets you to problem 2, and fixing that gets you to problem 3.

Workaround, if any¶

Enable the ("gpt") branch that is already in 350_save_partitions.sh, add the two missing assignments in both scripts, guard the bootstrap copy, and branch on the saved file in 390_create_partitions.sh — sfdisk -d writes a text dump whose first line is label:, sgdisk -b writes binary, so one grep distinguishes them without needing a new configuration variable.

With those changes the same reproducer completes:

Copying /var/lib/rear/layout/testvol_partitions.conf to /var/lib/rear/gpttest/v5c2-client
No boot-strap file to copy (GPT disk: the boot loader lives in the ESP)
Creating /var/lib/rear/gpttest/v5c2-client/testvol.ntfsclone.img from /dev/loop0p2 using ntfsclone

and sgdisk -l restores the layout with every partition GUID intact, which matters because a UEFI boot configuration can name the partition it boots from by GUID.

I have opened a pull request with these changes. The MBR path is untouched — on a DOS-labelled disk all three scripts run exactly the commands they ran before, and the GPT branches are additional.

Additional information¶

Found while testing BLOCKCLONE end to end on a real machine: a UEFI Windows Server 2022 guest was imaged from a Linux system and restored onto an empty 128 GiB disk, and it booted with the same MachineGuid, the same partition GUIDs, the same filesystem serials and a clean NTFS dirty bit. So the method works well once these four things are out of the way — ntfsclone put a 136,778,350,592-byte NTFS partition into 8,269,323,012 bytes (6.0% in use) and restored it in 92 seconds.

The documentation in doc/user-guide/12-BLOCKCLONE.adoc lists "GPT is not supported (work in progress)" and "UEFI is not supported (work in progress)" as known limitations, so problems 1 and 3 are arguably known gaps rather than surprises. Problems 2 and 4 look like plain bugs independent of that, and problem 4's silent exit 0 seemed worth reporting whatever is decided about GPT support.

gdha commented at 2026-11-06 10:01:¶

@abdelhaleemahmed PR #3656 has been merged. If you could retest with the master branch that would be nice.
If there are any remaining issues let us know.

[Export of Github issue for rear/rear.]

#3655 Issue open: BLOCKCLONE: GPT disks refused on backup and silently mis-restored; $scheme and $path unset in two scripts¶