#1573 PR merged: Use UserInput in some more usual places¶
Labels: enhancement, documentation, cleanup,
fixed / solved / done
jsmeix opened issue at 2017-11-13 13:14:¶
Use UserInput in 500_confirm_layout_file.sh
(renamed from 500_confirm_layout.sh)
and in 100_confirm_layout_code.sh
(renamed from 100_ask_confirmation.sh)
to improve that 'rear recover' can run
unattended in migration mode, cf.
https://github.com/rear/rear/issues/1399
jsmeix commented at 2017-11-13 13:20:¶
Now for me "rear recover" in migration mode
looks like (excerpts):
RESCUE e205:~ # rear recover
...
Current disk mapping table (source -> target):
/dev/sda /dev/sda
Confirm or edit the disk mapping
1) Confirm disk mapping and continue 'rear recover'
2) Edit disk mapping (/var/lib/rear/layout/disk_mappings)
3) Use Relax-and-Recover shell and return back to here
4) Abort 'rear recover'
(default '1' timeout 300 seconds)
User confirmed disk mapping
Confirm or edit the disk layout file
1) Confirm disk layout and continue 'rear recover'
2) Edit disk layout (/var/lib/rear/layout/disklayout.conf)
3) View disk layout (/var/lib/rear/layout/disklayout.conf)
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)
User confirmed disk layout file
Partition primary on /dev/sda: size reduced to fit on disk.
Confirm or edit the disk recreation script
1) Confirm disk recreation script and continue 'rear recover'
2) Edit disk recreation script (/var/lib/rear/layout/diskrestore.sh)
3) View 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)
User confirmed disk recreation script
Start system layout restoration.
...
jsmeix commented at 2017-11-14 14:57:¶
I have a question to all ReaR maintainers:
Can one of you perhaps explain to me what
the reason is for the unexpected behaviour in
https://github.com/jsmeix/rear/blob/e5d7f694212912d958168ec1238ed1bae25a50d2/usr/share/rear/layout/recreate/default/200_run_layout_code.sh
why code like
( source $LAYOUT_CODE ) && break
does not work because it seems this way
the 'set -e' inside LAYOUT_CODE does no longer work
so that then LAYOUT_CODE would no longer exit
if a command therein exits with non-zero status.
In ReaR I must explicitly test $? as follows
( source $LAYOUT_CODE ) (( $? == 0 )) && break
so that the 'set -e' inside LAYOUT_CODE still makes it
exit if a command therein exits with non-zero status.
On plain command line such code works for me
# echo 'set -e ; cat qqq ; echo hello' >script.sh # ( source script.sh ) && echo ok || echo failed cat: qqq: No such file or directory failed # echo QQQ >qqq # ( source script.sh ) && echo ok || echo failed QQQ hello ok
but it seems same kind of code does not work within ReaR.
jsmeix commented at 2017-11-14 15:55:¶
I found the root cause of my question in
https://github.com/rear/rear/pull/1573#issuecomment-344284401
In ReaR it does not work because on my SLES12 test system
where I run ReaR there is "GNU bash, version 4.3.42"
while on my SLE11 workstation where I usually try out
commands there is "GNU bash, version 3.2.51" and in
https://github.com/rear/rear/pull/1573#issuecomment-344284401
I did the plain command line test with bash 3.x.
The bash version makes the difference here:
With bash 4.x it also does not work on plain command line:
# echo 'set -e ; cat qqq ; echo hello' >script.sh # ( source script.sh ) && echo ok || echo failed cat: qqq: No such file or directory hello ok # ( source script.sh ) ; (( $? == 0 )) && echo ok || echo failed cat: qqq: No such file or directory failed
jsmeix commented at 2017-11-15 13:30:¶
@gozora via
https://github.com/rear/rear/pull/1573/commits/7b15e5c3783c41d41dbf3c9fb735351633d51a6d
I completely overhauled the
layout/prepare/default/200_recreate_hpraid.sh
script and I would very much appreciate it
if you could have a general look at it
https://github.com/jsmeix/rear/blob/7b15e5c3783c41d41dbf3c9fb735351633d51a6d/usr/share/rear/layout/prepare/default/200_recreate_hpraid.sh
whether or not you see perhaps immediate mistakes.
Many thanks in advance!
gozora commented at 2017-11-15 16:10:¶
Hello @jsmeix
What I can tell you from top of my head.
grep -q '^cciss ' /proc/modules || return 0
cciss is no longer module to be used, HP(E) switched to hpsa
some time ago.
hpsa uses standard SCSI disk names for SmarArray logical disks
(/dev/sd[a-z] instead of /dev/cciss/...) so I'm not sure if whole code
in 200_recreate_hpraid.sh will work on modern systems ...
Unfortunately I don't have access to any HPE test HW right now, so I
can't really tell you whether recreation of SmartArray works or not
:-(
I'll however keep this in mind and as soon as I have an opportunity to
test it, I'll do so.
V.
gozora commented at 2017-11-15 16:23:¶
Topic of creating SmarArray (SA) from OS can be even more complicated due special branch of SA called HPE Dynamic Smart Array (cf. specification link) which is "kind of" smart array but can be used only in UEFI mode and uses different Linux driver hpdsa dependent on hpsa.
I actually never used ReaR feature for creating logical volumes during
restore process, but rather created them manually prior rear recover
V.
jsmeix commented at 2017-11-15 16:29:¶
I tried hard to not change what the code
in 200_recreate_hpraid.sh actually does.
I do not have such hardware so that I cannot
change what that code actually does.
I only changed (i.e. cleaned up) the syntax and
replaced the 'read' and 'select' calls by UserInput()
so that the new 200_recreate_hpraid.sh again
matches the new 200_run_layout_code.sh.
jsmeix commented at 2017-11-15 16:34:¶
Regarding
"cciss is no longer module to be used, HP(E) switched to hpsa"
I had noticed that in
http://cciss.sourceforge.net/
which reads
The cciss driver has been removed from RHEL7 and SLES12. If you really want cciss on RHEL7 checkout the elrepo directory. A new Smart Array driver called "hpsa" has been accepted into the main line linux kernel as of Dec 18, 2009, in linux-2.6.33-rc1. This new driver will support new Smart Array products going forward, and the cciss driver will eventually be deprecated.
Accordingly my hopefully non-behavioural changes
in 200_recreate_hpraid.sh are not of real importance
nowadays so that I can more easily merge it without
too much fear about possible regressions related to
CCISS HP Smart Array setups.
jsmeix commented at 2017-11-15 16:50:¶
@gozora
many thanks for your prompt review!
gozora commented at 2017-11-15 16:51:¶
@jsmeix anytime ;-)
jsmeix commented at 2017-11-15 17:17:¶
FWIW:
For me on my SLES12 test system the new stuff works really well.
[Export of Github issue for rear/rear.]