#3561 Issue closed: Add PARTUUID recovery

Labels: enhancement, fixed / solved / done

svlv opened issue at 2026-02-05 12:57:

Platform

Linux x64

Currently, during Bare-Metal Recovery partition GUIDs (for GPT partition tables) are not preserved.
For example, if the partition GUIDs before recovery are as follows:

lsblk -o NAME,PARTUUID
NAME    PARTUUID
sda
├─sda1  7a5a3aff-efaf-4ead-97e8-73ce273e5901
├─sda14 fd1d84ec-20c4-4771-ab52-e1006cf4b840
├─sda15 1eecae2b-bc04-44f7-9f93-022d511dea63
└─sda16 2e03485c-de6f-4c80-9730-14ad86d1abd9

then, after a successful recovery, the partition GUIDs have different values:

NAME    PARTUUID
sda
├─sda1  0b5618f0-155e-4f46-91e4-8bec27a82442
├─sda14 9b1dcbe6-ecc2-4be?-9f70-7b4cb745ccf1
├─sda15 a0f5b?42-9150-4804-8d0d-96d31c1a16fe
└─sda16 8b4cf737-7bce-4868-8432-72e1138610dc

On setups where partition GUIDs are not used, this is harmless. However, on systems where PARTUUIDs are used in /etc/fstab or grub.cfg, it may result in a non-bootable machine after restoration.

In the case of grub.cfg, the PARTUUID values can also be hard-coded, e.g., in one of the config files under /etc/default/grub.d/, so even running grub-mkconfig doesn't update PARTUUID during recovery.

Describe the solution you'd like

I propose backing up and restoring PARTUUID values for GPT partition tables in the same way that filesystem UUIDs are already handled.

Describe alternatives you've considered

I considered updating config files that use hard-coded PARTUUID values during recovery process, however, these values technically can appear in unpredictable locations. A general solution - recovery PARTUUIDs - would likely be more valuable and robust than fixing symptoms.

Additional context

It is not a new issue, it was previously discussed in https://github.com/rear/rear/issues/2548

svlv commented at 2026-02-05 13:05:

Proposed patch: https://github.com/rear/rear/pull/3562

jsmeix commented at 2026-02-05 15:05:

@svlv
thank you for your enhancement of ReaR!

Could you please post here some examples how exactly
PARTUUID values are used in /etc/fstab or grub.cfg ?

I ask because I am wondering if ReaR could automatically
determine if PARTUUID values must be recreated, see
https://github.com/rear/rear/pull/3562#discussion_r2769615310

svlv commented at 2026-02-05 16:01:

@jsmeix
Thank you for the feedback.

Sure, I'll post examples for both /etc/fstab and grub.cfg tomorrow.
Yes, it's a good point. I'll probably be able to propose automatic detection for these cases as well

svlv commented at 2026-02-06 14:14:

The example from grub.cfg:

menuentry 'My entry' {
    linux   /vmlinuz-6.14.0 root=PARTUUID=cb545c90-d37e-4d44-a35e-26175e27da3e ro console=tty1 console=ttyS0
    initrd  /initrd.img-6.14.0
}

The example for /etc/fstab:
PARTUUID=ae81658e-e32a-4dea-b274-e706812b0e5a /boot xfs defaults 0 0

jsmeix commented at 2026-02-06 14:40:

@svlv

your examples show that simple grep "PARTUUID="
should be sufficient to automatically determine
if it seems PARTUUID values must be recreated.

I think when this test has a false positive result
i.e. it indicates PARTUUID values must be recreated
but actually different PARTUUID values won't matter
then REQUIRED_PROGS+=( sgdisk ) normally won't hurt
except on systems where no 'sgdisk' is installed
and that test has a false positive result.

But it won't hurt as much when "rear mkrescue/mkackup"
exits with an error about missing REQUIRED_PROGS
as if "rear recover" fails - or more precisely
when "rear recover" falsely succeeds but then
booting of the recreated system fails.

So I think your implementation is perfectly fine
i.e. I think it works sufficiently well in practice
with reasonable implementation efforts.

[Export of Github issue for rear/rear.]