#1718 Issue closed: "rear recover" can re-create overlapping partitions in case of an extended partition¶
Labels: bug, fixed / solved / done
abbbi opened issue at 2018-01-31 08:32:¶
hi,
this should be more a discussion as a issue.
Rear 2.3
Ubuntu 10.X (very old, i know)
While moving a system to another host using REAR i came along this
interesting disk layout.
The original disk is formatted like this:
Number Start End Size Type File system Flags
1 32256B 53686402559B 53686370304B extended
5 64512B 53686402559B 53686338048B logical
2 53686402560B 107372805119B 53686402560B primary
disklayout.conf for this device looks like this:
disk /dev/sdc 107374182400 msdos
# Partitions on /dev/sdc
part /dev/sdc 1024 32256 extended none /dev/sdc1
part /dev/sdc 53686402560 53686402560 primary none /dev/sdc2
part /dev/sdc 53686338048 64512 logical none /dev/sdc5
However, the disk layout recration script fails with:
+++ parted -s /dev/sdc mkpart primary 2101248B 64426648780B
Error: Can't have overlapping partitions.
the commands beeing used are:
rear> grep "parted -s /dev/sdc mkpart" /var/log/rear/rear-sepcrm2.log
+++ parted -s /dev/sdc mkpart extended 2097152B 128849018879B
+++ parted -s /dev/sdc mkpart primary 2101248B 64426648780B
i was able to recreate the disks partitions by editing the recovery
script and giving it
clear assigments, thus the partitions not overlapping.
The main question here for me is: clearly the disk is partitioned in a very strange way:
- should REAR work around this?
- should it even work?
- would there be a possibility to detect such caveats during creation
of the recovery iso and
either warn the user about a strange disk layout, or even fail? I think that would better than leaving the user with a frustrating situation during restore.
abbbi commented at 2018-01-31 08:32:¶
attached the full restore log
gdha commented at 2018-01-31 09:12:¶
Be aware SLES 10 is not official supported anymore by ReaR.
jsmeix commented at 2018-01-31 09:19:¶
I think what is missing in general in ReaR are various verification
tests
that run during "rear mkbackup/mkrescue" to verify that things
on the original system look o.k. (as far as possible with reasonable
effort)
so that one can more often expect that also later during "rear
recover"
things work o.k. (as far as possible with reasonable effort), e.g. see
https://github.com/rear/rear/issues/1711#issuecomment-361544271
In particular there are tests missing that verify
whether or not the entries in disklayout.conf look o.k.
(as far as possible with reasonable effort), e.g. see
https://github.com/rear/rear/issues/1704
and
https://github.com/rear/rear/issues/1563#issuecomment-361561739
jsmeix commented at 2018-01-31 09:29:¶
Only FYI:
Regardles that SLE10 is not officially supported
(which means there is no support for SLE10 specific issues)
ReaR 2.3 even worked for me on SLE10 to some reasonable extent, cf.
https://github.com/rear/rear/wiki/Test-Matrix-rear-2.3
Also Ubuntu 10.X is not officially supported
see "Supported Operating Systems" at
http://relax-and-recover.org/documentation/release-notes-2-3
which means there is no support for Ubuntu < 12 specific issues
but as far as I see this issue here is a generic issue because I think
overlapping partitions could happen on any Linux distribution.
For me the main question here is if it is worth the effort
to check the entries in disklayout.conf for overlapping partitions
because it seems parted refuses to set up overlapping partitions
so that overlapping partitions are probably an extreme corner case
and testing for extreme corner cases is beyond "reasonable effort".
gdha commented at 2018-01-31 09:33:¶
@jsmeix a discussion point for us at Fosdem
jsmeix commented at 2018-03-01 13:56:¶
I close it as "won't fix" because while I was working
on
https://github.com/rear/rear/pull/1733
I found that detecting overlapping partitions is too complicated
to be implemented with reasonable effort because in case of
an extended partition its logical partitions are inside the extended
partition
so that an extended partition must completely overlap its logical
partitions
which makes the whole overlapping partitions detecting code too
complicated
to be implemented with reasonable effort.
This does of course not mean that I would reject a GitHub pull request
that
implements checking the entries in disklayout.conf for overlapping
partitions
and/or other validation tests for the entries in disklayout.conf.
It only means that from my current point of view it looks too
complicated
to be implemented with reasonable effort by me.
jsmeix commented at 2018-03-05 13:58:¶
I think I see now and I can understand what actually went wrong in
https://github.com/rear/rear/issues/1718#issue-293071380
On the original system the partitions do not overlap
but the parted commands that are generated during "rear recover"
have partitioning data that would create overlapping partitions.
The reason is a (from my point of view severe) bug in how
"rear recover" recreated partitions before I merged
https://github.com/rear/rear/pull/1733
One bug was that the extended partition size was not correctly
detected
(in disklayout.conf it is only 1024 bytes) which I fixed
in
https://github.com/rear/rear/pull/1733
via
https://github.com/rear/rear/pull/1733/commits/6efb681d8b4c6a4d9f20b2900bbea79548c624a8
Because of the former bug the next bug was that during "rear recover"
it recreated extended partitions always up to the end of the disk
which I fixed in
https://github.com/rear/rear/pull/1733
via
https://github.com/rear/rear/pull/1733/commits/f4273dc500be87263297f88827508b64d521ccf1
Accordingly I think this issue here is a real (severe) bug
which is meanwhile fixed via
https://github.com/rear/rear/pull/1733
@abbbi
please try out the latest ReaR GitHub master code and
provide feedback whether or not it is actually fixed now for you.
In default.conf read the sections about MIGRATION_MODE
and the new AUTORESIZE_PARTITIONS
AUTORESIZE_EXCLUDE_PARTITIONS
AUTOSHRINK_DISK_SIZE_LIMIT_PERCENTAGE
AUTOINCREASE_DISK_SIZE_THRESHOLD_PERCENTAGE
config variables because since
https://github.com/rear/rear/pull/1733
the default behaviour changed.
jsmeix commented at 2018-03-06 11:08:¶
I tested the latest ReaR GitHub master code
whether or not it works when after the extended partition
there is one more primary partition and for me it "just works".
On my original system I have this sdb
# parted -s /dev/sdb unit MiB print Model: ATA QEMU HARDDISK (scsi) Disk /dev/sdb: 2048MiB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 8.00MiB 808MiB 800MiB primary ext2 type=83 2 808MiB 1208MiB 400MiB primary linux-swap(v1) type=82 3 1208MiB 1708MiB 500MiB extended lba, type=0f 5 1209MiB 1300MiB 91.0MiB logical ext2 type=83 6 1400MiB 1600MiB 200MiB logical ext2 type=83 4 1800MiB 2000MiB 200MiB primary ext2 type=83 # parted -s /dev/sdb unit B print Model: ATA QEMU HARDDISK (scsi) Disk /dev/sdb: 2147483648B Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 8388608B 847249407B 838860800B primary ext2 type=83 2 847249408B 1266679807B 419430400B primary linux-swap(v1) type=82 3 1266679808B 1790967807B 524288000B extended lba, type=0f 5 1267728384B 1363148799B 95420416B logical ext2 type=83 6 1468006400B 1677721599B 209715200B logical ext2 type=83 4 1887436800B 2097151999B 209715200B primary ext2 type=83
On the replacement system I have a sdb with same size (also 2 GiB)
and "rear recover" recreated byte-by-byte identical partitioning:
RESCUE d57:~ # parted -s /dev/sdb unit MiB print Model: ATA QEMU HARDDISK (scsi) Disk /dev/sdb: 2048MiB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 8.00MiB 808MiB 800MiB primary type=83 2 808MiB 1208MiB 400MiB primary type=83 3 1208MiB 1708MiB 500MiB extended lba, type=0f 5 1209MiB 1300MiB 91.0MiB logical type=83 6 1400MiB 1600MiB 200MiB logical ext2 type=83 4 1800MiB 2000MiB 200MiB primary ext2 type=83 RESCUE d57:~ # parted -s /dev/sdb unit B print Model: ATA QEMU HARDDISK (scsi) Disk /dev/sdb: 2147483648B Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 8388608B 847249407B 838860800B primary type=83 2 847249408B 1266679807B 419430400B primary type=83 3 1266679808B 1790967807B 524288000B extended lba, type=0f 5 1267728384B 1363148799B 95420416B logical type=83 6 1468006400B 1677721599B 209715200B logical ext2 type=83 4 1887436800B 2097151999B 209715200B primary ext2 type=83
On the original system only /dev/sdb4 and /dev/sdb6 are mounted
# mount | grep sdb /dev/sdb4 on /data.primary4 type ext2 (rw) /dev/sdb6 on /data.logical2 type ext2 (rw)
which is the reason why no other filesystems were re-created
on sdb during "rear recover", cf. at the bottom of
https://github.com/rear/rear/pull/1733#issuecomment-369563496
[Export of Github issue for rear/rear.]