#25 Issue `closed`: mkbackup fails¶

Labels: waiting for info, support / question

dagwieers opened issue at 2012-03-28 11:43:¶

Bug reported by irvined at SF#3263766

Original report¶

This is for version 1.10.0 running on Ubuntu 10.04 64 bit Linux #55-Ubuntu SMP Mon Jan 10 23:57:16 UTC 2011 x86_64 GNU/Linux

sudo rear mkbackup gives:

Relax & Recover Version 1.10.0 / 2011-02-20
The preparation phase OK
ERROR: Could not guess physical device for '/dev/mapper/s11--vm--app--22-root' [251:0] in '/sys/block/dm-0/dev'.
This is probably a bug in your kernel or in Relax & Recover, so please file a bug report about this.

This is running on a VMware virtual machine with disks provided by IBM XIV SAN

Aditional notes¶

I have tried the latest svn code an mkbackup now works for me.

When I try to boot from the generated .iso file I get a error while loading shared libraries: libpthread.so.0 wrong ELF class ELFCLASS32e Then kernel panic

Looking at the library files in the /tmp/rear.xxxx/rootfs/lib directory

libpthread.so.0: symbolic link to `libpthread-2.11.1.so'
libpthread-2.11.1.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped

Whereas in the running filesystem

/lib/libpthread-2.11.1.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped

Does this mean that the .iso has been created using the 32bit library instead of the 64 bit?

dagwieers commented at 2012-03-28 11:44:¶

Comment by schlomoschapiro¶

we have seen similar reports from 64bit systems where /lib contained 64bit stuff and /lib32 contained 32bit stuff. But so far I have heard about that only in the context of Debian, not Ubuntu.

I would advice that you find out how your system handles 64bit and 32bit libraries and see if ReaR understands that and puts them in the correct place, see also the use of LIBS and LIBS64 in ReaR.

Without a test system to take a look at I won't be able to help you beyond such general advice.

Sorry,
Schlomo

dagwieers commented at 2012-03-28 11:47:¶

Please test a recent (or master branch) for this issue and provide feedback relating to this bug as it is believed to have been fixed in the latest version.

I am closing this bug now, but do reopen this bug if it has not been fixed by recent improvements to the code.

[Export of Github issue for rear/rear.]

#25 Issue closed: mkbackup fails¶