#2958 Issue `open`: ReaR fails while verifying the disklayout when a disk has a 0 size¶

Labels: enhancement

rmetrich opened issue at 2023-03-20 15:37:¶

ReaR version ("/usr/sbin/rear -V"):

latest upstream 2.7 at latest commit 7ce864210fc7a7c95a131ea8c933f543b6e3b9cb

OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):

N/A

ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):

AUTOEXCLUDE_DISKS=n

Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR):

N/A

System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):

N/A

Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):

N/A

Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):

USB Card Reader with no card inserted

Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):

N/A

Description of the issue (ideally so that others can reproduce it):

When plugging in a USB multi-card reader (SD / MicroSD) which has no card insert, the device (/dev/sda) has a 0 size.
This leads to layout verification to fail:

No partition label type for 'disk /dev/sda' (may cause 'rear recover' failure)
/dev/sda size 0 is not a positive integer
ERROR: 
====================
BUG in /root/rear/usr/share/rear/layout/save/default/950_verify_disklayout_file.sh line 254:
'Entries in /root/rear/var/lib/rear/layout/disklayout.conf are broken ('rear recover' would fail)'

This happens when AUTOEXCLUDE_DISKS=n (which is not the default).

Workaround, if any:

None found yet, except excluding the "disk" manually, which isn't always possible due to non-persistent device naming.

Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):

The root cause is the code snippet in /usr/share/rear/layout/save/GNU/Linux/200_partition_layout.sh, which doesn't skip disks with $devsize == 0 :

