#2060 PR merged: New verify disklayout file script 950_verify_disklayout_file.sh¶
Labels: enhancement, fixed / solved / done
jsmeix opened issue at 2019-02-28 18:11:¶
-
Type: Enhancement and AvoidErrorsDuringRecovery
-
Impact: Low and High
Low impact when all is fine but hight (useful) impact when things
look fishy when disklayout.conf is created during "rear mkrescue"
to avoid that "rear recover" fails when it is too late to fix things. -
Reference to related issue (URL):
https://github.com/rear/rear/issues/1681
https://github.com/rear/rear/issues/2006#issuecomment-460646685 -
How was this pull request tested?
"rear mkrescue" still works for me on my openSUSE Leap 15.0 sytem
with that partitioning:
# parted -s /dev/sda unit MiB print
Model: ATA WDC WD10EZEX-75M (scsi)
Disk /dev/sda: 953870MiB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1.00MiB 501MiB 500MiB fat16 boot, esp
2 501MiB 937911MiB 937410MiB ext4
3 937911MiB 953870MiB 15959MiB linux-swap(v1) swap
- Brief description of the changes in this pull request:
Currently it is only verifying in disklayout.conf that
the 'disk' entries are correct
the 'part' entries are correct
the 'part' entries specify consecutive partitions
I hope it does not break things (i.e. BugError out with false alarm)
so that I hope it can be included in ReaR 2.5, more testing will tell...
jsmeix commented at 2019-03-01 08:29:¶
@rear/contributors
currently this is work in progress...
I need to enhance and fix some things...
But of course I would appreciate it very much if you have an early
look.
Perhaps you could even try it out and report things that behave wrong,
in particular when it errors out because of false alarm.
jsmeix commented at 2019-03-01 10:42:¶
I need to fix more when testing for consecutive partitions...
gozora commented at 2019-03-01 12:31:¶
@gdha
As @gozora did a great review already I can blindly approve this
Thanks for trusting in me so much! :-)
jsmeix commented at 2019-03-01 13:38:¶
@gozora
when I implemented the is_*_integer functions I needed to provide
some
backward compatibility with what was done before by is_numeric()
and there some echo had been used, see
# git log -p --follow usr/share/rear/lib/global-functions.sh
for details that lead to
https://github.com/rear/rear/commit/0eec413050319721d24c31af823da7217f84e0cf
and
https://github.com/rear/rear/pull/1706
I could try to clean up the is_*_integer functions usage in a
separated pull request.
For now in this pull request let's ignore that useless numbers output
that shows up only in case of errors via
Some latest log messages since the last called script ...
in usr/share/rear/lib/_input-output-functions.sh
jsmeix commented at 2019-03-01 13:41:¶
Since my latest
https://github.com/rear/rear/pull/2060/commits/703d5549ca24ecf2b7b4aaa518746b332e17f1d6
testing for non consecutive partitions for GPT works for me.
I have
# parted -s /dev/sda unit MiB print
Model: ATA WDC WD10EZEX-75M (scsi)
Disk /dev/sda: 953870MiB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1.00MiB 501MiB 500MiB fat16 boot, esp
2 501MiB 937911MiB 937410MiB ext4
3 937911MiB 953870MiB 15959MiB linux-swap(v1) swap
# parted -s /dev/sdb unit MiB print
Model: ATA SAMSUNG SSD SM95 (scsi)
Disk /dev/sdb: 244198MiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1.00MiB 129MiB 128MiB primary
3 81576MiB 81737MiB 161MiB primary
2 90000MiB 91000MiB 1000MiB ext2 ext2
5 94000MiB 95000MiB 1000MiB ext2 ext2
7 100000MiB 101000MiB 1000MiB ext2
10 106000MiB 107000MiB 1000MiB ext2
i.e. sda is o.k but sdb has non consecutive partitions
and "rear mkrescue" results
# usr/sbin/rear -D mkrescue
...
Verifying that the entries in /root/rear.github.master/var/lib/rear/layout/disklayout.conf are correct ...
Partitions on /dev/sdb not consecutive: /dev/sdb4 missing
Partitions on /dev/sdb not consecutive: /dev/sdb6 missing
Partitions on /dev/sdb not consecutive: /dev/sdb8 missing
Partitions on /dev/sdb not consecutive: /dev/sdb9 missing
ERROR: There are non consecutive partitions ('rear recover' would fail)
Some latest log messages since the last called script 950_verify_disklayout_file.sh:
104857600000
1048576000
111149056000
2019-03-01 14:40:51.000729343 Verifying that the 'part' entries for /dev/sdb in /root/rear.github.master/var/lib/rear/layout/disklayout.conf specify consecutive partitions
2019-03-01 14:40:51.006471463 Partitions on /dev/sdb not consecutive: /dev/sdb4 missing
2019-03-01 14:40:51.011500811 Partitions on /dev/sdb not consecutive: /dev/sdb6 missing
2019-03-01 14:40:51.014949040 Partitions on /dev/sdb not consecutive: /dev/sdb8 missing
2019-03-01 14:40:51.018250788 Partitions on /dev/sdb not consecutive: /dev/sdb9 missing
Aborting due to an error, check /root/rear.github.master/var/log/rear/rear-g243.log for details
jsmeix commented at 2019-03-01 14:36:¶
Since my latest
https://github.com/rear/rear/pull/2060/commits/20a3b3bc7caa9a0fd00c7bc3dc7f95185d76e00f
testing for non consecutive partitions for GPT works for me.
I have (same sda as above but now MBR on sdb):
# parted -s /dev/sdb unit MiB print
Model: ATA SAMSUNG SSD SM95 (scsi)
Disk /dev/sdb: 244198MiB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1000MiB 2000MiB 1000MiB primary type=83
3 10000MiB 100000MiB 90000MiB extended lba, type=0f
5 11000MiB 12000MiB 1000MiB logical ext2 type=83
6 15000MiB 16000MiB 1000MiB logical type=83
7 17000MiB 18000MiB 1000MiB logical type=83
i.e. sda is still o.k (as above) but sdb has non consecutive
partitions
and "rear mkrescue" results
Verifying that the entries in /root/rear.github.master/var/lib/rear/layout/disklayout.conf are correct ...
MBR primary and extended partitions on /dev/sdb not consecutive: /dev/sdb2 missing
ERROR: There are non consecutive partitions ('rear recover' would fail)
Some latest log messages since the last called script 950_verify_disklayout_file.sh:
1048576000
11534336000
1048576000
15728640000
1048576000
17825792000
2019-03-01 15:32:44.777938891 Verifying that the 'part' entries for /dev/sdb in /root/rear.github.master/var/lib/rear/layout/disklayout.conf specify consecutive partitions
2019-03-01 15:32:44.784635554 MBR primary and extended partitions on /dev/sdb not consecutive: /dev/sdb2 missing
Aborting due to an error, check /root/rear.github.master/var/log/rear/rear-g243.log for details
jsmeix commented at 2019-03-01 14:42:¶
In my above
https://github.com/rear/rear/pull/2060#issuecomment-468684916
I had also removed logical partitions but that did not result
non consecutive logical partitions.
Before it was
# parted -s /dev/sdb unit MiB print
Model: ATA SAMSUNG SSD SM95 (scsi)
Disk /dev/sdb: 244198MiB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1000MiB 2000MiB 1000MiB primary type=83
2 3000MiB 4000MiB 1000MiB primary type=83
3 10000MiB 100000MiB 90000MiB extended lba, type=0f
5 11000MiB 12000MiB 1000MiB logical ext2 type=83
6 13000MiB 14000MiB 1000MiB logical type=83
7 15000MiB 16000MiB 1000MiB logical type=83
8 17000MiB 18000MiB 1000MiB logical type=83
and with that (i.e. both sda and sdb are ok)
"rear mkrescue" worked for me.
Then I did:
# parted -s /dev/sdb rm 2
# parted -s /dev/sdb rm 6
# parted -s /dev/sdb unit MiB print
Model: ATA SAMSUNG SSD SM95 (scsi)
Disk /dev/sdb: 244198MiB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1000MiB 2000MiB 1000MiB primary type=83
3 10000MiB 100000MiB 90000MiB extended lba, type=0f
5 11000MiB 12000MiB 1000MiB logical ext2 type=83
6 15000MiB 16000MiB 1000MiB logical type=83
7 17000MiB 18000MiB 1000MiB logical type=83
# ls -l /dev/sdb*
brw-rw---- 1 root disk 8, 16 Mar 1 15:17 /dev/sdb
brw-rw---- 1 root disk 8, 17 Mar 1 15:17 /dev/sdb1
brw-rw---- 1 root disk 8, 19 Mar 1 15:17 /dev/sdb3
brw-rw---- 1 root disk 8, 21 Mar 1 15:17 /dev/sdb5
brw-rw---- 1 root disk 8, 22 Mar 1 15:17 /dev/sdb6
brw-rw---- 1 root disk 8, 23 Mar 1 15:17 /dev/sdb7
where "rear mkrescue" did error out as in
https://github.com/rear/rear/pull/2060#issuecomment-468684916
I got only non consecutive primary and extended partitions
but no non consecutive logical partitions.
Accordingly it seems testing for non consecutive logical partitions
is superflous but for now I would like to keep that code there
until it is clear that non consecutive logical partitions can really
never ever happen even on old systems.
I tested all the above on openSUSE Leap 15.0.
jsmeix commented at 2019-03-01 15:02:¶
@gozora
I think now it should be ok to do some more tests.
gozora commented at 2019-03-04 07:33:¶
@jsmeix sorry but I did not had time to test this PR during weekend as promised, I'll give it a chance later today (hopefully).
V.
jsmeix commented at 2019-03-05 10:46:¶
@gozora
as always many thanks for your review and your testing efforts!
rmetrich commented at 2019-03-05 14:02:¶
@jsmeix Sorry I'm late on this thread, but what is that PR effectively
doing?
Does ReaR support gaps in partition numbering?
jsmeix commented at 2019-03-05 14:45:¶
@rmetrich
Currently "rear recover" fails (or may fail) when
- a GPT partition numbering is not 1 2 3 ...
- a MBR primary partition numbering is not 1 2 ... up to 4
- a MBR logical partition numbering is not 5 6 7 ...
see https://github.com/rear/rear/issues/1681
Accordingly the new verify script
layout/save/default/950_verify_disklayout_file.sh
tests disklayout.conf after it was created by "rear mkrescue/mkbackup"
for non-consecutive partitions and lets "rear mkrescue/mkbackup"
error out if non-consecutive partitions are found, cf.
https://github.com/rear/rear/issues/1681#issuecomment-469635590
What needs to be tested is if
layout/save/default/950_verify_disklayout_file.sh
may falsely let "rear mkrescue/mkbackup" error out because of false
alarm.
The immediate workaround for the user in such cases is to remove
layout/save/default/950_verify_disklayout_file.sh
or skip what it does by adding a return 0 at its very beginning.
In such cases I will fix layout/save/default/950_verify_disklayout_file.sh
[Export of Github issue for rear/rear.]