#1893 Issue closed: recovery system setup script 67-check-by-label-cdrom.sh functionality needs to be overhauled¶
Labels: enhancement, bug, cleanup, fixed / solved / done
jsmeix opened issue at 2018-08-07 11:30:¶
The current
usr/share/rear/skel/default/etc/scripts/system-setup.d/67-check-by-label-cdrom.sh
works mostly by chance and not sufficiently fail save.
It blindly links /dev/cdrom or /dev/sr0 to
/dev/disk/by-label/RELAXRECOVER
regardless what /dev/cdrom or /dev/sr0 actually is,
perhaps the RELAXRECOVER labeled ISO image is attached to /dev/sr1?
And there is no proper error handling.
If things fail it just proceeds.
At least some meaningful error message should be shown to the user
so that he is aware when no RELAXRECOVER labeled thingy exists.
For an example see
https://github.com/rear/rear/issues/1891#issuecomment-411017183
Since
https://github.com/rear/rear/pull/1885
is merged
together with blockdev also lsblk gets included in the recovery system
(if it exists on the original system) so that now lsblk can be used by
default to
determine disk values and the block device structure in the recovery
system.
This can be used to enhance 67-check-by-label-cdrom.sh to find out
what kernel device nodes match RELAXRECOVER labeled thingies
or CDROM devices in general.
For example in my recovery system
on a KVM machine with two virtual IDE CDROM drives as in
https://github.com/rear/rear/pull/1885#issuecomment-410697398
I get
RESCUE f144:~ # lsblk -i -d -o KNAME,TYPE,FSTYPE,LABEL KNAME TYPE FSTYPE LABEL sda disk sdb disk sr0 rom iso9660 RELAXRECOVER sr1 rom
so that from this info /dev/sr0 is the right kernel device node that
should be linked
to /dev/disk/by-label/RELAXRECOVER if such a link does not yet exist.
schabrolles commented at 2018-08-07 12:09:¶
@jsmeix, we can also use blkid -L <label> for that purpose. It returns
the device associated with this label. Here is an example on one of my
system:
# blkid -L RELAXRECOVER
/dev/sr0
jsmeix commented at 2018-08-07 12:30:¶
@schabrolles
thanks for the more straightforward way to get it!
Unfortunately I had read the blkid man page that reads on my SLES12
system
with blkid from util-linux 2.29.2 (libblkid 2.29.2, 22-Feb-2017):
It is recommended to use lsblk(8) command to get information about block devices rather than blkid. lsblk(8) provides more information, better control on output formatting and it does not require root permissions to get actual information.
;-)
jsmeix commented at 2018-08-09 09:12:¶
As always sleeping over it helped:
Meanwhile I think the following:
https://github.com/rear/rear/issues/1891
and
https://github.com/rear/rear/issues/326
are exactly the same issue because in both cases the root cause is
that
the /dev/disk/by-label/ directory is empty (or does not exist).
The only place where /dev/disk/by-label/$ISO_VOLID is actually needed
is by the mount_url function in
usr/share/rear/lib/global-functions.sh
when the URL scheme is 'iso' so that the only place where things can go
wrong
is when the mount_url function is called with URL scheme 'iso'.
Accordingly it is not needed to try to ensure in a recovery system setup
script
that a symlink /dev/disk/by-label/$ISO_VOLID exists that points to a
block device
where a $ISO_VOLID labeled thingy is attached to (that thingy is the
ReaR ISO).
The actually right place where to deal with this issue is the mount_url
function
when it is called with URL scheme 'iso'.
One advantage is that I do no longer need to test in the system setup
script
the conditions when such a symlink is actually needed to avoid
to show probably confusing 'false alarm' messages to the user.
Another advantage to deal with the issue where it actually causes an
error is
that when the mount_url function is called we are inside the running
'rear recover'
where we have the full set of ReaR variables available plus the
UserInput function
and the rear shell so that when the needed symlink is not there
we can do a user dialog where the user can choose the right block
device
or where the user can run the rear shell within the running 'rear
recover'
to set up the needed symlink as he likes.
Accordingly I will move 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 remove the recovery system setup script 67-check-by-label-cdrom.sh
This way I can also avoid the current awkward ways how to show
messages to the user from a running system setup script:
I would have to add sleep delays so that the user can actually read
the
messages before they go away when all system setup scripts had finished.
Furthermore messages from a system setup script won't help much
because the user can do nothing at this point because the
system setup scripts cannot be easily interrupted:
User dialogs in system setup scripts are awkward compared to
user dialogs while a 'rear $WORKFLOW' runs because in the latter case
we have the UserInput function that cannot be sourced by system setup
scripts
because the current lib/_input-output-functions.sh does also some
very basic 'rear $WORKFLOW' setup like ExitTask setup and
STDIN STDOUT STDERR redirection which is a known mess
that would need to be cleaned up (like many other things in ReaR)
but I find no time for things like
https://github.com/rear/rear/issues/1251
jsmeix commented at 2018-08-09 14:06:¶
With my commit
https://github.com/jsmeix/rear/commit/0c47fab08bff67994d1ff9335122fe71cf118745
I implemented
https://github.com/rear/rear/issues/1893#issuecomment-411692041
and as far as I tested it things behave now much better for me than ever
before, see
https://github.com/rear/rear/pull/1894#issuecomment-411766357
jsmeix commented at 2018-08-09 14:09:¶
I will sleep once more over it
and if nothing "appears" over night
I would like to merge it tomorrow
so that also @dewagner1 and @suseusr168 could test it.
jsmeix commented at 2018-08-10 10:47:¶
With
https://github.com/rear/rear/pull/1894
merged
this issue should be fixed.
[Export of Github issue for rear/rear.]