415                 devsize=$(get_disk_size ${disk#/sys/block/})
416                 disktype=$(parted -s $devname print | grep -E "Partition Table|Disk label" | cut -d ":" -f "2" | t    r -d " ")
 :
430                     echo "disk $devname $devsize $disktype"

This leads to creating entry disk sda 0, which is invalid entry (missing $disktype).

I think the solution is to skip those 0 size disks completely.

pcahyna commented at 2023-03-20 16:10:¶

Potentially similar issue: #2810 , but details seem different. Possibly because in #2810 disk access fails with "No medium found", while here it returns size 0 (@rmetrich can you please check if blockdev reports blockdev: cannot open /dev/sdb: No medium found which would indicate that the drive actually behaves same as in #2810 ? ) Also please provide the USB vendor and model (lsusb output).

rmetrich commented at 2023-03-20 17:04:¶

Yes it returns "Medium not found". But I think whenever the size returned is 0, the disk should be skipped.

The SD card reader I used for reproducing is:

Bus 002 Device 007: ID 8564:4000 Transcend Information, Inc. microSD/SD/CF UHS-II Card Reader [RDF8, RDF9]

jsmeix commented at 2023-03-21 09:35:¶

@rmetrich
good to hear from you again!

Does "rear recover" work in your case
with a disk with size 0 in disklayout.conf?
I.e. when you disable (e.g. via 'return 0' as first line)
layout/save/default/950_verify_disklayout_file.sh
during "rear mkrescue/mkbackup"
does then "rear recover" work for you?

The primary reason for the tests in
layout/save/default/950_verify_disklayout_file.sh
is to avoid known cases where "rear recover" fails.
Better error out "too often" during "rear mkrescue"
than possibly let the user learn the "too hard" way
why he must verify in advance that "rear recover"
will work for him for his specific use case ;-)

jsmeix commented at 2023-03-21 09:41:¶

Regarding
https://github.com/rear/rear/issues/2958#issue-1632369838

entry 'disk sda 0', which is invalid entry (missing $disktype)

see my test in
https://github.com/rear/rear/issues/2810#issuecomment-1141138162
which shows that "rear recover" even works when there is
only a 'disk' entry without partition type label value
but nothing else for this disk exists in disklayout.conf like

disk /dev/sdb 5368709120

so perhaps "rear recover" also works when there is
only a 'disk' entry without partition type label value
and with zero disk size but nothing else for this disk
exists in disklayout.conf like

disk /dev/sdb 0

Next test would be if "rear recover" also works when there is
only a 'disk' entry without partition type label value
and without a disk size value but nothing else for this disk
exists in disklayout.conf like

disk /dev/sdb

jsmeix commented at 2023-03-21 09:52:¶

Only an offhanded idea regarding the workaroud

excluding the "disk" manually, which isn't always possible
due to non-persistent device naming

Because etc/rear/local.conf is executed as bash script
one can implement therein whatever works in the specific case
to autodetect the right disk which must be excluded.

jsmeix commented at 2023-03-21 12:50:¶

I tested how "rear recover" behaves
when there is only a 'disk' entry
but nothing else for this disk
exists in disklayout.conf

To test that I created an empty 1GiB disk on a KVM/QEMU VM.

"rear mkrescue" makes only this one disabled entry
in disklayout.conf

#disk /dev/sdb 1073741824 unknown

(1) disk /dev/sdb 1073741824 unknown¶

I tested "rear recover" with this entry enabled

disk /dev/sdb 1073741824 unknown

"rear recover" works.

I got this in diskrestore.sh

if create_component "/dev/sdb" "disk" ; then
# Create /dev/sdb (disk)

#
# Code handling disk '/dev/sdb'
#

### Disks should be block devices.
[ -b "/dev/sdb" ] || BugError "Disk /dev/sdb is not a block device."

Log "Stop mdadm"
if grep -q md /proc/mdstat 2>/dev/null; then
    mdadm --stop -s >&2 || echo "stop mdadm failed"
    # Prevent udev waking up mdadm later.
    # Reasoning: At least on RHEL6 when parted created a raid partition on disk,
    # udev (via /lib/udev/rules.d/65-md-incremental.rules) wakes up mdadm which locks the disk,
    # so further parted commands with the disk will fail since the disk is busy now.
    # The /lib/udev/rules.d/65-md-incremental.rules detects anaconda (the Red Hat installer),
    # and if it find itself running under anaconda, it will not run.
    # Accordingly also for other installers (in particular the ReaR installer)
    # this rule should not be there (and other Linux distros probably do not have it)
    # which means removing it is the right solution to make ReaR work also for RHEL6:
    if [ -e /lib/udev/rules.d/65-md-incremental.rules ] ; then
        rm -f /lib/udev/rules.d/65-md-incremental.rules || echo "rm 65-md-incremental.rules failed"
    fi
fi
Log "Erasing MBR of disk /dev/sdb"
dd if=/dev/zero of=/dev/sdb bs=512 count=1
sync

# Make sure device nodes are visible (eg. in RHEL4)
my_udevtrigger
my_udevsettle

# Clean up transient partitions and resize shrinked ones
delete_dummy_partitions_and_resize_real_ones

#
# End of code handling disk '/dev/sdb'
#

component_created "/dev/sdb" "disk"
else
    LogPrint "Skipping /dev/sdb (disk) as it has already been created."
fi

(2) disk /dev/sdb 1073741824¶

I tested "rear recover" with this entry

disk /dev/sdb 1073741824

"rear recover" works.

I got this in diskrestore.sh

if create_component "/dev/sdb" "disk" ; then
# Create /dev/sdb (disk)

#
# Code handling disk '/dev/sdb'
#

### Disks should be block devices.
[ -b "/dev/sdb" ] || BugError "Disk /dev/sdb is not a block device."

Log "Stop mdadm"
if grep -q md /proc/mdstat 2>/dev/null; then
    mdadm --stop -s >&2 || echo "stop mdadm failed"
    # Prevent udev waking up mdadm later.
    # Reasoning: At least on RHEL6 when parted created a raid partition on disk,
    # udev (via /lib/udev/rules.d/65-md-incremental.rules) wakes up mdadm which locks the disk,
    # so further parted commands with the disk will fail since the disk is busy now.
    # The /lib/udev/rules.d/65-md-incremental.rules detects anaconda (the Red Hat installer),
    # and if it find itself running under anaconda, it will not run.
    # Accordingly also for other installers (in particular the ReaR installer)
    # this rule should not be there (and other Linux distros probably do not have it)
    # which means removing it is the right solution to make ReaR work also for RHEL6:
    if [ -e /lib/udev/rules.d/65-md-incremental.rules ] ; then
        rm -f /lib/udev/rules.d/65-md-incremental.rules || echo "rm 65-md-incremental.rules failed"
    fi
fi
Log "Erasing MBR of disk /dev/sdb"
dd if=/dev/zero of=/dev/sdb bs=512 count=1
sync

# Make sure device nodes are visible (eg. in RHEL4)
my_udevtrigger
my_udevsettle

# Clean up transient partitions and resize shrinked ones
delete_dummy_partitions_and_resize_real_ones

#
# End of code handling disk '/dev/sdb'
#

component_created "/dev/sdb" "disk"
else
    LogPrint "Skipping /dev/sdb (disk) as it has already been created."
fi

I.e. same as in case (1) before

(3) disk /dev/sdb 0¶

I tested "rear recover" with this entry

disk /dev/sdb 0

"rear recover" works
but now it goes into MIGRATION_MODE (as expected):

Device sda has expected (same) size 21474836480 bytes (will be used for 'recover')
Device sdb has size 1073741824 bytes but 0 bytes is expected (needs manual configuration)
Switching to manual disk layout configuration (GiB sizes rounded down to integer)
/dev/sda has same size 21474836480 (20 GiB)
/dev/sdb had size 0 (0 GiB) but is now 1073741824 (1 GiB)
Using /dev/sda (same name and same size 21474836480) for recreating /dev/sda
Could not automap /dev/sdb (no disk with same size 0 found)
Original disk /dev/sdb does not exist (with same size) in the target system
Cannot check write protection by ID for /dev/sdb (no ID found)
Using /dev/sdb (the only available of the disks) for recreating /dev/sdb
Current disk mapping table (source => target):
  /dev/sda => /dev/sda
  /dev/sdb => /dev/sdb
...
Confirm or edit the disk mapping
...
User confirmed disk mapping

I got this in diskrestore.sh

if create_component "/dev/sdb" "disk" ; then
# Create /dev/sdb (disk)

#
# Code handling disk '/dev/sdb'
#

### Disks should be block devices.
[ -b "/dev/sdb" ] || BugError "Disk /dev/sdb is not a block device."

Log "Stop mdadm"
if grep -q md /proc/mdstat 2>/dev/null; then
    mdadm --stop -s >&2 || echo "stop mdadm failed"
    # Prevent udev waking up mdadm later.
    # Reasoning: At least on RHEL6 when parted created a raid partition on disk,
    # udev (via /lib/udev/rules.d/65-md-incremental.rules) wakes up mdadm which locks the disk,
    # so further parted commands with the disk will fail since the disk is busy now.
    # The /lib/udev/rules.d/65-md-incremental.rules detects anaconda (the Red Hat installer),
    # and if it find itself running under anaconda, it will not run.
    # Accordingly also for other installers (in particular the ReaR installer)
    # this rule should not be there (and other Linux distros probably do not have it)
    # which means removing it is the right solution to make ReaR work also for RHEL6:
    if [ -e /lib/udev/rules.d/65-md-incremental.rules ] ; then
        rm -f /lib/udev/rules.d/65-md-incremental.rules || echo "rm 65-md-incremental.rules failed"
    fi
fi
Log "Erasing MBR of disk /dev/sdb"
dd if=/dev/zero of=/dev/sdb bs=512 count=1
sync

# Make sure device nodes are visible (eg. in RHEL4)
my_udevtrigger
my_udevsettle

# Clean up transient partitions and resize shrinked ones
delete_dummy_partitions_and_resize_real_ones

#
# End of code handling disk '/dev/sdb'
#

component_created "/dev/sdb" "disk"
else
    LogPrint "Skipping /dev/sdb (disk) as it has already been created."
fi

I.e. same as in case (1) and (2) before

(4) disk /dev/sdb¶

I tested "rear recover" with this entry

disk /dev/sdb

Now "rear recover" fails

Device sda has expected (same) size 21474836480 bytes (will be used for 'recover')
Device sdb has size 1073741824 bytes but  bytes is expected (needs manual configuration)
Switching to manual disk layout configuration (GiB sizes rounded down to integer)
/dev/sda has same size 21474836480 (20 GiB)
/dev/sdb had size  (0 GiB) but is now 1073741824 (1 GiB)
Using /dev/sda (same name and same size 21474836480) for recreating /dev/sda
Could not automap /dev/sdb (no disk with same size  found)
Original disk /dev/sdb does not exist (with same size) in the target system
Cannot check write protection by ID for /dev/sdb (no ID found)
Using /dev/sdb (the only available of the disks) for recreating /dev/sdb
Current disk mapping table (source => target):
  /dev/sda => /dev/sda
  /dev/sdb => /dev/sdb
...
Confirm or edit the disk mapping
...
User confirmed disk mapping
...
Start system layout restoration.
Disk '/dev/sda': creating 'gpt' partition table
Disk '/dev/sda': creating partition number 1 with name ''sda1''
Disk '/dev/sda': creating partition number 2 with name ''sda2''
ERROR: 
====================
BUG in /var/lib/rear/layout/diskrestore.sh line 112:
'Disk  is not a block device.'
--------------------
Please report it at https://github.com/rear/rear/issues
and include all related parts from /var/log/rear/rear-localhost.log
preferably the whole debug information via 'rear -D recover'
====================
Some latest log messages since the last called script 200_run_layout_code.sh:
  2023-03-21 13:33:09.742193096 Erasing MBR of disk /dev/sda
  1+0 records in
  1+0 records out
  512 bytes copied, 0.00330212 s, 155 kB/s
  2023-03-21 13:33:09.756683476 Disk '/dev/sda': creating 'gpt' partition table
  2023-03-21 13:33:09.832794541 Disk '/dev/sda': creating partition number 1 with name ''sda1''
  2023-03-21 13:33:10.143920489 Disk '/dev/sda': creating partition number 2 with name ''sda2''
  /dev/sda: gpt partitions 1 2
Error exit of rear recover (PID 764) and its descendant processes

I got this in diskrestore.sh

if create_component "/dev/sdb" "disk" ; then
# Create /dev/sdb (disk)

#
# Code handling disk ''
#

### Disks should be block devices.
[ -b "" ] || BugError "Disk  is not a block device."

Log "Stop mdadm"
if grep -q md /proc/mdstat 2>/dev/null; then
    mdadm --stop -s >&2 || echo "stop mdadm failed"
    # Prevent udev waking up mdadm later.
    # Reasoning: At least on RHEL6 when parted created a raid partition on disk,
    # udev (via /lib/udev/rules.d/65-md-incremental.rules) wakes up mdadm which locks the disk,
    # so further parted commands with the disk will fail since the disk is busy now.
    # The /lib/udev/rules.d/65-md-incremental.rules detects anaconda (the Red Hat installer),
    # and if it find itself running under anaconda, it will not run.
    # Accordingly also for other installers (in particular the ReaR installer)
    # this rule should not be there (and other Linux distros probably do not have it)
    # which means removing it is the right solution to make ReaR work also for RHEL6:
    if [ -e /lib/udev/rules.d/65-md-incremental.rules ] ; then
        rm -f /lib/udev/rules.d/65-md-incremental.rules || echo "rm 65-md-incremental.rules failed"
    fi
fi
Log "Erasing MBR of disk "
dd if=/dev/zero of= bs=512 count=1
sync

# Make sure device nodes are visible (eg. in RHEL4)
my_udevtrigger
my_udevsettle

# Clean up transient partitions and resize shrinked ones
delete_dummy_partitions_and_resize_real_ones

#
# End of code handling disk ''
#

component_created "/dev/sdb" "disk"
else
    LogPrint "Skipping /dev/sdb (disk) as it has already been created."
fi

which is different than before at those places

#
# Code handling disk ''
#

### Disks should be block devices.
[ -b "" ] || BugError "Disk  is not a block device."

and

Log "Erasing MBR of disk "
dd if=/dev/zero of= bs=512 count=1

jsmeix commented at 2023-03-21 13:07:¶

I think the issue is more generic:

I wonder what to do when there is only a 'disk' entry
but nothing else for this disk exists in disklayout.conf?

Should such a "lonely" 'disk' entry be commented out
as it happens above for my "empty disk" test case
OR
should disks where we cannot detect the usually needed values
for disk size and partition type label be skipped
and all what possibly depends on such disks
(partitions filesystems and so one)
OR
should we somehow try to autodetect when
a disk is an empty SD card slot or the like
and then skip all of it?

If we skip disks and all what belongs to them
should we report that to the user so he is informed
(we may skip things the user expects to be included)
or would that be only unwanted noise in almost all cases?
Perhaps report it only via DebugPrint so the user can
see it when unexpected things got skipped?

pcahyna commented at 2023-03-21 13:55:¶

I wonder what to do when there is only a 'disk' entry but nothing else for this disk exists in disklayout.conf?

Should such a "lonely" 'disk' entry be commented out as it happens above for my "empty disk" test case

My preference. That's how the component exclusion code works now. If there is nothing useful on the disk (either because there is nothing at all, or because the components got excluded by the include/exclude rules) , the entry for the disk is itself excluded (commented out). This prevents formatting of disks that are not included in the backup. I rely on it in the s390 code (where the disk entry also governs low-level formatting of the disk). But even outside the context of dasd-specific stuff it makes sense.

OR should disks where we cannot detect the usually needed values for disk size and partition type label be skipped and all what possibly depends on such disks (partitions filesystems and so one)

This should not happen - if we can't detect basic stuff like partition table and size, there shouldn't be anything that depends on the disk (like partitions and anything on them)? Having a partition on a disk whose size can't be even determined or which does not have a partition table is not an expected situation. I would call BugError in this case.

OR should we somehow try to autodetect when a disk is an empty SD card slot or the like and then skip all of it?

Yes, I think we should skip disk drives without disk media (or with bad media - I saw a failing SCSI disk that was reported but with a size of 0 - it was not even a removable disk).

pcahyna commented at 2023-03-21 14:00:¶

(3) disk /dev/sdb 0¶

I tested "rear recover" with this entry
disk /dev/sdb 0
"rear recover" works

Note that as soon as the USB card reader is unplugged from the USB port, the layout code will fail because of the

[ -b "/dev/sdb" ] || BugError "Disk /dev/sdb is not a block device."

part.
So in this case it is indeed better if the disk entry gets commented out. (Of course this does not protect you against the situation where there is an actual card with data in the reader during backup and then the reader gets removed for recovery.)

pcahyna commented at 2023-03-21 14:04:¶

(Note that all the reasoning about commenting out the unused disk entries does not apply to this bug report, because the problem happens when AUTOEXCLUDE_DISKS=n)

jsmeix commented at 2023-03-21 14:13:¶

The case when there is an actual card with data in the reader
during backup and then the reader gets removed for recovery
is an unsupported migration case:
Recreating on hardware with different number of disks.
In such cases the user must manually adapt his disklayout.conf.

jsmeix commented at 2023-03-21 14:16:¶

Perhaps with AUTOEXCLUDE_DISKS=n the user cannot expect that
then certain unwanted disks get automatically excluded or skipped?

jsmeix commented at 2023-03-21 14:41:¶

I think I see now how it failed in the above case
(4) disk /dev/sdb

In layout/prepare/GNU/Linux/100_include_partition_code.sh
there is

create_disk() {
    local component disk size label junk
    local blocksize layout dasdtype dasdcyls junk2
    read component disk size label junk < <(grep "^disk $1 " "$LAYOUT_FILE")

    cat >> "$LAYOUT_CODE" <<EOF

#
# Code handling disk '$disk'
#

### Disks should be block devices.
[ -b "$disk" ] || BugError "Disk $disk is not a block device."

where the grep "^disk $1 " "$LAYOUT_FILE"
results nothing for disk /dev/sdb
because there is no trailing space after '/dev/sdb'.

In the log file that code results

++ create_disk /dev/sdb
++ local component disk size label junk
++ local blocksize layout dasdtype dasdcyls junk2
++ read component disk size label junk
+++ grep '^disk /dev/sdb ' /var/lib/rear/layout/disklayout.conf
++ cat

Sigh!
Just the usual old "blindly proceed" code, cf.
"Try hard to care about possible errors" in
https://github.com/rear/rear/wiki/Coding-Style

jsmeix commented at 2023-03-21 15:08:¶

With
https://github.com/rear/rear/commit/8bb07de7a552e72657b11b02c95f1b3c9089513c
it fails now "better" in the above case
(4) disk /dev/sdb

User confirmed disk layout file
Marking component '/dev/sda' as done in /var/lib/rear/layout/disktodo.conf
Marking component '/dev/sda1' as done in /var/lib/rear/layout/disktodo.conf
Marking component '/dev/sda2' as done in /var/lib/rear/layout/disktodo.conf
ERROR: 
====================
BUG in /usr/share/rear/layout/prepare/GNU/Linux/100_include_partition_code.sh line 31:
'No 'disk /dev/sdb ' entry in /var/lib/rear/layout/disklayout.conf'
--------------------
Please report it at https://github.com/rear/rear/issues
and include all related parts from /var/log/rear/rear-localhost.log
preferably the whole debug information via 'rear -D recover'
====================
Some latest log messages since the last called script 540_generate_device_code.sh:
  2023-03-21 16:04:29.898569368 Marking component '/dev/sda1' as done in /var/lib/rear/layout/disktodo.conf
  2023-03-21 16:04:29.909547264 Testing /dev/sda2 for dependencies...
  2023-03-21 16:04:29.917718888 deps (1): /dev/sda
  2023-03-21 16:04:29.923187643 All dependencies for /dev/sda2 are present, processing...
  2023-03-21 16:04:29.933992874 Marking component '/dev/sda2' as done in /var/lib/rear/layout/disktodo.conf
  2023-03-21 16:04:29.944777845 Testing /dev/sdb for dependencies...
  2023-03-21 16:04:29.952433935 deps (0): 
  2023-03-21 16:04:29.956760120 All dependencies for /dev/sdb are present, processing...
Aborting due to an error, check /var/log/rear/rear-localhost.log for details

It fails "better" because now it fails earlier in
layout/prepare/default/540_generate_device_code.sh
with a message that tells the actual error
and not arbitrarily later when running
the broken generated diskrestore.sh script.

pcahyna commented at 2023-03-21 15:10:¶

the grep "^disk $1 " "$LAYOUT_FILE"
results nothing for disk /dev/sdb
because there is no trailing space after '/dev/sdb'.

If the third field is mandatory, perhaps it is not a big problem if the code misbehaves without it?

jsmeix commented at 2023-03-21 15:13:¶

Yes, it is OK that the third field is mandatory.
But when it is mandatory the code should
not "blindly proceed" when it is not there.
In particular because disklayout.conf is meant
to be edited by the user when needed.

jsmeix commented at 2023-03-21 15:15:¶

With

(5) 'disk /dev/sdb ' (with a trailing space)¶

"rear recover" works as in the other cases (1)...(3)

pcahyna commented at 2023-03-21 15:26:¶

Perhaps with AUTOEXCLUDE_DISKS=n the user cannot expect that then certain unwanted disks get automatically excluded

Indeed, AUTOEXCLUDE_DISKS=y is documented as "Automatically exclude disks that are not used by mounted filesystems" in default.conf

or skipped?

I would think that invalid disks (zero-sized, missing media) should still be skipped, even with AUTOEXCLUDE_DISKS=n. It is not documented that this such a functionality (not even implemented) would depend on AUTOEXCLUDE_DISKS=y. And since excluding unused disks is a very different operation than excluding broken disks (even if in practice they tend to occur together since a broken disk is typically unused as well), I would not conflate them.

jsmeix commented at 2023-03-21 15:30:¶

OK from me to automatically exclude or silently skip
(silent means without user notification in normal modes)
broken disks regardless how AUTOEXCLUDE_DISKS is set.

pcahyna commented at 2023-03-21 15:54:¶

The case when there is an actual card with data in the reader during backup and then the reader gets removed for recovery is an unsupported migration case: Recreating on hardware with different number of disks. In such cases the user must manually adapt his disklayout.conf.

Indeed. I don't have any ambition to extend the code to support this case. I mentioned it only for completeness.

pcahyna commented at 2023-03-22 09:43:¶

Thank you @rmetrich and @jsmeix for all your information and thoughts. I now have the hardware which triggers the problem so I can continue.

jsmeix commented at 2023-03-22 13:41:¶

I think I found a (possibly severe) issue
with the current behaviour of "rear recover"
for incomplete 'disk' entries in disklayout.conf

See
https://github.com/rear/rear/issues/2958#issuecomment-1477783731
and
https://github.com/rear/rear/issues/2810#issuecomment-1141138162

The current behaviour of "rear recover"
for incomplete 'disk /dev/sdb' entries in disklayout.conf
results in diskrestore.sh (excerpt)

Log "Erasing MBR of disk /dev/sdb"
dd if=/dev/zero of=/dev/sdb bs=512 count=1
sync

which destroys the first 512 data bytes on the disk.

I am wondering if this might damage data on a disk
that is not meant to be touched by ReaR?

For example assume during "rear mkrescue/mkbackup" there is
a disk /dev/sdb with removable medium that has no medium loaded
(e.g. because that disk is not meant to be touched by ReaR)
which results an incomplete 'disk /dev/sdb' entry in disklayout.conf
but during "rear recover" there is (perhaps accidentally)
a medium loaded so "rear recover" will damage the data on the medium.

pcahyna commented at 2023-03-22 13:52:¶

IMO incomplete entries should not be allowed to occur. Unknown disk label types are covered by the literal unknown, right?
And if a device should be skipped (e.g. because there is no actual disk in the drive), I would completely avoid adding it to disklayout, instead of adding a incomplete entry.

The dd command will be problematic in any case, because if there is no medium, we do not lose any data, but dd will abort with the error message ... No medium found. And diskrestore.sh runs with errexit set...

EDIT: to answer the question - indeed it is a problem - @jsmeix good catch!

pcahyna commented at 2023-03-22 13:57:¶

By the way, after my update of the S/390 code, unformatted DASDs (which also report zero size, but unlike drives with missing media they can be opened) are already skipped from the layout entirely (except for the dasd_channel directive that causes them to be activated (to not cause unnecessary shifts in naming)).

drakkainenn commented at 2023-04-19 10:07:¶

I have almost the same issue.
My /dev/sdab is cdrom or some other device.
errors:

No partition label type for 'disk /dev/sdab' (may cause 'rear recover' failure
Verifying that the entries in /var/lib/rear/layout/disklayout.conf are correct
/dev/sdab size 0 is not a positive integer

ERROR:
BUG in /usr/share/rear/layout/save/default/950_verify_disklayout_file.sh line 254:
'Entries in /var/lib/rear/layout/disklayout.conf are broken ('rear recover' would fail)'

disklayout.conf:
# Disk /dev/sdab
# Format: disk <devname> <size(bytes)> <partition label type>
disk /dev/sdab 0

pcahyna commented at 2023-04-25 09:09:¶

@drakkainenn I believe for CD-ROM drives it should not happen, because they should not show up as /dev/sd*. But for "some other device" it certainly could, if it has removable media (e.g. a Iomega Zip would probably fall in this category).

Are you also using AUTOEXCLUDE_DISKS=n ? The problem should not happen without this setting.

[Export of Github issue for rear/rear.]

#2958 Issue open: ReaR fails while verifying the disklayout when a disk has a 0 size¶

rmetrich opened issue at 2023-03-20 15:37:¶

pcahyna commented at 2023-03-20 16:10:¶

rmetrich commented at 2023-03-20 17:04:¶

jsmeix commented at 2023-03-21 09:35:¶

jsmeix commented at 2023-03-21 09:41:¶

jsmeix commented at 2023-03-21 09:52:¶

jsmeix commented at 2023-03-21 12:50:¶

(1) disk /dev/sdb 1073741824 unknown¶

(2) disk /dev/sdb 1073741824¶

(3) disk /dev/sdb 0¶

(4) disk /dev/sdb¶

jsmeix commented at 2023-03-21 13:07:¶

pcahyna commented at 2023-03-21 13:55:¶

pcahyna commented at 2023-03-21 14:00:¶

(3) disk /dev/sdb 0¶

pcahyna commented at 2023-03-21 14:04:¶

jsmeix commented at 2023-03-21 14:13:¶

jsmeix commented at 2023-03-21 14:16:¶

jsmeix commented at 2023-03-21 14:41:¶

jsmeix commented at 2023-03-21 15:08:¶

pcahyna commented at 2023-03-21 15:10:¶

jsmeix commented at 2023-03-21 15:13:¶

jsmeix commented at 2023-03-21 15:15:¶

(5) 'disk /dev/sdb ' (with a trailing space)¶

pcahyna commented at 2023-03-21 15:26:¶

jsmeix commented at 2023-03-21 15:30:¶

pcahyna commented at 2023-03-21 15:54:¶

pcahyna commented at 2023-03-22 09:43:¶

jsmeix commented at 2023-03-22 13:41:¶

pcahyna commented at 2023-03-22 13:52:¶

pcahyna commented at 2023-03-22 13:57:¶

drakkainenn commented at 2023-04-19 10:07:¶

pcahyna commented at 2023-04-25 09:09:¶

#2958 Issue `open`: ReaR fails while verifying the disklayout when a disk has a 0 size¶