#1894 PR merged: Moved what script 67-check-by-label-cdrom.sh does into the mount_url function 'iso' case (issue1893)

Labels: enhancement, bug, cleanup, fixed / solved / done

jsmeix opened issue at 2018-08-08 13:54:

Enhanced 67-check-by-label-cdrom.sh so that now it dynamically finds out
what block device matches the RELAXRECOVER labeled ISO and
create a symlink /dev/disk/by-label/RELAXRECOVER that points
to that block device unless such a symlink already exists.

Fixed the bug that a hardcoded 'RELAXRECOVER' value was used
instead of using the value of the ISO_VOLID config variable.

Provided user information messages when things do not look o.k.
so that the user is at least made aware when the ISO content
is not accessible during 'rear recover'.

jsmeix commented at 2018-08-08 16:17:

@schabrolles
thanks for your kind review!

jsmeix commented at 2018-08-09 13:56:

With my last commit
https://github.com/rear/rear/pull/1894/commits/0c47fab08bff67994d1ff9335122fe71cf118745
I moved the basic code of the recovery system setup script 67-check-by-label-cdrom.sh
into the mount_url function 'iso' case plus additional enhancements there with a user dialog
if things are not o.k. and removed the no longer needed 67-check-by-label-cdrom.sh, see
https://github.com/rear/rear/issues/1893#issuecomment-411692041

I tested it and so far things behave now much better for me than ever before.

I use this etc/rear/local.conf

OUTPUT=ISO
BACKUP=NETFS
OUTPUT_OPTIONS="nfsvers=3,nolock"
OUTPUT_URL=nfs://10.160.4.244/nfs
BACKUP_URL=iso:///mybackup
SSH_ROOT_PASSWORD="rear"
USE_DHCLIENT="yes"
PROGRESS_MODE="plain"
PROGRESS_WAIT_SECONDS="3"
KEEP_BUILD_DIR="yes"
MODULES=( 'all_modules' )
FIRMWARE_FILES=( 'no' )

I need MODULES=( 'all_modules' ) because without it
I get on my SLES12 x86_64 KVM system

RESCUE f144:~ # rear -D recover
Relax-and-Recover 2.4 / Git
Running rear recover (PID 1263)
Using log file: /var/log/rear/rear-f144.log
Running workflow recover within the ReaR rescue/recovery system
ERROR: Mount command 'mount /dev/disk/by-label/RELAXRECOVER /tmp/rear.KPD7lnrKA1nbRps/outputfs' failed.
Some latest log messages since the last called script 060_mount_NETFS_path.sh:
  2018-08-09 12:56:49.231229703 Including verify/NETFS/default/060_mount_NETFS_path.sh
  2018-08-09 12:56:49.231961813 Entering debugscripts mode via 'set -x'.
  mkdir: created directory '/tmp/rear.KPD7lnrKA1nbRps/outputfs'
  2018-08-09 12:56:49.236236643 Added 'rmdir -v /tmp/rear.KPD7lnrKA1nbRps/outputfs >&2' as an exit task
  2018-08-09 12:56:49.240332127 Mounting with 'mount /dev/disk/by-label/RELAXRECOVER /tmp/rear.KPD7lnrKA1nbRps/outputfs'
  mount: unknown filesystem type 'iso9660'
Aborting due to an error, check /var/log/rear/rear-f144.log for details
Exiting rear recover (PID 1263) and its descendant processes
Running exit tasks
You should also rm -Rf /tmp/rear.KPD7lnrKA1nbRps
Terminated

where mount: unknown filesystem type 'iso9660'
is exactly my example for https://github.com/rear/rear/issues/1202
see also https://github.com/rear/rear/issues/1891#issuecomment-410757405

When all is o.k. there is no visible difference (the difference behind the scenes is
that now the mount_url function 'iso' case checks whether or not things look o.k.).

Things just repair automatically when the /dev/disk/by-label/RELAXRECOVER
does not point to a block device with filesystem label RELAXRECOVER
if such a block device exists. I tested that by manually

# ln -vsf /dev/doesnotexist /dev/disk/by-label/RELAXRECOVER

before running 'rear recover'.

To test how things behave when there is no block device
that uses the filesystem label RELAXRECOVER
I disconnected the virtual CDROM drive from my SLES12 KVM system
which leads in 'rear recover' to

A symlink '/dev/disk/by-label/RELAXRECOVER' is required that points to the device with the ReaR ISO image
UserInput -I RELAXRECOVER_SYMLINK_TARGET needed in /usr/share/rear/lib/global-functions.sh line 436
Create symlink '/dev/disk/by-label/RELAXRECOVER' that points to the ReaR ISO image device
1) /dev/cdrom is where the ISO is attached to
2) /dev/sr0 is where the ISO is attached to
3) /dev/sr1 is where the ISO is attached to
4) Use Relax-and-Recover shell and return back to here
5) Continue 'rear recover'
6) Abort 'rear recover'
(default '1' timeout 300 seconds)

I went to the Relax-and-Recover shell to get any time I need,
re-connected the virtual CDROM drive to my SLES12 KVM system
and in the Relax-and-Recover shell I did (excerpts):

rear> blkid
...
/dev/sr1: UUID="2018-08-09-13-23-35-00" LABEL="RELAXRECOVER" TYPE="iso9660"

rear> ln -vsf /dev/sr1 /dev/disk/by-label/RELAXRECOVER
'/dev/disk/by-label/RELAXRECOVER' -> '/dev/sr1'

rear> ls -l /dev/disk/by-label/RELAXRECOVER
lrwxrwxrwx 1 root root 8 Aug  9 13:33 /dev/disk/by-label/RELAXRECOVER -> /dev/sr1

rear> exit
Are you sure you want to exit the Relax-and-Recover shell ? y
exit
UserInput -I RELAXRECOVER_SYMLINK_TARGET needed in /usr/share/rear/lib/global-functions.sh line 436
Create symlink '/dev/disk/by-label/RELAXRECOVER' that points to the ReaR ISO image device
1) /dev/cdrom is where the ISO is attached to
2) /dev/sr0 is where the ISO is attached to
3) /dev/sr1 is where the ISO is attached to
4) Use Relax-and-Recover shell and return back to here
5) Continue 'rear recover'
6) Abort 'rear recover'
(default '1' timeout 300 seconds)
5
UserInput: Valid choice number result 'Continue 'rear recover''
User chose to continue 'rear recover'
Restoring from '/tmp/rear.FkTKFCef55A9z4g/outputfs/mybackup/backup.tar.gz' (restore log in /var/lib/rear/restore/recover.backup.tar.gz.1252.restore.log) ...
Backup restore program 'tar' started in subshell (PID=4438)
...

It should have also worked to re-connected the virtual CDROM drive
while the 300 seconds timeout waiting and then select
3) /dev/sr1 is where the ISO is attached to
provided one knows that the re-connected virtual CDROM drive
will re-appear as /dev/sr1 in the KVM system.
In general I prefer the Relax-and-Recover shell to fix things
because there I have any time I need and I can do all I like.

jsmeix commented at 2018-08-10 08:49:

I slept over my last changes, cf.
https://github.com/rear/rear/issues/1893#issuecomment-411771035
and nothing appeared over night so that I would like
to merge it soon today unless there are objections.

[Export of Github issue for rear/rear.]