Version 2.2.7 Failing due to Mindi Failing to Create boot+data disks

[kaplan71]

Hi there --

I have version 2.2.7 running on a Fedora Core 2 system, and I am trying to do an NFS backup to a remote system. The command syntax that I enter to accomplish this task is the following:

/usr/sbin/mondoarchive -9 -N -O -s 650m -p mondorescue -n rorecovery.mgh.harvard.edu:/rtp4

The initial creation of the catalog appears to work without a problem. However, the following error message appears shortly thereafter:

Your backup will occupy one meeeeellion media! (maybe 14)
Done.
Copying Mondo's core files to the scratch directory
Done.
Calling MINDI to create boot+data disks
Your boot loader is GRUB and it boots from /dev/sda
Waiting for external binary to start
Mindi failed to create your boot+data disks.
Fatal error... Failed to generate boot+data disks
---FATALERROR--- Failed to generate boot+data disks
If you require technical support, please contact the mailing list.
See http://www.mondorescue.org for details.
The list's members can help you, if you attach that file to your e-mail.
Log file: /var/log/mondoarchive.log
FYI, I have gzipped the log and saved it to /var/cache/mondo/MA.log.gz.
Mondo has aborted.
Execution run ended; result=254
Type 'less /var/log/mondoarchive.log' to see the output log
======= 11/11/08 11:20:56  END make_net_recovery Session

As far as I know, version 2.2.7 does not use the -F option, so there should not be any reason for boot+data media to be created. Does anyone have any idea as to what the cause for this is, and how it can be corrected? Thanks.

[kaplan71]

Most recent mondoarchive.log file

[Bruno Cornec]

The error is: FATAL ERROR. Cannot copy /sbin/../usr/bin/smbmount to mondo.tmp.UDCmt4/bigdir - did you run out of disk space?

So could you check that you have enough room on / to host the temp files, or use options -S/-T to redirect their creation to where you have more room.

[kaplan71]

Hi there --

The workstation in question has 8.4 gigabytes available out of a total amount of thirty gigabytes on the hard drive. When I ran the mondoarchive binary, I monitored the amount of used space on the root filesystem, and until the problem occurred, the percent of space used never went above seventy-three percent. Listed below is the output of the df -hl command on the system in question:

Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/Volume00-LogVol00
                       30G   20G  8.4G  71% /
/dev/sda1              99M   11M   83M  12% /boot
none                  2.0G     0  2.0G   0% /dev/shm

If I was to use the -S/-T options, would it be possible to create the scratch and temporary directories on the destination system? Thanks.

[Bruno Cornec]

Replying to kaplan71:

The workstation in question has 8.4 gigabytes available out of a total amount of thirty gigabytes on the hard drive. When I ran the mondoarchive binary, I monitored the amount of used space on the root filesystem, and until the problem occurred, the percent of space used never went above seventy-three percent. Listed below is the output of the df -hl command on the system in question:

Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/Volume00-LogVol00
                       30G   20G  8.4G  71% /
/dev/sda1              99M   11M   83M  12% /boot
none                  2.0G     0  2.0G   0% /dev/shm

Ok. Could you also check the result of df -i please ? Now it could be that it can't create enough files on the VFAT boot partition it has created. To be sure of that a monitoring of df with watch during the run would be great.

If I was to use the -S/-T options, would it be possible to create the scratch and temporary directories on the destination system? Thanks.

Yes. Where you want. It may be a bit slower through the network however.

[kaplan71]

Hi there --

Per your request listed below is the output of df -i along with the df -hl commands on the workstation in question. NOTE: These were taken at the point of failure during the running of mondoarchive:

[root@rtp4 root]# df -hli && df -hl
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/mapper/Volume00-LogVol00
                        3.8M    355K    3.4M   10% /
/dev/sda1                26K      38     26K    1% /boot
none                    214K       1    214K    1% /dev/shm
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/Volume00-LogVol00
                       30G   20G  8.4G  71% /
/dev/sda1              99M   11M   83M  12% /boot
none                  2.0G     0  2.0G   0% /dev/shm

The output shown below is that of the destination server taken at the same point of failure:

[ahk@rorecovery ~]$ df -hli && df -hl
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/mapper/VolGroup00-LogVol00
                         17M    793K     16M    5% /
/dev/sda3                26K      32     26K    1% /boot
tmpfs                   215K       1    215K    1% /dev/shm
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                      130G   43G   87G  33% /
/dev/sda3              99M   12M   82M  13% /boot
tmpfs                 1.7G     0  1.7G   0% /dev/shm

I haven't tried the -S/-T options yet, but I'll try to implement them if all else fails.

[marcopugge]

the version of tar used by your distribution is not able to follow a simlink containing a '..'

there is an entry in the faq related to this problem: http://trac.mondorescue.org/wiki/FAQ#Q33WhydoesntmindiworkwithRHAS2.1RHEL3orRedHat9 I suggest you to check the file $MINDI_CONF/deplist.txt (usually /etc/mindi/deplist.txt) to see which are the affected files, and then follow the instruction in the FAQ to recreate all the simlinks with an absolute path