New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ReaR fails while verifying the disklayout when a disk has a 0 size #2958
Comments
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 |
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:
|
@rmetrich Does "rear recover" work in your case The primary reason for the tests in |
Regarding
see my test in
so perhaps "rear recover" also works when there is
Next test would be if "rear recover" also works when there is
|
Only an offhanded idea regarding the workaroud
Because etc/rear/local.conf is executed as bash script |
I tested how "rear recover" behaves To test that I created an empty 1GiB disk on a KVM/QEMU VM. "rear mkrescue" makes only this one disabled entry
(1) disk /dev/sdb 1073741824 unknownI tested "rear recover" with this entry enabled
"rear recover" works. I got this in diskrestore.sh
(2) disk /dev/sdb 1073741824I tested "rear recover" with this entry
"rear recover" works. I got this in diskrestore.sh
I.e. same as in case (1) before (3) disk /dev/sdb 0I tested "rear recover" with this entry
"rear recover" works
I got this in diskrestore.sh
I.e. same as in case (1) and (2) before (4) disk /dev/sdbI tested "rear recover" with this entry
Now "rear recover" fails
I got this in diskrestore.sh
which is different than before at those places
and
|
I think the issue is more generic: I wonder what to do when there is only a 'disk' entry Should such a "lonely" 'disk' entry be commented out If we skip disks and all what belongs to them |
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
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.
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). |
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. |
(Note that all the reasoning about commenting out the unused |
The case when there is an actual card with data in the reader |
Perhaps with |
I think I see now how it failed in the above case In layout/prepare/GNU/Linux/100_include_partition_code.sh
where the In the log file that code results
Sigh! |
In layout/prepare/GNU/Linux/100_include_partition_code.sh verify we could read the intended 'disk /dev/sdX ' entry (with trailing space) from disklayout.conf and BugError if that fails, cf. #2958 (comment)
With
It fails "better" because now it fails earlier in |
If the third field is mandatory, perhaps it is not a big problem if the code misbehaves without it? |
Yes, it is OK that the third field is mandatory. |
With (5) 'disk /dev/sdb ' (with a trailing space)"rear recover" works as in the other cases (1)...(3) |
Indeed,
I would think that invalid disks (zero-sized, missing media) should still be skipped, even with |
OK from me to automatically exclude or silently skip |
Indeed. I don't have any ambition to extend the code to support this case. I mentioned it only for completeness. |
I think I found a (possibly severe) issue See The current behaviour of "rear recover"
which destroys the first 512 data bytes on the disk. I am wondering if this might damage data on a disk For example assume during "rear mkrescue/mkbackup" there is |
IMO incomplete entries should not be allowed to occur. Unknown disk label types are covered by the literal The EDIT: to answer the question - indeed it is a problem - @jsmeix good catch! |
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 |
In layout/save/GNU/Linux/200_partition_layout.sh do not error out when there is no partition label type value for a 'disk' entry in disklayout.conf because "rear recover" works in a special case without partition label type value when there is only a 'disk' entry but nothing else for this disk exists in disklayout.conf which can happen when /dev/sdX is an empty SD card slot without medium, see #2810
I have almost the same issue. No partition label type for 'disk /dev/sdab' (may cause 'rear recover' failure ERROR:
|
@drakkainenn I believe for CD-ROM drives it should not happen, because they should not show up as Are you also using |
Stale issue message |
Stale issue message |
This reverts commit 0a1d634. We now skip disks with no data (like when there is no medium), so incomplete disk entries (without partition type) should not occur anymore. Restore the code that aborted when such disks were encountered. Incomplete entries should not be allowed to occur, as they could confuse the layout restoration code. Moreover, the layout restoration wipes all disks in the layout, so if during layout restoration there happens to be a medium in the drive that was empty during layout save, the data on the medium would get overwritten and lost. And if there is not medium, the layout recreation script would fail. See the discussion at rear#2958 (comment)
This reverts commit 0a1d634. We now skip disks with no data (like when there is no medium), so incomplete disk entries (without partition type) should not occur anymore. Restore the code that aborted when such disks were encountered. Incomplete entries should not be allowed to occur, as they could confuse the layout restoration code. Moreover, the layout restoration wipes all disks in the layout, so if during layout restoration there happens to be a medium in the drive that was empty during layout save, the data on the medium would get overwritten and lost. And if there is not medium, the layout recreation script would fail. See the discussion at rear#2958 (comment)
This reverts commit 0a1d634. We now skip disks with no data (like when there is no medium), so incomplete disk entries (without partition type) should not occur anymore. Restore the code that aborted when such disks were encountered. Incomplete entries should not be allowed to occur, as they could confuse the layout restoration code. Moreover, the layout restoration wipes all disks in the layout, so if during layout restoration there happens to be a medium in the drive that was empty during layout save, the data on the medium would get overwritten and lost. And if there is not medium, the layout recreation script would fail. See the discussion at rear#2958 (comment)
This reverts commit 0a1d634. We now skip disks with no data (like when there is no medium), so incomplete disk entries (without partition type) should not occur anymore. Restore the code that aborted when such disks were encountered. Incomplete entries should not be allowed to occur, as they could confuse the layout restoration code. Moreover, the layout restoration wipes all disks in the layout, so if during layout restoration there happens to be a medium in the drive that was empty during layout save, the data on the medium would get overwritten and lost. And if there is not medium, the layout recreation script would fail. See the discussion at rear#2958 (comment)
latest upstream 2.7 at latest commit 7ce8642
N/A
N/A
N/A
N/A
USB Card Reader with no card inserted
N/A
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:
This happens when
AUTOEXCLUDE_DISKS=n
(which is not the default).None found yet, except excluding the "disk" manually, which isn't always possible due to non-persistent device naming.
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
: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.
The text was updated successfully, but these errors were encountered: