#3477 Issue open: Disk mappings should be also applied to user configuration values¶

Labels: enhancement, bug

jsmeix opened issue at 2025-06-03 07:25:¶

Disk mappings should be also applied to user configuration values.

See
https://github.com/rear/rear/pull/3471#discussion_r2099970464

Is it the device node in the original system or in the rescue system?
I.e. is it subject to disk mapping or not?

and
https://github.com/rear/rear/pull/3471#discussion_r2100321542
(excerpt)

I thought that mappings are being applied
to configuration values at more places,
I am now surprised that there is only one.
I would actually argue for applying them more consistently to more values.
What is the value of being able to specify DISKS_TO_BE_WIPED, for example,
if you don't know what will the names will look like in the rescue system?
You tell ReaR during rescue image creation that it should wipe /dev/sda,
this gets embedded into the rescue image, but when the image boots,
the devices swap and ReaR now wipes what you thought was /dev/sdb instead,
as it has become /dev/sda now. Oops.

Because of such a possibly disastrous outcome this issue is also a bug
regardless that in general it is the user's task and responsibility
how to properly deal with migration issues where traditionally any
changed disk is a migration issue but nowadays it is questionable
if the unpredictable kernel device names are a "migration"
but at least unpredictable kernel device names cause issues
which behave as if there was an actual migration.

But there is a problem when disk mappings would get applied
same as elsewhere in ReaR also to user configuration files, see
https://github.com/rear/rear/pull/3471#discussion_r2100329911

> during "rear recover"
> his WRITE_PROTECTED_IDS in /etc/rear/rescue.conf may get
> again modified by the apply_layout_mappings() function
> in layout/prepare/default/320_apply_mappings.sh

And what if "rear recover" fails and the user reruns it?
Will rescue.conf get mapped AGAIN? :)### Describe the solution you'd like
So what was originally /dev/sda will get first mapped to /dev/sdb,
but in the second run will get mapped again to /dev/sda
if /dev/sda swaps with /dev/sdb ?

and
https://github.com/rear/rear/issues/3473#issuecomment-2898257250
(excerpt)

... the apply_layout_mappings() function
is "just run" on the original file (via 'sed -i')
and no backup of the original file is made
so after the apply_layout_mappings() function was run
one cannot tell by looking at e.g. /etc/rear/local.conf
if it is still the original one or a changed one
because there is only one /etc/rear/local.conf

---

[Export of Github issue for rear/rear.]