#2106 Issue closed: SLES 12.3; BTRFS; "The disk layout recreation script failed"

Labels: support / question, fixed / solved / done

asamapsa opened issue at 2019-04-02 10:52:

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"):
    2.4 / 2018-06-21

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

> OS_VENDOR=SUSE_LINUX
> OS_VERSION=12.3
> # The following information was added automatically by the mkbackup workflow:
> ARCH='Linux-i386'
> OS='GNU/Linux'
> OS_VERSION='12.3'
> OS_VENDOR='SUSE_LINUX'
> OS_VENDOR_VERSION='SUSE_LINUX/12.3'
> OS_VENDOR_ARCH='SUSE_LINUX/i386'
  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
cat /etc/rear/local.conf

> USE_STATIC_NETWORKING=y                         # to assign current IP addresses
> USE_DHCLIENT=
> 
> BACKUP_OPTIONS="nfsvers=3,nolock"               # just to be able to mount /AIX share/
> BACKUP=NETFS                                    # NFS backup /tar, TSM, and so on, possible/
> BACKUP_URL=nfs://somewhere/rear       # remote share as <scheme>://<host>/<share>
> 
> OUTPUT_OPTIONS="nfsvers=3,nolock"               # just to be able to mount /AIX share/
> OUTPUT=ISO                                      # ISO produces files suitable for booting with isolinux
> OUTPUT_URL=nfs://somewhere/rear       # location to copy ISO image to
> 
> NETFS_KEEP_OLD_BACKUP_COPY=2                    # new one & previous one
> 
> ONLY_INCLUDE_VG=("rootvg")                      # system only, w/o APP/DB -for RH
> EXCLUDE_DEVICE_MAPPING=( "loop*" "ram*" )       # no backup for mounted ISO
> 
> TMPDIR=/tmp  # alternative /tmp (as DVD size might be too big; use another location)
> 
> SSH_ROOT_PASSWORD="somewhere"                  # to access system in recovery
> 
> #SLES specific
> BACKUP_PROG_INCLUDE=( /boot/grub2/x86_64-efi /opt /var/tmp /srv /var/cache /var/lib/machines /usr/local /var/opt /boot/grub2/i386-pc /var/spool /dsv /tmp /var/log )
  • Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
    vmware guest

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

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

Hi, I'm new here.
It's about SLES 12.3 with security patches. I'd like to know if rescue would work with "tar" (for the beginning) system backup. It's only system on it - no APP/DB.

> rear -v -d mkbackup
 echo $? -0

> rear -D recover
Results with:

> [...]
>  UserInput
> 
>  -I LAYOUT_CODE_RUN needed in **/usr/share/rear/layout/recreate/default/200_run_layout_code.sh line 127
> The disk layout recreation script failed**
> 1) Rerun disk recreation script (/var/lib/rear/layout/diskrestore.sh)
> 2) View 'rear recover' log file (/var/log/rear/rear-i15340.log)
> 3) Edit disk recreation script (/var/lib/rear/layout/diskrestore.sh)
> 4) View original disk space usage (/var/lib/rear/layout/config/df.txt)
> 5) Use Relax-and-Recover shell and return back to here
> 6) Abort 'rear recover'
> (default '1' timeout 300 seconds)
> UserInput: No real user input (empty or only spaces) - using default input
> UserInput: Valid choice number result 'Rerun disk recreation script (/var/lib/rear/layout/diskrestore.sh)'
> Rerunning disk recreation script by default
> Start system layout restoration.
> Skipping /dev/sda (disk) as it has already been created.
> Skipping /dev/sda1 (part) as it has already been created.
> Skipping /dev/sda2 (part) as it has already been created.
> Skipping /dev/sda3 (part) as it has already been created.
> Creating filesystem of type btrfs with mount point / on /dev/sda1.
> Mounting filesystem /
>

So, it is not booting now.
Is it restorable in any way or the only thing I can do is reinstall the system?

  • Workaround, if any:
    No.

  • Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
    rear-zyzio.log ( I tried to remove specific for company strings. I hope file isn't broken)
    rear-zyzio.log.gz

asamapsa commented at 2019-04-02 11:42:

Reading log file I found sth crucial:

> [...]
> +++ mount -t btrfs -o rw,relatime,space_cache -o subvol=@/var/opt /dev/sda1 /mnt/local/var/opt
> +++ grep -q ' on /mnt/local/.snapshots '
> +++ tr -s '[:blank:]' ' '
> +++ mount -t btrfs
> +++ test -d /mnt/local/.snapshots
> +++ mkdir -p /mnt/local/.snapshots
> +++ mount -t btrfs -o rw,relatime,space_cache -o subvol=@/.snapshots /dev/sda1 /mnt/local/.snapshots
> mount: wrong fs type, bad option, bad superblock on /dev/sda1,
>        missing codepage or helper program, or other error
> 
>        In some cases useful info is found in syslog - try
>        dmesg | tail or so.
> ++ ((  1 == 0  ))
> ++ true
> +++ UserInput -I LAYOUT_CODE_RUN -p 'The disk layout recreation script failed' -D 'Rerun disk recreation script (/var/lib/rear/layout/diskrestore.sh)'
> [...]

My question is still current. Is it possible to restore?

jsmeix commented at 2019-04-02 14:14:

@asamapsa
your /etc/rear/local.conf does not look as if you had used
one of our example config files for the special SLES12 btrfs structure
as template for your /etc/rear/local.conf:

/usr/share/rear/conf/examples/SLE12-btrfs-example.conf
/usr/share/rear/conf/examples/SLE12-SP1-btrfs-example.conf
/usr/share/rear/conf/examples/SLE12-SP2-btrfs-example.conf

e.g. those files online at
https://github.com/rear/rear/tree/master/usr/share/rear/conf/examples

Cf. the "Disaster Recovery with Relax-and-Recover" chapter
in our "High Availability Administration Guide" for
SUSE Linux Enterprise High Availability Extension 12
that is also online available at
https://www.suse.com/documentation/sle-ha-12/book_sleha/data/cha_ha_rear.html

In general see
https://en.opensuse.org/SDB:Disaster_Recovery

jsmeix commented at 2019-04-02 14:18:

FWIW:

NETFS_KEEP_OLD_BACKUP_COPY=2

may not work as you might guess - you need to read the documentation
how each config variable actually works:

In general see usr/share/rear/conf/default.conf
or in this particular case read the section
https://en.opensuse.org/SDB:Disaster_Recovery#Relax-and-Recover_versus_backup_and_restore

jsmeix commented at 2019-04-18 12:15:

No news is good news.


[Export of Github issue for rear/rear.]