#3505 Issue open: MIGRATION_MODE inconsistencies: disklayout.conf (et al.) versus local.conf (et al.)¶

Labels: enhancement

jsmeix opened issue at 2025-08-05 14:05:¶

What the current state is in general
(except possible exceptions for a few specific cases):

Current MIGRATION_MODE migrates disk device names
only in "layout" files like disklayout.conf
but not in user config files like local.conf
cf. https://github.com/rear/rear/issues/3473#issue-3080197047
cf. https://github.com/rear/rear/pull/3471#discussion_r2100254872

It happens during "rear recover" ...
by calling the apply_layout_mappings() function for the
autogenerated ReaR config file 'rescue.conf' in
layout/prepare/default/320_apply_mappings.sh
via

for file_to_migrate in "$LAYOUT_FILE" "$original_disk_space_usage_file" "$rescue_config_file" ; do
...
    ... apply_layout_mappings "$file_to_migrate" ...

This is the only place where apply_layout_mappings() is called
during preparation of the disk layout recreation in "rear recover".

BUT

We have also disk device names in user config variables.

Disk device names in user config variables are currently
not (more or less) automatically migrated in MIGRATION_MODE.

By searching for dev/sd in default.conf I found (excerpts)

# ... DISKS_TO_BE_WIPED="/dev/sda /dev/sdb" ...
...
# ... AUTORESIZE_PARTITIONS=( /dev/sda2 /dev/sdb3 ) ...
...
# ... AUTORESIZE_EXCLUDE_PARTITIONS=( boot swap efi /dev/sdb3 /dev/sdc4 ) ...
...
# For example for /dev/sda2 it would be MKFS_XFS_OPTIONS_SDA2 ...
...
# ... BACKUP_URL=usb:///dev/sdb1 ...
...
#  eg. Ultrium-1 or /dev/sda1
BEXTRACT_DEVICE=
...
# Source device for backup, e.g. /dev/sdb
BLOCKCLONE_SOURCE_DEV=""
...
# EXCLUDE_COMPONENTS+=( /dev/sdX fs:/mountpoint pv:/dev/sdXN ) ...
...
# ... GRUB2_INSTALL_DEVICES="/dev/sda /dev/sdb"
...
# EFIBOOTMGR_CREATE_ENTRIES=( '/dev/sda 1 EFI\boot\shim.efi shim_on_sda1' '/dev/sdb 2 EFI\boot\bootx64.efi bootx64\040on\040sdb2' )
...
# ... EFI_STUB_EFIBOOTMGR_ARGS="initrd=initramfs-linux.img root=/dev/sda2"

Those user config variables may contain disk device names
which likely need to be also migrated in MIGRATION_MODE
to keep disk device name information in user config files
CONSISTENT
with the (more or less) automatically migrated
disk device name information in "layout" files
(like disklayout.conf et al.)

Automatically migrating user config variable values
causes the generic problem
https://github.com/rear/rear/issues/3473

But "layout" files (in particular disklayout.conf)
are documented in our "Layout configuration" user guide
to be also user config files when needed, see
https://github.com/rear/rear/blob/rear-2.9/doc/user-guide/06-layout-configuration.adoc
in the "Restore to different hardware" section
in the "The Ad-Hoc Way" sub-section
https://github.com/rear/rear/blob/rear-2.9/doc/user-guide/06-layout-configuration.adoc#the-ad-hoc-way
reads (excerpts)

RESCUE firefly:~ # rear recover
...
2) Edit disk layout (disklayout.conf) ...
...
checking the disklayout file
...
just put some nice comments on them and their logical volumes.
The resulting layout file looks like this:
...

So it is a (more or less indirectly) documented use case
that a user may modify his disklayout.conf in the ReaR recovery system
before running "rear recover" to what he needs.

I think our current MIGRATION_MODE behaviour is prepared for this case
because during "rear recover" the user must make a decision
whether or no he wants to enter ReaR's MIGRATION_MODE
where disk device names get (more or less) automatically migrated.

When the user had properly adapted all ReaR config files
(i.e. disklayout.conf et al. and local.conf et al.)
to what he needs for "rear recover"
then he can deny ReaR's MIGRATION_MODE.

The question is how many users can in practice
properly adapt all ReaR config files
for what is needed for "rear recover".

pcahyna commented at 2025-08-05 18:29:¶

# EXCLUDE_COMPONENTS+=( /dev/sdX fs:/mountpoint pv:/dev/sdXN ) ...

I believe that EXCLUDE_COMPONENTS is fine - I don't think it is used during recreation. EXCLUDE_RECREATE is problematic, if you can put disk names there (and I believe you can). See the discussion of the differences in #3458 and in https://github.com/rear/rear/issues/3477#issuecomment-3024403418 (which also shows that EXCLUDE_RECREATE is problematic in a a similar way).

---

[Export of Github issue for rear/rear.]