#1151 Issue closed: ReaR fails weirdly when an incompatible 'uname' replacement is used¶
Labels: support / question, fixed / solved / done,
not ReaR / invalid
dakoide opened issue at 2017-01-04 15:10:¶
Relax-and-Recover (rear) Issue Template¶
Please fill in the following items before submitting a new issue (quick response is not guaranteed with free support):
- rear version (/usr/sbin/rear -V): Relax-and-Recover 1.17.2 / Git
- OS version (cat /etc/rear/os.conf or lsb_release -a):
Distributor ID: Debian
Description: Debian GNU/Linux 7.7 (wheezy)
Release: 7.7
Codename: wheezy - rear configuration files (cat /etc/rear/site.conf or cat
/etc/rear/local.conf):
OUTPUT_URL=nfs://172.30.125.45/backup/ISO_BMR/LINUX
BACKUP=BACULA - Brief description of the issue
2017-01-04 15:01:36 ERROR: BUG BUG BUG! ROOTFS_DIR '/tmp/rear.yqZ12HCum2JIqNE/rootfs' is broken, chroot bash test failed. === Issue report === Please report this unexpected issue at: https://github.com/rear/rear/issues Also include the relevant bits from /var/log/rear/rear-s3pac-lta2.log HINT: If you can reproduce the issue, try using the -d or -D option ! ==================== === Stack trace === Trace 0: /usr/sbin/rear:251 main Trace 1: /usr/share/rear/lib/mkrescue-workflow.sh:31 WORKFLOW_mkrescue Trace 2: /usr/share/rear/lib/framework-functions.sh:70 SourceStage Trace 3: /usr/share/rear/lib/framework-functions.sh:31 Source Trace 4: /usr/share/rear/build/default/98_verify_rootfs.sh:17 source Trace 5: /usr/share/rear/lib/_input-output-functions.sh:144 BugError Message: BUG BUG BUG! ROOTFS_DIR '/tmp/rear.yqZ12HCum2JIqNE/rootfs' is broken, chroot bash test failed.
- Work-around, if any
jsmeix commented at 2017-01-04 15:44:¶
And what are the relevant bits from your
/var/log/rear/rear-s3pac-lta2.log
when you reproduce it using the -d or -D option?
The "chroot bash test failed" comes from
usr/share/rear/build/default/980_verify_rootfs.sh
therein from that code:
# The chroot bash test ensures that we have a working bash on our rescue image
if ! chroot $ROOTFS_DIR bash -c true ; then
KEEP_BUILD_DIR=1
BugError "ROOTFS_DIR '$ROOTFS_DIR' is broken, chroot bash test failed."
fi
Accordingly the relevant bits from your
/var/log/rear/rear-s3pac-lta2.log
are the debug output messages while the
usr/share/rear/build/default/980_verify_rootfs.sh
script runs.
dakoide commented at 2017-01-04 15:55:¶
this is log file after command:
rear -D mkrescue
rear-s3pac-lta2.txt
and The command is blocked nothing else does this happen
gozora commented at 2017-01-04 20:30:¶
Hello @dakoide,
I can only guess what is wrong here, but my assumptions might help
someone.
I went through your log and found indeed some interesting entries:
/usr/share/rear/lib/layout-functions.sh: line 80: $LAYOUT_DEPS: ambiguous redirect
++ :
/usr/share/rear/lib/layout-functions.sh: line 84: $LAYOUT_TODO: ambiguous redirect
++ local type dev remainder name disk disks vgrp dm_vgrp lvol dm_lvol part mp fs bd nmp temp_nm
++ read type remainder
+++ cat
Lets start from the end. cat you see as last output originates from
layout-functions.sh and it looks like:
while while read type remainder ; do
...
done < <(cat $LAYOUT_FILE)
You got ReaR hanging (most probably) because $LAYOUT_FILE is not set.
It is similar with ambiguous redirect message, as bash will throw
ambiguous redirect (among other) when target for redirection does not
exist.
To summarize, you are heaving all these trouble because $LAYOUT_DEPS,
$LAYOUT_TODO and $LAYOUT_FILE were not set.
Normally these variables should be set by script layout/save/GNU/Linux/10_create_layout_file.sh, in your case however, I don't see any script from GNU/Linux section being launched and that will be a problem I guess.
Unfortunately, this launching mechanism of ReaR is a bit mystery for me, but I'm sure @gdha or @jsmeix will know exactly why your copy of ReaR skips GNU/Linux section.
Just a Hail marry shot, but do you have lsb package installed on your wheezy ?
root@debian:/etc/rear# dpkg -l | grep lsb
ii lsb-base 4.1+Debian13+nmu1 all Linux Standard Base 4.1 init script functionality
ii lsb-release 4.1+Debian13+nmu1 all Linux Standard Base version reporting utility
V.
jsmeix commented at 2017-01-05 10:36:¶
@gozora
your analysis of the user's
https://github.com/rear/rear/files/685137/rear-s3pac-lta2.txt
is right.
The usrer's
https://github.com/rear/rear/files/685137/rear-s3pac-lta2.txt
fails at
+ . /usr/share/rear/layout/save/default/30_list_dependencies.sh ++ generate_layout_dependencies ++ : /usr/share/rear/lib/layout-functions.sh: line 80: $LAYOUT_DEPS: ambiguous redirect ++ : /usr/share/rear/lib/layout-functions.sh: line 84: $LAYOUT_TODO: ambiguous redirect
and the matching code is in
usr/share/rear/lib/layout-functions.sh
: > $LAYOUT_DEPS
...
: > $LAYOUT_TODO
that are apparently called with empty LAYOUT_DEPS
and LAYOUT_TODO variables regardless that normally
those variables have been set before in
usr/share/rear/layout/save/GNU/Linux/100_create_layout_file.sh
as
LAYOUT_DEPS=/root/rear/var/lib/rear/layout/diskdeps.conf LAYOUT_TODO=/root/rear/var/lib/rear/layout/disktodo.conf
but in the user's
https://github.com/rear/rear/files/685137/rear-s3pac-lta2.txt
usr/share/rear/layout/save/GNU/Linux/100_create_layout_file.sh
is not sourced.
I have no idea why
usr/share/rear/layout/save/GNU/Linux/100_create_layout_file.sh
is not sourced for this particular user.
My blind guess is that the ReaR installation
of this particular user is broken.
I.e. I think this is not a bug in ReaR itself.
@dakoide
I would recommend to re-install ReaR to ensure
all its files are there as expected.
If you like I would even recommend to use the
current newest ReaR Github code as follows:
How to test the currently newest rear GitHub master code:
Basically "git clone" it into a directory and
then run rear from within that directory like:
# git clone https://github.com/rear/rear.git # cd rear # vi etc/rear/local.conf # usr/sbin/rear -d -D mkbackup
@dakoide
better use both '-d' and '-D' to get full logging, e.g.:
rear -d -D mkbackup and rear -d -D recover
In general regarding ReaR you may also have a look at
https://en.opensuse.org/SDB:Disaster_Recovery
Regardless that it is about SUSE, the information therein
about ReaR applies in general.
gozora commented at 2017-01-05 10:41:¶
Again I'm not sure here, but ReaR should launch GNU/Linux part if
uname -o returns corresponding string.
@dakoide can you please check what uname -o shows on your system?
jsmeix commented at 2017-01-05 10:57:¶
@gozora
many thanks for your help!
I had that OS_* variables magic forgotten.
@dakoide
to debug OS_* variables magic in addition to
report what "uname -o" shows on your system
also change in your usr/sbin/rear the line
SetOSVendorAndVersion
to
set -x SetOSVendorAndVersion exit
and re-run "usr/sbin/rear -d -D mkrescue"
and provide the log file.
jsmeix commented at 2017-01-05 11:02:¶
@gozora
only a guess but I have the dim feeling this issue
may become another nice example how badly things fail
in a totally unexpected way at a totally weird place
when scripts are not run with "set -e -u -o pipefail",
cf. "Try to care about possible errors" at
https://github.com/rear/rear/wiki/Coding-Style
and
https://github.com/rear/rear/issues/700
dakoide commented at 2017-01-05 15:20:¶
hi thx to gozora and jsmeix ,
i change the line and look the attach file
rear-s3pac-lta2.txt
the command uname -o return nothing
gozora commented at 2017-01-05 15:36:¶
That is really interesting. What about uname -a ?
dakoide commented at 2017-01-05 15:48:¶
uname -a : nothing
uname -s : Linux
uname -r : 3.0.0-4-amd64
uname -m : x86_64
dakoide commented at 2017-01-05 15:53:¶
I just had an information: for an application to work on this server there has been modification of /bin/uname ,The problem may come from there
Here is what has been done
mv /bin/uname /bin/uname-OLD
cat<
#!/bin/bash
case $1 in
"-r") echo "3.0.0-4-amd64";;
"-s") echo "Linux";;
"-m") echo "x86_64";;
"*") echo "Linux";;
esac
if [ "$1" == "" ]
then
echo "Linux"
fi
EOF
chmod +x /bin/uname
gozora commented at 2017-01-05 16:12:¶
Outch!
That is not very fortunate solution!
Anyhow, I bet that if you revert your changes back (or replace all
uname occurrence in ReaR with uname-OLD) all should be working fine.
V.
dakoide commented at 2017-01-05 16:38:¶
where ? in /usr/sbin/rear the command is uname -n , i change the line for uname-OLD -n but it is the same .
gozora commented at 2017-01-05 16:46:¶
nope, that is only start ;-)
Here are all occurrences of uname with corresponding line numbers in
current rear code:
usr/share/rear/skel/default/etc/scripts/system-status.sh:8:echo "I am $(uname -a)"
usr/share/rear/skel/default/etc/scripts/boot:41:echo Hostname set to $(uname -n)
usr/share/rear/skel/default/etc/scripts/system-setup.d/40-start-udev-or-load-modules.sh:69: for module in $( find /lib/modules/$(uname -r)/kernel/drivers/{scsi,block,ide,message,ata} -type f 2>/dev/null ) ; do
usr/share/rear/output/USB/Linux-i386/300_create_extlinux.sh:112:Relax-and-Recover v$VERSION - $usb_label_workflow using kernel $(uname -r) ${IPADDR:+on $IPADDR}
usr/share/rear/output/USB/Linux-i386/300_create_extlinux.sh:122:Relax-and-Recover v$VERSION - $usb_label_workflow using kernel $(uname -r) ${IPADDR:+on $IPADDR}
usr/share/rear/output/USB/Linux-i386/300_create_extlinux.sh:371: if [ -r "/lib/modules/$(uname -r)/modules.pcimap" ]; then
usr/share/rear/restore/GALAXY/default/400_restore_with_galaxy.sh:18: SHORTHOST="$(uname -n)"
usr/share/rear/conf/default.conf:61:KERNEL_VERSION="${KERNEL_VERSION:-$( uname -r )}"
usr/share/rear/conf/default.conf:77:REAL_MACHINE="$( uname -m )"
usr/share/rear/conf/default.conf:89:ARCH="$( uname -s )-$MACHINE" 2>>/dev/null
usr/share/rear/conf/default.conf:90:REAL_ARCH="$( uname -s )-$REAL_MACHINE" 2>>/dev/null
usr/share/rear/conf/default.conf:93:HOSTNAME="$( hostname -s 2>/dev/null || uname -n | cut -d. -f1 )"
usr/share/rear/conf/default.conf:100:OS="$( uname -o )"
usr/share/rear/conf/GNU/Linux.conf:62:uname
usr/sbin/rear:484:Host $( uname -n ) using Backup $BACKUP and Output $OUTPUT
dakoide commented at 2017-01-05 16:52:¶
ok thx gozora I would test tomorrow morning .
gozora commented at 2017-01-05 16:53:¶
Or maybe one dirty hack.
Try to edit just your /usr/sbin/rear and add somewhere to beginning of the file following lines:
shopt -s expand_aliases
alias uname=uname-OLD
dakoide commented at 2017-01-06 09:39:¶
hi gozora,
Your little manipulation works, I add the alias in /usr/sbin/rear and it
works thank you for your help.
dakoide commented at 2017-01-06 09:41:¶
Thanks to everyone for your help i close
dakoide commented at 2017-01-06 10:34:¶
hi gozora,
Your little manipulation works, I add the alias in /usr/sbin/rear and
it
works thank you for your help.
2017-01-05 17:53 GMT+01:00 Vladimir Gozora notifications@github.com:
Or maybe one dirty hack.
Try to edit just your /usr/sbin/rear and add somewhere to beginning of
the file following lines:shopt -s expand_aliases
alias uname=uname-OLD—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rear/rear/issues/1151#issuecomment-270694991, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ARt5IiDtzmTWb3VfQuqSrJFgT4BtAFY1ks5rPSAFgaJpZM4Lat5y
.
--
Babar pour les intimes.
Dans le doute abstient toi (et c'est vrai pour toutes les situations)
jsmeix commented at 2017-01-09 08:28:¶
The root cause os not in ReaR but an incompatible
modified standard program (uname).
Accordingly the issue is invalid for Rear.
But by design ReaR is made of pure bash scripts
so that appropriate adaptions can be relatively easily done
in ReaR to make it work even under non-standard conditions.
@gozora
many thanks for your very useful help here!
jsmeix commented at 2017-01-09 08:42:¶
Regarding the hack in
https://github.com/rear/rear/issues/1151#issuecomment-270694991
In usr/sbin/rear the uname command is called after
the config files have been read.
Because all of ReaR is bash scripts also the config files
are sourced and executed as bash scripts, cf.
"Character encoding" at
https://github.com/rear/rear/wiki/Coding-Style
so that it should also work to have in etc/rear/local.conf
shopt -s expand_aliases alias uname=uname-OLD
or whatever more elaborated workaround is needed like
if system_uname="$( type -P uname-OLD )" ; then
shopt -s expand_aliases
alias uname=$system_uname
fi
[Export of Github issue for rear/rear.]