#1933 Issue closed: partitions are not recreated /usr/share/rear/layout/prepare/GNU/Linux/120_include_raid_code.sh: line 78: create_partitions: command not found

Labels: bug, support / question, fixed / solved / done

mailinglists35 opened issue at 2018-10-16 10:10:

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"):
    config from #1930

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

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

  • Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):

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

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

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

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

attempt to restore fails with "the disk recreation script failed"
log and disk layout https://pastebin.com/eTBvM6LP

  • Work-around, if any:

mailinglists35 commented at 2018-10-16 11:35:

I've tried again with latest master and disk partitions were correctly recreated. parhaps the issue #1931 was preventing correct restore? I've also observed parted was missing from rescue ("/usr/share/rear/lib/_input-output-functions.sh: line 328: type: parted: not found" in pastebin logs) so I added it to PROGS. don't know which one was truly the root cause but it works now.

gdha commented at 2018-10-16 11:44:

@mailinglists35 pls paste your /etc/rear/local.conf file for review

jsmeix commented at 2018-10-16 11:49:

https://pastebin.com/raw/eTBvM6LP
contains

2018-10-16 01:56:11.701248246 Including layout/prepare/GNU/Linux/100_include_partition_code.sh
/usr/share/rear/lib/_input-output-functions.sh: line 328: type: parted: not found

which is the very fist thing that goes wrong and all the rest are only bad
consequences because afterwards ReaR blindly proceeds and errors out
somewhere later at an unrelated place with a weird error message, cf.
https://github.com/rear/rear/wiki/Coding-Style

@mailinglists35
first get your https://github.com/rear/rear/issues/1930 fixed
then usr/share/rear/layout/prepare/GNU/Linux/100_include_partition_code.sh
that defines the create_partitions() function
will not blindly and silently return too early.

@gdha
I think it is a bug that 100_include_partition_code.sh
blindly returns when there is no parted.
I think this is against "Try to care about possible errors" in
https://github.com/rear/rear/wiki/Coding-Style
I think it should verbosely error out in this case.

I think that is another place of old code in ReaR that we need to clean up
where as usual the code is without a comment that explains what the reason
behind is why 100_include_partition_code.sh could blindly return when
there is no parted.

If you do not object I will just now change that and let it error out there.

gdha commented at 2018-10-16 11:56:

@jsmeix Thanks Johannes as always for cleaning up the mesh produced by others 👍

mailinglists35 commented at 2018-10-16 12:13:

@jsmeix I fixed 1930; local.conf:

BACKUP=NETFS
OUTPUT=PXE
BACKUP_PROG=rsync
BACKUP_URL=nfs://bkp1/srv/bkp1/backups/jump
BACKUP_PROG_EXCLUDE=( "${BACKUP_PROG_EXCLUDE[@]}" '/home/csl/rpmbuild*' '/home/cst/rpmbuild*' '/var/cache' )
PROGS=( "${PROGS[@]}" zfs zpool zdb zstreamdump mount.zfs parted ncdu )
USE_DHCLIENT=y

jsmeix commented at 2018-10-16 12:21:

@gdha
actually I am very grateful for what our predecessors contributed.
Without their contributions ReaR would not be what it is nowadays:
The de facto standard tool for disaster recovery on Linux.

This issue should now be fixed via
https://github.com/rear/rear/commit/17e5c7b7a563e8caf1c9d33c0023969c142a9cf7

Even if there is a subtle exceptional corner case where things work
even without having parted in the recovery system, then the user
who actaully has this special case can adapt his 100_include_partition_code.sh
to not error out there (e.g. by adding an initial return line).

mailinglists35 commented at 2018-10-16 12:24:

thank you so much for the extremely fast response and fix!

jsmeix commented at 2018-10-16 12:30:

@mailinglists35
when you really need PROGS=( "${PROGS[@]}" ... parted ... )
something strange is going on in your particular case
because I never needed it and I do not know about any case
where it was needed to explicitly add 'parted' to the PROGS array.

In your case your https://github.com/rear/rear/files/2480027/rear-gw2.log
from your https://github.com/rear/rear/issues/1930#issuecomment-429964990
contains (as expected)

+ source /usr/share/rear/conf/GNU/Linux.conf
++ REQUIRED_PROGS=("${REQUIRED_PROGS[@]:-}" parted)
.
.
.
+ source /usr/share/rear/build/GNU/Linux/390_copy_binaries_libraries.sh
...
+++ echo '2018-10-15 21:13:42.033200666 Found binary /sbin/parted'
...
++ Log 'Binaries being copied: ... /sbin/parted ...
...
++ cp --verbose --archive --dereference --force /sbin/parted /tmp/rear.2Cj7RPbPv9hH6hP/rootfs/bin

so that 'parted' is copied into your recovery system - as far as your log tells.

mailinglists35 commented at 2018-10-16 12:55:

when you really need PROGS=( "${PROGS[@]}" ... parted ... )

I had to put parted there because on restore log I was stuck in not creating partitions and I noticed on the restore log that it was a warning about parted not found.

I will try again with updated commit to see if now parted is there by default without having to add it to PROGS

thank you again! :)


[Export of Github issue for rear/rear.]