#3504 Issue open: BTRFS_SUBVOLUME_SLES_SETUP+= rescue.conf hack not working (or: disk layout file should contain more infos)¶
Labels: bug
schlomo opened issue at 2025-08-04 15:36:¶
ReaR version¶
master
Describe the ReaR bug in detail¶
those two don't match so that this logic probably never works right now
schlomo commented at 2025-08-04 15:39:¶
Other question about this problem: Why can't we transport the special SLES info via the disk layout file? Instead of "breaking out" of the disk layout file and storing this information somewhere else in the rescue system?
I think there is a great value in ensuring that disk layout is "self contained" and "complete" and that that kind of information is not spread elsewhere.
Maybe "disk layout" is somewhat misnamed and should be something like "system configuration" and it should contain more infos than just the actual disk layout.
If the disk layout file carries more infos then in migration mode (which is now the default) those other infos would be seamlessly migrated as well. Examples are boot loader configuration and other stuff which is related to disks
schlomo commented at 2025-08-04 15:41:¶
#3473 would probably be resolved by this issue
jsmeix commented at 2025-08-04 15:57:¶
@schlomo
please keep this issue to what it originally is about
(which I can fix).
I cannot "by the way" redesign the whole (grown over long time)
way how ReaR does all its disk related things.
Please create separated issues for global issues.
https://github.com/rear/rear/issues/3473
will not be resolved by this issue here
which is about fixing a BTRFS_SUBVOLUME_SLES_SETUP+=
versus BTRFS_SUBVOLUME_SLES_SETUP= bug.
schlomo commented at 2025-08-04 16:04:¶
@jsmeix yes, please adjust and fix as you see fit
jsmeix commented at 2025-08-04 16:16:¶
Found the cause of this bug:
eval $( grep '^BTRFS_SUBVOLUME_SLES_SETUP=' "$rescue_config_file" )
was introduced by me on Jul 19 2019 via
https://github.com/rear/rear/commit/b2be35bbb3a3764abb1fc5897ab55df4459fce2a
Later on Apr 17 2020
BTRFS_SUBVOLUME_SLES_SETUP=( ${BTRFS_SUBVOLUME_SLES_SETUP[@]} $btrfs_subvolume_sles_setup_devices )
became improved by me (simpler and more fail-safe syntax) to
BTRFS_SUBVOLUME_SLES_SETUP+=( $btrfs_subvolume_sles_setup_devices )
via
https://github.com/rear/rear/commit/d4f8d30cd06c1f9da8a041aa11979024318cd53b
pcahyna commented at 2025-08-04 16:36:¶
Found the cause of this bug:
eval $( grep '^BTRFS_SUBVOLUME_SLES_SETUP=' "$rescue_config_file" )was introduced by me on Jul 19 2019 via b2be35b
Later on Apr 17 2020
BTRFS_SUBVOLUME_SLES_SETUP=( ${BTRFS_SUBVOLUME_SLES_SETUP[@]} $btrfs_subvolume_sles_setup_devices )
IMO, this first version was already wrong, because you should not append in rescue.conf if you are going to re-read it. The values will appear in the array twice (first the unmapped values and then the mapped values).
jsmeix commented at 2025-08-05 13:16:¶
@pcahyna
thank you!
I think you are right.
I will have a closer look how the BTRFS_SUBVOLUME_SLES_SETUP stuff
is meant to work (I have to reverse-engineer my own code because
SUSE btrfs stuff is too weird to keep it in my precious brain ;-)
jsmeix commented at 2025-08-05 14:07:¶
Regarding
https://github.com/rear/rear/issues/3504#issuecomment-3151279304
see
https://github.com/rear/rear/issues/3505
and
https://github.com/rear/rear/issues/3477
[Export of Github issue for rear/rear.]