#638 Issue closed: Errors with Duply and Scientific Linux 7.1¶
Labels: support / question
jmp242 opened issue at 2015-08-18 13:33:¶
Trying to do
rear -v mkrescue
with latest version in EPEL (1.17.1) and I get these errors in the rear.log
Including prep/DUPLICITY/default/25_find_all_libs.sh
/usr/share/rear/prep/DUPLICITY/default/25_find_all_libs.sh: line 46:
21841 Segmentation fault LIBS=/lib/libexpat.so.1
/lib/libgcc_s-4.8.3-20140911.so.1 /lib/libgcc_s.so.1
/lib/libnss_dns-2.17.so /lib/libnss_dns.so.2 /lib/libnss_files-2.17.so
/lib/libnss_files.so.2 /lib/libresolv-2.17.so /lib/libresolv.so.2
/lib/x86_64-linux-gnu/libexpat.so.1 /lib64/libacl.so.1
/lib64/libassuan.so.0 /lib64/libattr.so.1 /lib64/libbz2.so.1
/lib64/libc.so.6 /lib64/libcap.so.2 /lib64/libcom_err.so.2
/lib64/libcrypto.so.10 /lib64/libdl.so.2
/lib64/libgcc_s-4.8.3-20140911.so.1 /lib64/libgcc_s.so.1
/lib64/libgcrypt.so.11 /lib64/libgpg-error.so.0
/lib64/libgssapi_krb5.so.2 /lib64/libk5crypto.so.3
/lib64/libkeyutils.so.1 /lib64/libkrb5.so.3 /lib64/libkrb5support.so.0
/lib64/liblzma.so.5 /lib64/libm.so.6 /lib64/libnss_dns-2.17.so
/lib64/libnss_dns.so /lib64/libnss_dns.so.2
/lib64/libnss_files-2.17.so /lib64/libnss_files.so
/lib64/libnss_files.so.2 /lib64/libpcre.so.1 /lib64/libpopt.so.0
/lib64/libpthread.so.0 /lib64/libpython2.7.so.1.0
/lib64/libreadline.so.6 /lib64/libresolv-2.17.so /lib64/libresolv.so
/lib64/libresolv.so.2 /lib64/librsync.so.2 /lib64/libselinux.so.1
/lib64/libssl.so.10 /lib64/libtinfo.so.5 /lib64/libutil.so.1
/lib64/libz.so.1 /lib64/rsyslog/imdiag.so /lib64/rsyslog/imfile.so
/lib64/rsyslog/imjournal.so /lib64/rsyslog/imklog.so
/lib64/rsyslog/immark.so /lib64/rsyslog/impstats.so
/lib64/rsyslog/imptcp.so /lib64/rsyslog/imtcp.so
/lib64/rsyslog/imudp.so /lib64/rsyslog/imuxsock.so
/lib64/rsyslog/lmnet.so /lib64/rsyslog/lmnetstrms.so
/lib64/rsyslog/lmnsd_ptcp.so /lib64/rsyslog/lmregexp.so
/lib64/rsyslog/lmstrmsrv.so /lib64/rsyslog/lmtcpclt.so
/lib64/rsyslog/lmtcpsrv.so /lib64/rsyslog/lmzlibw.so
/lib64/rsyslog/mmanon.so /lib64/rsyslog/mmjsonparse.so
/lib64/rsyslog/omjournal.so /lib64/rsyslog/ommail.so
/lib64/rsyslog/omprog.so /lib64/rsyslog/omruleset.so
/lib64/rsyslog/omstdout.so /lib64/rsyslog/omtesting.so
/lib64/rsyslog/omuxsock.so /lib64/rsyslog/pmaixforwardedfrom.so
/lib64/rsyslog/pmcisconames.so /lib64/rsyslog/pmlastmsg.so
/lib64/rsyslog/pmrfc3164sd.so /lib64/rsyslog/pmsnare.so /usr/lib/cruft
/usr/lib/librsync.so.1.0.2 /usr/lib64/libexpat.so.1
/usr/lib64/librsync.so.1
/usr/lib64/python2.7/lib-dynload/_bisectmodule.so
/usr/lib64/python2.7/lib-dynload/_collectionsmodule.so
/usr/lib64/python2.7/lib-dynload/_functoolsmodule.so
/usr/lib64/python2.7/lib-dynload/_hashlib.so
/usr/lib64/python2.7/lib-dynload/_heapq.so
/usr/lib64/python2.7/lib-dynload/_io.so
/usr/lib64/python2.7/lib-dynload/_localemodule.so
/usr/lib64/python2.7/lib-dynload/_randommodule.so
/usr/lib64/python2.7/lib-dynload/_socketmodule.so
/usr/lib64/python2.7/lib-dynload/_ssl.so
/usr/lib64/python2.7/lib-dynload/_struct.so
/usr/lib64/python2.7/lib-dynload/arraymodule.so
/usr/lib64/python2.7/lib-dynload/binascii.so
/usr/lib64/python2.7/lib-dynload/cStringIO.so
/usr/lib64/python2.7/lib-dynload/datetime.so
/usr/lib64/python2.7/lib-dynload/fcntlmodule.so
/usr/lib64/python2.7/lib-dynload/grpmodule.so
/usr/lib64/python2.7/lib-dynload/itertoolsmodule.so
/usr/lib64/python2.7/lib-dynload/math.so
/usr/lib64/python2.7/lib-dynload/operator.so
/usr/lib64/python2.7/lib-dynload/resource.so
/usr/lib64/python2.7/lib-dynload/selectmodule.so
/usr/lib64/python2.7/lib-dynload/stropmodule.so
/usr/lib64/python2.7/lib-dynload/termios.so
/usr/lib64/python2.7/lib-dynload/timemodule.so
/usr/lib64/python2.7/lib-dynload/zlibmodule.so
/usr/lib64/python2.7/site-packages/duplicity/_librsync.so
/usr/lib64/rsyslog/imdiag.so /usr/lib64/rsyslog/imfile.so
/usr/lib64/rsyslog/imjournal.so /usr/lib64/rsyslog/imklog.so
/usr/lib64/rsyslog/immark.so /usr/lib64/rsyslog/impstats.so
/usr/lib64/rsyslog/imptcp.so /usr/lib64/rsyslog/imtcp.so
/usr/lib64/rsyslog/imudp.so /usr/lib64/rsyslog/imuxsock.so
/usr/lib64/rsyslog/lmnet.so /usr/lib64/rsyslog/lmnetstrms.so
/usr/lib64/rsyslog/lmnsd_ptcp.so /usr/lib64/rsyslog/lmregexp.so
/usr/lib64/rsyslog/lmstrmsrv.so /usr/lib64/rsyslog/lmtcpclt.so
/usr/lib64/rsyslog/lmtcpsrv.so /usr/lib64/rsyslog/lmzlibw.so
/usr/lib64/rsyslog/mmanon.so /usr/lib64/rsyslog/mmjsonparse.so
/usr/lib64/rsyslog/omjournal.so /usr/lib64/rsyslog/ommail.so
/usr/lib64/rsyslog/omprog.so /usr/lib64/rsyslog/omruleset.so
/usr/lib64/rsyslog/omstdout.so /usr/lib64/rsyslog/omtesting.so
/usr/lib64/rsyslog/omuxsock.so
/usr/lib64/rsyslog/pmaixforwardedfrom.so
/usr/lib64/rsyslog/pmcisconames.so /usr/lib64/rsyslog/pmlastmsg.so
/usr/lib64/rsyslog/pmrfc3164sd.so /usr/lib64/rsyslog/pmsnare.so
/usr/share/rear/prep/DUPLICITY/default/25_find_all_libs.sh: line 49:
/etc/dracut.conf: Permission denied
When I then try and do a restore from the created ISO onto a smaller
SSD, though it is big enough for the partitions and data I have in the
backup, I get to:
could not find directory /boot/grub
Backups seem to succeed, but can't get anywhere with restores, nor can I
stop the issue on mkrescue.
gdha commented at 2015-08-18 14:10:¶
@jmp242 what did you define in the local.conf file?
jmp242 commented at 2015-08-18 14:15:¶
Here is the current content for my latest test.
Default is to create Relax-and-Recover rescue media as ISO image¶
set OUTPUT to change that¶
set BACKUP to activate an automated (backup and) restore of your data¶
Possible configuration values can be found in¶
/usr/share/rear/conf/default.conf
This file (local.conf) is intended for manual configuration. For¶
configuration
through packages and other automated means we recommend creating a new¶
file named site.conf next to this file and to leave the local.conf as¶
it is.
Our packages will never ship with a site.conf.¶
BACKUP=DUPLICITY
OUTPUT=ISO
BACKUP_URL="file:///run/media/jmp242/9ae976d7-2c18-4c37-b2c7-3eea2dcc35d0/"
DUPLY_PROFILE="local"
Previously I was doing:
Default is to create Relax-and-Recover rescue media as ISO image¶
set OUTPUT to change that¶
set BACKUP to activate an automated (backup and) restore of your data¶
Possible configuration values can be found in¶
/usr/share/rear/conf/default.conf
This file (local.conf) is intended for manual configuration. For¶
configuration
through packages and other automated means we recommend creating a new¶
file named site.conf next to this file and to leave the local.conf as¶
it is.
Our packages will never ship with a site.conf.¶
BACKUP=DUPLICITY
OUTPUT=ISO
BACKUP_URL="cifs://lnx121/windr"
BACKUP_OPTIONS="credentials=/root/.cifs"
DUPLY_PROFILE="standard"
COPY_AS_IS=( $COPY_AS_IS[@] /usr/sbin/mount.cifs
/usr/sbin/mount.ntfs
/usr/sbin/mount.ntfs-3g /usr/sbin/mount.ntfs-fuse )
where I was trying to store on the network, and maybe provide what I
needed to access the network in restore mode. Same errors though.
James Pulver
CLASSE Computer Group
Cornell University
On 08/18/2015 10:10 AM, gdha wrote:
@jmp242 https://github.com/jmp242 what did you define in the
|local.conf| file?—
Reply to this email directly or view it on GitHub
https://github.com/rear/rear/issues/638#issuecomment-132222422.
gdha commented at 2015-08-19 08:18:¶
@jmp242 When using BACKUP=DUPLICITY then the BACKUP_URL has no
meaning anymore as duplicity is an external backup mechanism which uses
its own transport mechanism (you can define it in /etc/rear/local.conf
- see the /usr/share/rear/conf/default.conf file section Extention
for DUPLICITY for the possibilities.
You cannot mix two backup methods in one go! You could have for example
2 local.conf files and use the -c config-file option with the rear
command to use a different config file then then default one.
However, I noticed that you got a segmentation fault which might indicate that something went wrong when traces the required libraries for duplicity (python script). That need some investigation.
jmp242 commented at 2015-08-19 12:04:¶
So how does ReaR know where to put the ISO file without the BACKUP_URL?
James Pulver
CLASSE Computer Group
Cornell University
On 08/19/2015 04:18 AM, gdha wrote:
@jmp242 https://github.com/jmp242 When using |BACKUP=DUPLICITY| then
the |BACKUP_URL| has no meaning anymore as duplicity is an external
backup mechanism which uses its own transport mechanism (you can
define it in |/etc/rear/local.conf| - see the
|/usr/share/rear/conf/default.conf| file section /Extention for
DUPLICITY/ for the possibilities.
You cannot mix two backup methods in one go! You could have for
example 2 local.conf files and use the |-c config-file| option with
the |rear| command to use a different config file then then default one.However, I noticed that you got a segmentation fault which might
indicate that something went wrong when traces the required libraries
for duplicity (python script). That need some investigation.—
Reply to this email directly or view it on GitHub
https://github.com/rear/rear/issues/638#issuecomment-132487746.
gdha commented at 2015-08-19 13:33:¶
@jmp242 OUTPUT_URL is your friend for ISO destination
gdha commented at 2015-08-19 18:33:¶
@jmp242 also noticed the following:
COPY_AS_IS=( $COPY_AS_IS[@] /usr/sbin/mount.cifs /usr/sbin/mount.ntfs /usr/sbin/mount.ntfs-3g /usr/sbin/mount.ntfs-fuse )
be aware that $COPY_AS_IS[@] should be corrected into
${COPY_AS_IS[@]} which is the correct syntax for an array output.
jmp242 commented at 2015-08-19 18:52:¶
I did get this on the mailing list. I swear I copied that from the
net,
but it apparently is wrong. I have now fixed that. I've also done some
more tests with duplicity / duply and I think the failure to find grub
is a bit misleading, it seems like just prior to that the restore
fails
with 'code 30' which I haven't been able to find out what exactly it
means, but I wonder if it's an error mounting the remote drive due to
not running pre command, which is:
mount -t cifs //lnx121/windr /tmp/backup -o
username=user,password=secret,mapchars
I added to the COPY_AS_IS the /etc/duply/standard/pre and
/etc/duply/standard/post and that didn't help either. I also still
have
the mount.cifs in there. Maybe it all goes back to the segfault making
the ISO?
Using
BACKUP=NETFS
BACKUP_TYPE=incremental
works, including accessing the cifs filesystem, but the incremental
backup and selection doesn't work (or I'm not sure how to make it work).
I'm happy to help debug, but I think I've tried all the config things
I
can at this point.
James Pulver
CLASSE Computer Group
Cornell University
On 08/19/2015 02:33 PM, gdha wrote:
@jmp242 https://github.com/jmp242 also noticed the following:
|COPY_AS_IS=( $COPY_AS_IS[@] /usr/sbin/mount.cifs /usr/sbin/mount.ntfs
/usr/sbin/mount.ntfs-3g /usr/sbin/mount.ntfs-fuse )|
be aware that |$COPY_AS_IS[@]| should be corrected into
|${COPY_AS_IS[@]}| which is the correct syntax for an array output.—
Reply to this email directly or view it on GitHub
https://github.com/rear/rear/issues/638#issuecomment-132734606.
schlomo commented at 2015-08-20 06:14:¶
BTW, I was just wondering why you had to add so much config for the CIFS
use case. IIRC that should happen automatically once you set
BACKUP_URL=cifs://...
See https://github.com/rear/rear/blob/master/doc/user-guide/03-configuration.adoc for an example.
jmp242 commented at 2015-08-21 12:03:¶
I think it was related to duply not working for me with rsync, so I
tried file based as suggested in their docs where I handle the mount
in
the pre command. Not specifically a ReaR issue there, that's Dulpy,
it's
just that it seems to cause an issue on restore from the ReaR boot
disk.
I'm thinking about testing with ssh to see if it could be related, but
the build and restore would be the same no matter the backup method in
the Duply profile in terms of the segfault trying to copy over Duply /
Duplicity to the ReaR restore CD right?
James Pulver
CLASSE Computer Group
Cornell University
On 08/20/2015 02:14 AM, Schlomo Schapiro wrote:
BTW, I was just wondering why you had to add so much config for the
CIFS use case. IIRC that should happen automatically once you set
|BACKUP_URL=cifs://...|See
https://github.com/rear/rear/blob/master/doc/user-guide/03-configuration.adoc
for an example.—
Reply to this email directly or view it on GitHub
https://github.com/rear/rear/issues/638#issuecomment-132903575.
gdha commented at 2015-08-21 12:25:¶
I wonder if this is related to #642 ?
jmp242 commented at 2015-08-21 12:34:¶
Not sure... I wasn't using rsync directly, only using inside of duply,
and currently (in generating the errors) using a file:/// backed by a
mounted CIFS directory. Although, if you mean that duply in general is
crashing because of getting an unexpected restore flag, then that
could
be what's going on.
James Pulver
CLASSE Computer Group
Cornell University
On 08/21/2015 08:25 AM, gdha wrote:
I wonder if this is related to #642
https://github.com/rear/rear/issues/642 ?—
Reply to this email directly or view it on GitHub
https://github.com/rear/rear/issues/638#issuecomment-133409228.
gdha commented at 2015-08-28 12:53:¶
@jmp242 I have done several tests with DUPLICITY and I don't see any segmentation faults. Allbeit I've enhanced the code a bit. To be released in 1.17.2
jmp242 commented at 2015-08-28 13:16:¶
I'm not sure what's special about my set-up. I have had NETFS work
perfectly including a restore. I then just used duply to do a second
restore from the incremental backups and that worked pretty well for
me.
So I have a workaround.
James Pulver
CLASSE Computer Group
Cornell University
On 08/28/2015 08:53 AM, gdha wrote:
@jmp242 https://github.com/jmp242 I have done several tests with
DUPLICITY and I don't see any segmentation faults. Allbeit I've
enhanced the code a bit. To be released in 1.17.2—
Reply to this email directly or view it on GitHub
https://github.com/rear/rear/issues/638#issuecomment-135767063.
gdha commented at 2015-10-02 15:04:¶
@jmp242 do you require support from us for something that is still unclear?
[Export of Github issue for rear/rear.]