#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):
  • 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
when you reproduce it using the -d or -D option?

The "chroot bash test failed" comes from
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
        BugError "ROOTFS_DIR '$ROOTFS_DIR' is broken, chroot bash test failed."

Accordingly the relevant bits from your
are the debug output messages while the
script runs.

dakoide commented at 2017-01-04 15:55:

this is log file after command:
rear -D mkrescue

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


jsmeix commented at 2017-01-05 10:36:

your analysis of the user's
is right.

The usrer's
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

    : > $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


but in the user's
is not sourced.

I have no idea why
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.

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

better use both '-d' and '-D' to get full logging, e.g.:

rear -d -D mkbackup
rear -d -D recover

In general regarding ReaR you may also have a look at

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:

many thanks for your help!
I had that OS_* variables magic forgotten.

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



set -x

and re-run "usr/sbin/rear -d -D mkrescue"
and provide the log file.

jsmeix commented at 2017-01-05 11:02:

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
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

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/uname

case $1 in
"-r") echo "3.0.0-4-amd64";;
"-s") echo "Linux";;
"-m") echo "x86_64";;
"*") echo "Linux";;

if [ "$1" == "" ]


echo "Linux"



chmod +x /bin/uname

gozora commented at 2017-01-05 16:12:


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.


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/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

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.

many thanks for your very useful help here!

jsmeix commented at 2017-01-09 08:42:

Regarding the hack in

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
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

[Export of Github issue for rear/rear.]