#3632 PR open: Skip unsupported partition tables during layout save by default (SKIP_UNSUPPORTED_PARTITION_TABLES)

Labels: enhancement

parasjain37 opened issue at 2026-09-01 07:44:

Add SKIP_UNSUPPORTED_PARTITION_TABLES (default yes) to skip sun/unknown/loop disks before writing disk/part lines. Extends #3455 EXCLUDE_COMPONENTS handling with fleet-scale auto-skip. Adds 315 script and 230 filesystem skip. Related: #3455

Relax-and-Recover (ReaR) Pull Request Template

Please fill in the following items before submitting a new pull request:

Pull Request Details:

Test 1 — default auto-skip (SKIP_UNSUPPORTED_PARTITION_TABLES=y) :
Ran rear mkrescue -v , succeeds without including sun disk in disklayout.conf

Test 2 — strict mode (SKIP_UNSUPPORTED_PARTITION_TABLES=n):
mkrescue fails with clear Error on unsupported partition table

Test 3 — regression for #3455 (EXCLUDE_COMPONENTS):
SKIP_UNSUPPORTED_PARTITION_TABLES=n + EXCLUDE_COMPONENTS+=( /dev/vdX ) on unsupported disk
Then rear mkrescue -v , Disk in EXCLUDE_COMPONENTS is skipped, honoring exclusion added even if unsupported skip is set to No.

  • Description of the changes in this pull request:
    Since ReaR 2.7+ (#2803), layout/save/GNU/Linux/200_partition_layout.sh errors out when parted reports an unsupported partition table type (e.g. sun, unknown, loop, bsd). This causes mkrescue to abort on systems with legacy non-OS data disks that ReaR cannot recreate anyway.

#3455 added a soft-fail path in extract_partitions() when the disk is explicitly listed in EXCLUDE_COMPONENTS. That helps exceptional cases but does not scale for large fleets where per-host EXCLUDE_COMPONENTS configuration is impractical. Furthermore, EXCLUDE_COMPONENTS is processed in script 310_include_exclude.sh, which runs after 200_partition_layout.sh, so unsupported disks without sysfs partition entries can still abort layout save before exclude logic runs.

This pull request adds SKIP_UNSUPPORTED_PARTITION_TABLES=y (default) to skip unsupported disks during layout save:

usr/share/rear/conf/default.conf — new parameter SKIP_UNSUPPORTED_PARTITION_TABLES=y; set to n for strict Error behavior.

usr/share/rear/lib/layout-functions.sh — new helper is_partition_table_type() for supported types (msdos, gpt, gpt_sync_mbr, dasd).

usr/share/rear/layout/save/GNU/Linux/200_partition_layout.sh:

Initialize $VAR_DIR/layout/skipped_unsupported_disks
In the disk loop: detect disktype via parted (with 2>/dev/null); treat empty parse result as unknown; skip unsupported disks before writing active disk lines when auto-skip is enabled
In extract_partitions(): keep #3455 EXCLUDE_COMPONENTS soft-fail; add auto-skip via SKIP_UNSUPPORTED_PARTITION_TABLES
usr/share/rear/layout/save/GNU/Linux/230_filesystem_layout.sh — skip saving filesystem layout for devices on skipped disks.

usr/share/rear/layout/save/default/315_skip_unsupported_partition_tables.sh (new) — mark skipped disks, their filesystems, and swap as done so 330_remove_exclusions.sh comments them out in disklayout.conf.

Skipped disks are recorded as commented # Skipped disk ... lines in disklayout.conf for auditability. Supported OS disks (gpt/msdos/dasd) are unchanged.

codacy-production commented at 2026-09-01 07:45:

Not up to standards ⛔

🔴 Issues 7 medium >
> > **Alerts:** > ⚠ 7 issues (≤ 0 issues of at least minor severity) > > **Results:** > `7` new issues > > > > > > > > > > > > > > > > > > >
CategoryResults
BestPractice1 medium
ErrorProne6 medium
> > [View in > Codacy](https://app.codacy.com/gh/rear/rear/pull-requests/3632/issues) >

NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.

jsmeix commented at 2026-09-01 08:41:

@parasjain37
thank you for your valuable enhancement.
I think it helps to make excluding unwanted stuff
easier for the user.
I could not yet look at the details
(I am currently busy with CVEs elsewhere).

I think this is a too severe backward incompatible change
in ReaR behaviour to skip unsupported partition table types
by default.
Assume an experienced ReaR user got a new system
where also an unsupported partition table type exists.
An experienced ReaR user knows that ReaR errors out
in such cases.

Furthermore it is ReaR's default task to
recreate a system "as it was before".
So ReaR must not automatically skip things
when ReaR does not support something but instead
ReaR must error out when it cannot do its default task.

Therefore I think in default.conf there should be

SKIP_UNSUPPORTED_PARTITION_TABLES=''

which should default to "no".

The crucial point is that it must be an explicit
user request via a user specified setting like

SKIP_UNSUPPORTED_PARTITION_TABLES="yes"

where the user commands ReaR to skip disks
with unsupported partition table types.

pcahyna commented at 2026-09-04 12:20:

@jsmeix I completely agree.

Furthermore it is ReaR's default task to
recreate a system "as it was before".
So ReaR must not automatically skip things
when ReaR does not support something but instead
ReaR must error out when it cannot do its default task.

Indeed. ReaR should fail early if it detects something that it will not be able to recreate. Silently excluding stuff that it is not able to handle and thus potentially losing data is IMO a very bad idea. The administrator has to decide what to do in this case.

Before making a change to the default, I would like to review what is actually the desired behavior here. According to private conversations, the original problem is that PR #2803 (more precisely, commit 825478ee27f916553938afaf5164fec22cb32732) introduced a regression. It fixed the issue #2801 where in the presence of unsupported partition tables a broken layout got generated. But it fixed it by making ReaR error out early. The problem is, this is a regression for users where those disks got excluded using some *EXCLUDE_* / *INCLUDE_* variable - the broken entries in the layout got excluded afterwards, so this was not an issue unless the disk was being used or AUTOEXCLUDE_DISKS=n was specified in the configuration.

I would therefore propose to fix the problem in a different way. We should change ReaR so that the unsupported partition table causes an error only if the partition are actually used. This would lead to the same error as now for users that have configurations that can not be restored properly, but ReaR would work as before out of the box for users who do not have the problematic disks mounted or exclude them via any of the *EXCLUDE_* / *INCLUDE_* parameters. We would not add any new configuration option. (I feel that there are way too many *EXCLUDE_* / *INCLUDE_* parameters already, and as the person who has sometimes write docs about what they do, how they are used and how they interact I would very much prefer to avoid adding any new ones unless really needed.)

pcahyna commented at 2026-09-10 12:57:

I propose to close this PR and I will implement the approach outlined above, unless you @jsmeix really want the new parameter (I prefer not introducing new parameters unless really needed).

jsmeix commented at 2026-09-11 07:29:

@pcahyna
I agree with you.

I changed this pull request to a draft because I would like
to keep its proposed changes available at least for now.
I don't know what happens when I close an unmerged pull request.
Would that delete its proposed changes?
Later after your implementation was merged, we could
delete this pull request with its proposed changes.

In general regarding
"there are way too many EXCLUDE_ / INCLUDE_ parameters"
Yes, of course.
That current mess has grown over a long time
by various contributions for various specific use cases
without a "master plan" - but without such individual
contributions there would be basically no ReaR at all.

Feel free - if you like and/or if it helps you with your
implementation - to mercilessly clean up the current mess
in particular because backward incompatible changes
can be done for the next ReaR major version 3.0.

pcahyna commented at 2026-09-11 09:26:

Feel free - if you like and/or if it helps you with your
implementation - to mercilessly clean up the current mess
in particular because backward incompatible changes
can be done for the next ReaR major version 3.0.

Would be good, but currently my ambition is limited to making Paras' case work again by using the currently available parameters (without introducing a new one). Perhaps I will get to reducing the set of parameters, but no promises. (Me too, I am currently busy with CVEs elsewhere.)

jsmeix commented at 2026-09-14 12:46:

Sigh!

Above I made the bold statement that

... it is ReaR's default task to
recreate a system "as it was before".
So ReaR must not automatically skip things
when ReaR does not support something but instead
ReaR must error out when it cannot do its default task.

Over the weekend it came to my mind to check
how ReaR behaves when the unsupported ZFS is used.

So I created a ZFS pool
on a test VM (with SLES15) on /dev/vdb
where I have now

# lsblk -ipo NAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINTS

NAME        TRAN   TYPE FSTYPE      SIZE MOUNTPOINTS
/dev/sr0    sata   rom  iso9660    16.1G 
/dev/vda    virtio disk              15G 
|-/dev/vda1 virtio part               8M 
|-/dev/vda2 virtio part btrfs        13G /var
|                                        /usr/local
|                                        /tmp
|                                        /root
|                                        /srv
|                                        /home
|                                        /opt
|                                        /boot/grub2/x86_64-efi
|                                        /boot/grub2/i386-pc
|                                        /.snapshots
|                                        /
`-/dev/vda3 virtio part swap          2G [SWAP]
/dev/vdb    virtio disk               1G 
|-/dev/vdb1 virtio part zfs_member 1014M 
`-/dev/vdb9 virtio part               8M 
/dev/vdc    virtio disk               2G 
`-/dev/vdc1 virtio part ext4       1020M /other

# zpool status
  pool: myzfspool
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        myzfspool   ONLINE       0     0     0
          vdb       ONLINE       0     0     0

so the ZFS pool is not shown as mounted by lsblk
regardless that it is in use and mount shows it

# mount | grep zfs

myzfspool on /myzfspool type zfs (rw,relatime,xattr,noacl,casesensitive)

In /myzfspool I did a git clone of ReaR master code
and used this etc/rear/local.conf

OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL=file:///other/
BACKUP_ONLY_INCLUDE="yes"
BACKUP_PROG_INCLUDE=( /myzfspool )
{ SSH_ROOT_PASSWORD='rear' ; } 2>>/dev/$SECRET_OUTPUT_DEV
USE_DHCLIENT="yes"
MODULES=( 'loaded_modules' )
PROGRESS_MODE="plain"
PROGRESS_WAIT_SECONDS="5"

for the following rear mkrescue test
(excerpts):

localhost:/myzfspool/rear.github.master # usr/sbin/rear -D mkrescue

Relax-and-Recover 2.9 / 2025-01-31
Running rear mkrescue (PID 6546 date 2026-09-14 13:50:49)
Command line options: usr/sbin/rear -D mkrescue
Using log file: /myzfspool/rear.github.master/var/log/rear/rear-localhost.log
Using build area: /var/tmp/rear.2JzBoRSvwWDy4fC
...
Adding backup directory mountpoint 'fs:/other' to EXCLUDE_RECREATE
...
Running 'layout/save' stage ======================
Creating disk layout
SLES12-SP1 (and later) btrfs subvolumes setup needed for /dev/vda2 (default subvolume path contains '@/.snapshots/')
Added  /dev/vda2 to BTRFS_SUBVOLUME_SLES_SETUP in /var/tmp/rear.2JzBoRSvwWDy4fC/rootfs/etc/rear/rescue.conf
Excluding component fs:/other in EXCLUDE_RECREATE
Marking component 'fs:/other' as done in /myzfspool/rear.github.master/var/lib/rear/layout/disktodo.conf
Automatically excluding disk /dev/vdb (not used by any mounted filesystem)
Marking component '/dev/vdb' as done in /myzfspool/rear.github.master/var/lib/rear/layout/disktodo.conf
Dependent component /dev/vdb1 is a child of component /dev/vdb
Marking component '/dev/vdb1' as done in /myzfspool/rear.github.master/var/lib/rear/layout/disktodo.conf
Dependent component /dev/vdb9 is a child of component /dev/vdb
Marking component '/dev/vdb9' as done in /myzfspool/rear.github.master/var/lib/rear/layout/disktodo.conf
Automatically excluding disk /dev/vdc (not used by any mounted filesystem)
Marking component '/dev/vdc' as done in /myzfspool/rear.github.master/var/lib/rear/layout/disktodo.conf
Dependent component /dev/vdc1 is a child of component /dev/vdc
Marking component '/dev/vdc1' as done in /myzfspool/rear.github.master/var/lib/rear/layout/disktodo.conf
Dependent component fs:/other is a child of component /dev/vdc
Component 'fs:/other' is marked as 'done fs:/other' in /myzfspool/rear.github.master/var/lib/rear/layout/disktodo.conf
Disabling excluded components in /myzfspool/rear.github.master/var/lib/rear/layout/disklayout.conf
Disabling component 'disk /dev/vdb' in /myzfspool/rear.github.master/var/lib/rear/layout/disklayout.conf
Disabling component 'part /dev/vdb' in /myzfspool/rear.github.master/var/lib/rear/layout/disklayout.conf
Component 'part /dev/vdb' is disabled in /myzfspool/rear.github.master/var/lib/rear/layout/disklayout.conf
Disabling component 'disk /dev/vdc' in /myzfspool/rear.github.master/var/lib/rear/layout/disklayout.conf
Disabling component 'part /dev/vdc' in /myzfspool/rear.github.master/var/lib/rear/layout/disklayout.conf
Disabling component 'fs ... /other' in /myzfspool/rear.github.master/var/lib/rear/layout/disklayout.conf
Using sysconfig bootloader 'grub2' for 'rear recover'
Skip saving storage layout as 'barrel' devicegraph (no 'barrel' command)
Verifying that the entries in /myzfspool/rear.github.master/var/lib/rear/layout/disklayout.conf are correct
Created disk layout (check the results in /myzfspool/rear.github.master/var/lib/rear/layout/disklayout.conf)
Running 'rescue' stage ======================
...
Exiting rear mkrescue (PID 6546) and its descendant processes ...
Running exit tasks
To remove the build area you may use (with caution): rm -Rf --one-file-system /var/tmp/rear.2JzBoRSvwWDy4fC

So ReaR does not error out when the unsupported ZFS is used.

The reason is that ReaR cannot detect that ZFS is used
because in layout/save/GNU/Linux/230_filesystem_layout.sh
we do (excerpts)

supported_filesystems="ext2,ext3,ext4,vfat,xfs,reiserfs,btrfs"
...
read_filesystems_command="mount -t $supported_filesystems | cut -d ' ' -f 1,3,5,6"
# If the findmnt command is available use it instead of the traditional mount command
...
findmnt_command="$( type -P findmnt )"
if test -x "$findmnt_command" ; then
    ...
    read_filesystems_command="$findmnt_command -mnrv -o SOURCE,TARGET,FSTYPE,OPTIONS -t $supported_filesystems"

so ReaR calls

mount -t ext2,ext3,ext4,vfat,xfs,reiserfs,btrfs | cut -d ' ' -f 1,3,5,6

or (when the findmnt command is available)

findmnt -mnrv -o SOURCE,TARGET,FSTYPE,OPTIONS -t ext2,ext3,ext4,vfat,xfs,reiserfs,btrfs

and all the rest works based on that output
which must not contain unsupported filesystems
because ReaR cannot process unsupported filesystems
so things that depend on unsupported filesystems
must get automatically excluded (this part is right)
BUT
there is no test for unsupported filesystems
and no code to deal with unsupported filesystems
(so this part is missing).

So for unsupported filesystems ReaR is currently
"Silently excluding stuff that it is not able to handle"
:-(

Only in debug mode it tells what got automatically excluded

Automatically excluding disk /dev/vdb (not used by any mounted filesystem)

But currently ReaR cannot tell why (because there is
no code to deal with unsupported filesystems)
and the current message looks somewhat misleading
because the ZFS pool is not normally mounted
but nevertheless it is shown by mount.

As a quick band-aid I added in 230_filesystem_layout.sh

 # Comma separated list of filesystems that is used for "mount/findmnt -t <list,of,filesystems>" below:
 supported_filesystems="ext2,ext3,ext4,vfat,xfs,reiserfs,btrfs"
+# At least tell what happens for unsupported filesystems,
+# cf. https://github.com/rear/rear/pull/3632#issuecomment-5664168360
+LogPrint "Supported filesystems: $supported_filesystems (what belongs to unsupported filesystems gets automatically excluded)"

see
https://github.com/rear/rear/pull/3637

So now at least in verbose mode
the output looks a bit better (excerpt):

localhost:/myzfspool/rear.github.master # usr/sbin/rear -v mkrescue
...
Supported filesystems: ext2,ext3,ext4,vfat,xfs,reiserfs,btrfs (what belongs to unsupported filesystems gets automatically excluded)
SLES12-SP1 (and later) btrfs subvolumes setup needed for /dev/vda2 (default subvolume path contains '@/.snapshots/')
Added  /dev/vda2 to BTRFS_SUBVOLUME_SLES_SETUP in /var/tmp/rear.PlnaLqZhNWp5xUs/rootfs/etc/rear/rescue.conf
Excluding component fs:/other in EXCLUDE_RECREATE
Disabling component 'disk /dev/vdb' in /myzfspool/rear.github.master/var/lib/rear/layout/disklayout.conf
Disabling component 'part /dev/vdb' in /myzfspool/rear.github.master/var/lib/rear/layout/disklayout.conf
Disabling component 'disk /dev/vdc' in /myzfspool/rear.github.master/var/lib/rear/layout/disklayout.conf
Disabling component 'part /dev/vdc' in /myzfspool/rear.github.master/var/lib/rear/layout/disklayout.conf
Disabling component 'fs ... /other' in /myzfspool/rear.github.master/var/lib/rear/layout/disklayout.conf
...

In non-verbose mode there is no outout

localhost:/myzfspool/rear.github.master # usr/sbin/rear mkrescue
localhost:/myzfspool/rear.github.master # echo $?
0

which is right because currently there cannot be an Error()
because there is no code to deal with unsupported filesystems.

pcahyna commented at 2026-09-14 13:12:

@jsmeix indeed. I realized exactly the same thing when working on the same issue. ReaR automatically and silently excludes filesystems that are not in the (very short) supported filesystem list. Veritas' vxfs is one case, as is ZFS. But let's not make things worse by excluding unsupported partition tables as well.

pcahyna commented at 2026-09-14 13:18:

(...) which is right because currently there cannot be an Error()
because there is no code to deal with unsupported filesystems.

I would suggest to make it an Error in a future major release (3.0 or 4.0) to force the users to alter their configuration to exclude the unknown filesystems somehow, just like they used to be able (and should be able again) to skip unsupported partition tables by not including anything on them.

[Export of Github issue for rear/rear.]