#1778 Issue closed: mkpart fails with off by one error

Labels: support / question, not ReaR / invalid

ritzmann opened issue at 2018-04-17 22:59:

Relax-and-Recover (ReaR) Issue Template

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

  • ReaR version ("/usr/sbin/rear -V"):
    Latest Git clone, commit dd982ebee860c46015f19fc74fe3f13dc0468f02
    (rear -V prints: Relax-and-Recover 2.3 / 2017-12-20)

  • OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"):
    Debian GNU/Linux 8.10 (jessie)

  • ReaR configuration files ("cat /etc/rear/site.conf" or "cat /etc/rear/local.conf"):
    Included in rear.zip

  • System architecture (x86 compatible or POWER and/or what kind of virtual machine):
    amd64, restoration tested with VirtualBox Debian 64 bit machine

  • Are you using BIOS or UEFI or another way to boot?
    UEFI on backed up machine, BIOS in VirtualBox

  • Brief description of the issue:
    Steps to reproduce:

  • Format USB stick: rear -v mkformat /dev/sdl

  • Create rescue image: rear -v mkrescue
  • Boot stick from VirtualBox image with single hard drive attached and run rear restore
  • Restore fails with:
    +++ parted -s /dev/sda mkpart ''''logical'''' 256901120B 8719433718B
    Error: You requested a partition from 257MB to 8719MB (sectors 501760..17030143).
    The closest location we can manage is 257MB to 8719MB (sectors 501760..17030142).

Rear log and disklayout.conf are included in rear.zip.

  • Work-around, if any:

jsmeix commented at 2018-04-18 07:51:

@ritzmann
your rear-drossel.log contains (excerpts):

2018-04-18 01:38:49.260691926 Including layout/prepare/default/250_compare_disks.sh
2018-04-18 01:38:49.263550111 Comparing disks
2018-04-18 01:38:49.314407971 Comparing sdc
2018-04-18 01:38:49.316833419 Device sdc does not exist (manual configuration needed)
2018-04-18 01:38:49.320213737 Switching to manual disk layout configuration
...
2018-04-18 01:39:03.347164368 Including layout/prepare/default/400_autoresize_disks.sh
/usr/share/rear/layout/prepare/default/400_autoresize_disks.sh: line 10: backup_file: command not found
2018-04-18 01:39:03.368436066 Total resize of -482927992832B
2018-04-18 01:39:03.371575850 Searching for resizeable partitions on disk /dev/sda (17179869184B)
2018-04-18 01:39:03.384002290 Will not resize partition /dev/sda1.
2018-04-18 01:39:03.405380984 Will resize partition /dev/sda2.
2018-04-18 01:39:03.415167424 Will resize partition /dev/sda5.
2018-04-18 01:39:03.428222714 Resized partition /dev/sda2 from 499849888768B to 8462532616B.
2018-04-18 01:39:03.441723872 Resized partition /dev/sda5 from 499849887744B to 8462532599B.
2018-04-18 01:39:03.452081054 Including layout/prepare/default/420_autoresize_last_partitions.sh
17179869184
256901120
(standard_in) 1: syntax error
0
16922969088
2018-04-18 01:39:03.575701514 Including layout/prepare/default/430_autoresize_all_partitions.sh

You are in migration mode and
your ReaR scripts are messed up because there should be
either the old
layout/prepare/default/400_autoresize_disks.sh
or the new
layout/prepare/default/420_autoresize_last_partitions.sh
plus
layout/prepare/default/430_autoresize_all_partitions.sh

The old layout/prepare/default/400_autoresize_disks.sh
had severe issues, cf.
https://github.com/rear/rear/issues/1731
https://github.com/rear/rear/pull/1733
https://github.com/rear/rear/pull/1746
https://github.com/rear/rear/commit/32eafc491f793e5b8a510ff8f4219ff9be2a7edf

Therefore I recommend that you
first and foremost use a clean set of ReaR scripts
before we do any further debugging of issues.

To use our current ReaR upstream GitHub master code
do the following:

Basically "git clone" it into a separated directory and then
configure and run ReaR from within that directory like:

