System backup - Could not perform md5 checksum

Redevelopment

Redevelopment

Verified User
Joined
Dec 8, 2004
Messages
53
Location
The Netherlands
Hi all,

I'm sorry if this has been asked before, but I couldn't find a similar thread on the forums.

Here's the deal, when I try to perform a full system backup (locally), I get the following error:

Performing sanity checks: Completed
Checking load average: Completed
Checking free disk space: Completed
Performing Custom backup
Archiving /etc/exim.conf: Could not perform md5 checksum, aborting...
Performing cleanup operations: Completed

/etc/exim.conf is the very first file in line.
The weird thing about it is that even when I uncheck /etc/exim.conf it still gives me this error in the backup log using "View Last Backup Log".

User backups are running fine, but as soon as I try to perform a sysbackup I get this error.
Any ideas as to what could be causing this?

Thanks in advance.

Ruben.
 
Check your system to see if you can run md5sum from the command line.

If not, then you need to install md5sum.

Jeff
 
jlasman said:
Check your system to see if you can run md5sum from the command line.

If not, then you need to install md5sum.

Jeff
Click to expand...

Hi Jeff,

I checked it as root and admin, both users have /usr/bin in their path. /usr/bin is where the md5sum binary is located, so that cannot be the cause of this problem.
Any other ideas?

Ruben.
 
The backup is run as root.

So as root, from your root directory, try typing:

md5sum

and pressing <enter>.

What do you get?

Jeff
 
Hi Jeff,

I get the following:


thor:~# md5sum

thor:~# md5sum -h
usage: md5sum [-bv] [-c [file]] | [file...]
Generates or checks MD5 Message Digests
-c check message digests (default is generate)
-v verbose, print file names when checking
-b read files in binary mode
The input for -c should be the list of message digests and file names
that is printed on stdout by this program when it generates digests.
thor:~#


md5sum without any arguments returns nothing, but when I use the -h switch I get the helptext. So, the md5sum binary seems to work fine.
 
It does, and without studying how it's being called in your backup program and some testing, I'm not sure why it doesn't work :( .

Jeff
 
Yeah, pretty weird huh? I'll just keep playing around with it for a bit. If I really cannot resolve it, I'll contact support.
Thanks for the suggestions Jeff.

Ruben.
 
Update:
When I run the sysbk script manually, I get:

Performing Custom backup
Archiving /etc/exim.conf: chmod: getting attributes of `/home/admin/system_backup/04-13-06/custom/etc//exim.conf*': No such file or directory

Obviously the double slash when the script tries to chmod the file is the problem here, but I'm not sure where that gets done. I checked several files and my guess it's somewhere in internals.sysbk but I'm not sure where exactly.
Any help?
Thanks.

Ruben.
 
Have you tried to verify the file existence manually?

A double-slash // in Unix/Linux shouldn't matter; the system should read it as one slash.

Jeff
 
/home/admin/system_backup/04-13-06/custom/etc//exim.conf doesn't exist. The only thing sysbk does is creating and empty etc directory.
You're right about the double slashes, they don't make a difference.
Still not sure why it doesn't just copy the files then, because /etc/exim.conf sure does exist.
 
Hello,

What *is* getting created/copied then?
What is the contents of /home/admin/system_backup?
If it exists, the contents of the date directory (04-13-06)

Just a question, probably unrelated..
I don't know of any "checkbox" for exim.conf.. are you referring to the files list (bottom of interface)
when I uncheck /etc/exim.conf
Click to expand...
John
 
Hi John,

This is what's being created:

thor:/# cd ~admin/system_backup/
thor:/home/admin/system_backup# ls -l
total 4
drw-r----- 3 root root 4096 Apr 13 22:19 04-13-06
thor:/home/admin/system_backup# cd 04-13-06/
thor:/home/admin/system_backup/04-13-06# ls -l
total 4
drwxr-xr-x 3 root root 4096 Apr 13 22:19 custom
thor:/home/admin/system_backup/04-13-06# cd custom/
thor:/home/admin/system_backup/04-13-06/custom# ls -l
total 4
drwxr-x--- 2 root root 4096 Apr 13 22:19 etc
thor:/home/admin/system_backup/04-13-06/custom# cd etc
thor:/home/admin/system_backup/04-13-06/custom/etc# ls -l
total 0
thor:/home/admin/system_backup/04-13-06/custom/etc#


With the checkbox I was referring to the files list in DA indeed.

Ruben.

P.S. the output of sysbk -s:

thor:/usr/local/sysbk# ./sysbk -s
SysBK 1.0 [[email protected]]
Performing sanity checks: [ COMPLETED ]

Checking load average: [ COMPLETED ]

Checking free disk space: [ COMPLETED ]

Performing Custom backup
Archiving /etc/exim.conf: chmod: getting attributes of `/home/backup/04-16-06/custom/etc//exim.conf*': No such file or directory
[ FAILED ]

Could not perform md5 checksum, aborting...
Performing cleanup operations: [ COMPLETED ]

thor:/usr/local/sysbk#

In case I run it manually from the commandline like this the same directory structure is being created. The only difference is that it writes it to /home/backup instead of /home/admin/backup.

The error: Archiving /etc/exim.conf: chmod: getting attributes of `/home/backup/04-16-06/custom/etc//exim.conf*': No such file or directory

is perfectly valid, because exim.conf doesn't exist in the backup directory, but the question is why it isn't being copied.
It cannot be a rights issue:
thor:/etc# ls -l exim.conf
-rw-r--r-- 1 root root 40405 Apr 2 16:13 exim.conf
thor:/etc#

Besides that I run it as root from the commandline.
 
Last edited:
I found the problem by debugging sysbk.
What I did is this:
In internals.sysbk I removed the output redirection to /dev/null from the following commands:

line 192:
$NICE -n $PRI $ARC_PRI $BACKUP_PATH/$DATE/$DIR_PREFIX/$NAME$ARC_PRI_EXT $ARC_CONT >> /dev/null 2>&1

line 194:
$NICE -n $PRI $ARC_PRI $BACKUP_PATH/$DATE/$NAME$ARC_PRI_EXT $ARC_CONT >> /dev/null 2>&1

Then ran sysbk -s again to see the output.
The output showed that it was unable to find /bin/nice, which is obvious because on Debian nice is located in /usr/bin/nice.
I made a symlink in /bin and ran sysbk again. Problem solved.

However it is a bug in sysbk, because it does check for the OS in conf.sysbk to set the paths to several binaries:

if [ "$OS" = "FreeBSD" ]; then
MD5="/sbin/md5 -r"
GUNZIP="/usr/bin/gunzip"
NICE="/usr/bin/nice"
else
MD5="/usr/bin/md5sum" # Path to md5sum binary
GUNZIP="/bin/gunzip" # Path to 'gunzip' binary
NICE="/bin/nice" # Path to 'nice' binary
fi

As you can see in case of FreeBSD it does set NICE="/usr/bin/nice", but not in case of Debian as it should.

Ruben.
 
You must log in or register to reply here.
Back
Top