# git clone https://github.com/rear/rear.git

# mv rear rear.github.master

# cd rear.github.master

# vi etc/rear/local.conf

# usr/sbin/rear -D mkbackup

Note the relative paths "etc/rear/" and "usr/sbin/".

@ritzmann
because your current ReaR scripts are messed up
I close this issue as invalid.
If issues appear with a clean set of ReaR scripts
report them as new separated issues.

gozora commented at 2018-04-18 07:56:

Hello @ritzmann,

EFI based USB device needs to be formatted with command `rear format -- --efi /dev/<device_name>'

So in your case it would be:
# rear format -- --efi /dev/sdl

Also make sure that you are restoring to correct USB device. I happened several times already that ReaR recovery system (source boot USB disk) was overwritten due bad user decision.

V.

jsmeix commented at 2018-04-18 08:10:

@ritzmann
only FYI regarding your

UEFI on backed up machine, BIOS in VirtualBox
...
Format USB stick: rear -v mkformat /dev/sdl
Create rescue image: rear -v mkrescue
Boot stick from VirtualBox image with single hard drive attached and run rear restore

It seems you also like to migrate from UEFI to BIOS.

Bootloader migration is not supported by ReaR, cf.
https://github.com/rear/rear/issues/1437
and for an example how bootloader migration may go wrong see
https://github.com/rear/rear/issues/1271#issuecomment-347555836

See also
"Fully compatible replacement hardware is needed" at
https://en.opensuse.org/SDB:Disaster_Recovery
and in the "See also" section the link to the
"Essentials about disaster recovery with Relax-and-Recover presentation PDF" at
https://en.opensuse.org/images/8/85/Essentials_about_disaster_recovery_with_rear_jsmeix_presentation_v1.pdf

ritzmann commented at 2018-04-18 11:27:

Sorry for the unnecessary work that I caused. I will clean up my installation as instructed.

The UEFI - BIOS mess was of course not intentional either, VirtualBox was just the easiest way to test the restore procedure without messing with my existing setup. I believe I can switch the virtual machine to boot with UEFI in VirtualBox.

jsmeix commented at 2018-04-18 12:19:

No worries!
Your issue report was good so that it was easy
to detect what is wrong in your case.

FYI:

For real debugging an issue a log with debug info is needed,
cf. "Debugging issues with Relax-and-Recover" at
https://en.opensuse.org/SDB:Disaster_Recovery

Regarding bootloader migration:

That bootloader migration is not supported by ReaR
only means exactly what it tells:

The ReaR scripts do not help you to migrate your bootloader.

But you can of course manually migrate your bootloader
after "rear recover" had finished when you are still in the
running ReaR recovery system.

The ReaR recovery system is a rather minimal
but fully working installation system where you can do
all what is needed to install a system from scratch.

But by default the ReaR recovery system contains only
those programs that are needed to recreate the original system
as it was before.

For example when you like to migrate from one filesystem
to a different one (e.g. from btrfs to XFS) the needed things
to create an XFS filesystem (mainly mkfs.xfs plus perhaps
some XFS-specific kernel modules) get by default not
included in the ReaR recovery system when that is made
(i.e. during "rear mkrescue/mkbackup" on the original system).
E.g. regarding migration from btrfs to XFS see
http://lists.relax-and-recover.org/pipermail/rear-users/2018-April/003547.html

But via ReaR config variables like COPY_AS_IS, PROGS,
LIBS, MODULES,... you can specify any additional stuff
that you need to get included in your ReaR recovery system
during "rear mkrescue/mkbackup" to have your ReaR recovery
system prepared for basically any special manual migration
actions that you like to do.

I am not at all a bootloader expert but I guess migrating the
bootloader from UEFI to BIOS is perhaps relatively easy.
I would hope manually recofiguring and reinstalling GRUB is sufficient.
In contrast I guess migrating the bootloader from BIOS to UEFI
is more complicated because for UEFI you also need the right
GPT partitioning (e.g. with an ESP partition and things like that)
and if you like to migrate BIOS with MBR partitioning to UEFI
I assume things could get somewhat complicated.

[Export of Github issue for rear/rear.]