{5} Assigned, Active Tickets by Owner (Full Description) (67 matches)

Ticket raised at the request of Bruno following a report in the mailing list.

Fortunately this happened on a test rig.

When mondorestore enters the countdown phase prior to repartitioning a disk it instructs the user that the process may be cancelled by the combination keystroke CTL-ALT-DEL. This does not work. This process continues and destroys the partition structure, then recreates it and applies a file system.

I think it is important that this feature should work as stated on the screen advice.

When trying to build an ISO image with mindi on Debian 8, it aborts.

When restoring on RHEL 7.3+, at reboot of the VM used to test, grub doesn't find it's boot partition, and thus doesn't boot the restored system.

for storing scratch and temporary data and both archive and boot images (see also Mondorescue wiki:StandardsCompliance)

reported by Yann Aubert (<technique_at_alixen.fr>):
many sprintf in mondo code are used without checks and may lead to seg. fault (ex: -E with a long list of excluded directories)

I'm running the currently latest release for debian amd64 from ftp.mondorescue.org. I'm running Debian stable. I have tried the version available in Debian stable repository, same/similar error.

When backing up to more than 1 tape, the backup runs nicely, but when it verifies, it stops, just after starting the new tape. I get the same error if I try to restore from tape 2.

I have an IBM LTO Ultrium 2 drive.

Hi,

I am using mondorescue for some time without any problems for backups and replication of local linux machines, thank you very much! However, now that the time has come to backup the laptop of my boss, problem appeared :(

I think I know what is causing it: I am trying to backup several partitions with the overall data size of approx. 80 GB to an NFS mount, but locally there is just 9 GB for scratch and tmp, and it seems that mondorescue wrongly checks if the partition on which tmp and scratch space are has enough space to store the whole amount of data that is being backed up.

Details: laptop has windows NTFS partition of 75 GB, and SuSE linux is installed on the rest of HDD, with 9 GB of empty space on Linux. Backup is done to an NFS mount. If windows partition is not backed up, no problems (i.e. small linux partition can be backed up successfully). If windows partition is included (-x /dev/sda2), I get "/dev/sda2: no such file" after I see in the log file that the number of slices is correctly calculated for /dev/sda2. This is misleading message and should be fixed (not enough space is more appropriate, although also not correct).

However, if I set scratch (-S) and tmp (-T) directory to be on the NFS mount (the same used for storing the backup iso images), then everything works, since on NFS mount there is enough space (200 GB+), wile on the local disk there is just 9 GB of free space. Of course, this is _very_ slow (15+ hours estimated), and in practice not feasible.

Now, I have verified that (with the size of iso images not specified, defaulting to CD size) tmp directory on NFS mount never grows over 150-170 MB, and scratch directory on NFS mount never over 650 MB (of course), which means that local scratch and tmp can be used easily, but for some reason mondorescue fails to realize that and gives up (this happens after backup of linux partitions is finished, at the start of the backup of windows partition as biggiefile).

Do you have any ideas how to easily fix this? Versions used:

mondo-2.2.4-1.suse10.2.i586.rpm mindi-busybox-1.2.2-3.suse10.2.i586.rpm mindi-1.2.4-1.suse10.2.i586.rpm

Thanks, Antun Balaz antun@…

As reported on mondo ML: ​http://sourceforge.net/mailarchive/forum.php?thread_name=1295604747763-2300816.post%40n3.nabble.com&forum_name=mondo-devel

In the mondorestore application under the "Storage Dir" form, the text entry for inputting the path to your ISO files seems to be limited to 51 characters. This is arrived via the following:

Run mondorestore select OK Select "Hard disk"

The form with the information:

Storage dir.

Please enter the full path name to the directory for your ISO images. Example: /mnt/raid0_0

is presented to the user, in the text input box I try to add a path greater than 51 characters and am not able to do so, The path gets truncated.

This is with version 2.2.4.

Best Regards, Bill

zeroconf (www.zeroconf.org) apparently adds an IP address from the 169.254.0.0/16 range to an interface. So, with zeroconf installed I get the following outout from 'ip addr':

1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:11:d8:50:e0:80 brd ff:ff:ff:ff:ff:ff
    inet 169.254.134.104/16 brd 169.254.255.255 scope link eth0
    inet 192.168.1.213/24 brd 192.168.1.255 scope global eth0
    inet6 fe80::211:d8ff:fe50:e080/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ieee1394 00:e0:18:00:00:ce:cf:54 brd ff:ff:ff:ff:ff:ff:ff:ff
4: sit0: <NOARP> mtu 1480 qdisc noop
    link/sit 0.0.0.0 brd 0.0.0.0

The interesting one here is 2: The 192.168.1.213 address is what is configured as a static address. 169.254.134.104 is what zeroconf adds.

Networking in general works fine with this. However, mondoarchive uses ifconfig to obtain the IP address for the NFS config. 'ifconfig' gives:

eth0      Link encap:Ethernet  HWaddr 00:11:D8:50:E0:80
          inet addr:169.254.134.104  Bcast:169.254.255.255  Mask:255.255.0.0
          inet6 addr: fe80::211:d8ff:fe50:e080/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:13785 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10514 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:17528791 (16.7 MiB)  TX bytes:977510 (954.5 KiB)
          Interrupt:177

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:358 errors:0 dropped:0 overruns:0 frame:0
          TX packets:358 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:20284 (19.8 KiB)  TX bytes:20284 (19.8 KiB)

which means it only gives the IP address configured by zeroconf. And that address is what is using during restore and of course doesn't work.

I am not 100% sure what to do here but don't think it is super urgent. I mainly wanted it documented somewhere - maybe we should also put it in the wiki ?

One interesting comment I saw is that apparently ifconfig is getting superseded by the ip command. Maybe we need at some stage replace ifconfig with ip.

Cheers, Andree

During diagnosis of a different problem, I was presented with an on-screen (console) message reading, in part...

sh: -c: line 0: syntax error near unexpected token `(' sh: -c: line 0: `mkisofs -no-emul-boot -b isolinux.bin -boot-load-size 4 -boot-info-table -c boot.cat -o /backupMondo- (test) -Birch-061025@… -J -r -p MondoRescue? -publisher www.mondorescue.org -A Mondo_Rescue_GPL -V 1 . >> /var/log/mondo-archive.log 2>> /var/log/mondo-archive.log' Call to mkisofs to make ISO (ISO #1) ...failed ---promptdialogYN---1--- Failed to burn ISO #1. Retry?

However, these error messages didn't appear in the log. When I submitted the information to the mondo-devel list, I included both the (compressed) lot, and this snapshot of the screen (above).

It might be useful to make sure all error messages are echoed to the log, so sending you that log would be adequate for your further investigation.

During the compare operation, mondorescue only uses the mountlist from the source system. If the target system does not have the same mountlist, compare will failed. The proposal is to add an interactive mode to change the mountlist before doing the compare operation.

I am requesting the following enhancements to Mondo/Mindi?:

A live CD (or other method of creating this) that would scan the system for necessary drivers and such to create a custom, bootable USB disk with the necessary drivers for the DVD burner, etc. The USB disk would contain a backup-to-DVD solution that created a backup and burned bootable DVDs (DVDs just like Mondo's current DVD backups).

Just to be clear: I do not want to back up files to the USB drive -- I want to BOOT from the USB and burn backups to DVDs.

When I restore a backup to a new hard disk and let Mondo do the partioning and formatting, it uses 1024 as ext3 block size, but the original hard disk had 4096.

When dealing with very large files useless in a backup (aka a 22GB swap file e.g.) allow for their exclusion with -E or something similar.

mondo should support other type of NICs such as xenbrxx, vlanxx, ...

t also restores a few other empty directories which weren't selected in the file list. They seem to be consistent, in that I've done it twice and it restored the same 3 empty directories (note that they weren't empty on the original system). Since no unwanted files from those directories were restored I suppose that it's not really a big problem, but it is odd.

The unwanted directories restored in addition to what I asked for were:

/home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur
/tmp
/var/lib/mysql

I've noticed that they seem to be coming from the biggiefiles section even though they weren't selected.

Done.
Reassembling large files      
	[Main] mondorestore.c->restore_all_biggiefiles_from_stream#2397: OK, there are 5 biggiefiles in the archives
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1395: /home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur/1140740942.3798_596.rlo.com.au,S=86071333:2, --- pih=NO
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1418: Skipping /home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur/1140740942.3798_596.rlo.com.au,S=86071333:2, (name isn't in biggielist subset)
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1481: Reassembling big file 1 (/home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur/1140740942.3798_596.rlo.com.au,S=86071333:2,)
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1501: Pipe command = 'cat > "/dev/null"'
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #1, slice #0    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #1, slice #1    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #1, slice #2    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #1, slice #3    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #1, slice #4    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #1, slice #5    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #1, slice #6    
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1561: pathname_of_last_file_restored is now 
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1573: biggiestruct.filename = /home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur/1140740942.3798_596.rlo.com.au,S=86071333:2,
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1574: biggiestruct.checksum = 931bcc31faaebc228109f8f78c95f201
[Main] mondorestore.c->restore_all_biggiefiles_from_stream#2430: I believe I have restored 
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1395: /home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur/1140741010.3798_597.rlo.com.au,S=86075819:2, --- pih=NO
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1418: Skipping /home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur/1140741010.3798_597.rlo.com.au,S=86075819:2, (name isn't in biggielist subset)
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1481: Reassembling big file 2 (/home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur/1140741010.3798_597.rlo.com.au,S=86075819:2,)
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1501: Pipe command = 'cat > "/dev/null"'
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #2, slice #0    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #2, slice #1    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #2, slice #2    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #2, slice #3    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #2, slice #4    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #2, slice #5    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #2, slice #6    
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1561: pathname_of_last_file_restored is now 
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1573: biggiestruct.filename = /home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur/1140741010.3798_597.rlo.com.au,S=86075819:2,
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1574: biggiestruct.checksum = f9ba3e4c5d6b8daf10d5c47d4fcedc78
[Main] mondorestore.c->restore_all_biggiefiles_from_stream#2430: I believe I have restored 
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1395: /home/vpopmail/domains/ticgroup.com.au/sapsupport.tar.gz --- pih=NO
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1418: Skipping /home/vpopmail/domains/ticgroup.com.au/sapsupport.tar.gz (name isn't in biggielist subset)
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1481: Reassembling big file 3 (/home/vpopmail/domains/ticgroup.com.au/sapsupport.tar.gz)
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1501: Pipe command = 'cat > "/dev/null"'
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #3, slice #0    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #3, slice #1    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #3, slice #2    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #3, slice #3    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #3, slice #4    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #3, slice #5    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #3, slice #6    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #3, slice #7    
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1561: pathname_of_last_file_restored is now 
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1573: biggiestruct.filename = /home/vpopmail/domains/ticgroup.com.au/sapsupport.tar.gz
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1574: biggiestruct.checksum = 1e4aa002fbebb935d4a185d708782b51
[Main] mondorestore.c->restore_all_biggiefiles_from_stream#2430: I believe I have restored 
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1395: /tmp/selected-files.txt --- pih=NO
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1418: Skipping /tmp/selected-files.txt (name isn't in biggielist subset)
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1481: Reassembling big file 4 (/tmp/selected-files.txt)
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1501: Pipe command = 'cat > "/dev/null"'
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #4, slice #0    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #4, slice #1    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #4, slice #2    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #4, slice #3    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #4, slice #4    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #4, slice #5    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #4, slice #6    
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1561: pathname_of_last_file_restored is now 
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1573: biggiestruct.filename = /tmp/selected-files.txt
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1574: biggiestruct.checksum = 841aec6a37f6d2d2b9991eb31f9f6fd2
[Main] mondorestore.c->restore_all_biggiefiles_from_stream#2430: I believe I have restored 
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1395: /var/lib/mysql/ibdata1 --- pih=NO
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1418: Skipping /var/lib/mysql/ibdata1 (name isn't in biggielist subset)
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1481: Reassembling big file 5 (/var/lib/mysql/ibdata1)
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1501: Pipe command = 'cat > "/dev/null"'
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #0    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #1    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #2    
[...]	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3184    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3185    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3186    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3187    
update_progress_form_full(      I am now reassembling all the large files.     ,Working on file #5, slice #3187,         Please wait. This may take some time.       ) --- g_current_progress=3216; g_maximum_progress=3215
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3188    
update_progress_form_full(      I am now reassembling all the large files.     ,Working on file #5, slice #3188,         Please wait. This may take some time.       ) --- g_current_progress=3216; g_maximum_progress=3215
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3189    
update_progress_form_full(      I am now reassembling all the large files.     ,Working on file #5, slice #3189,         Please wait. This may take some time.       ) --- g_current_progress=3216; g_maximum_progress=3215
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3190    
update_progress_form_full(      I am now reassembling all the large files.     ,Working on file #5, slice #3190,         Please wait. This may take some time.       ) --- g_current_progress=3216; g_maximum_progress=3215
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3191    
update_progress_form_full(      I am now reassembling all the large files.     ,Working on file #5, slice #3191,         Please wait. This may take some time.       ) --- g_current_progress=3216; g_maximum_progress=3215
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3192    
update_progress_form_full(      I am now reassembling all the large files.     ,Working on file #5, slice #3192,         Please wait. This may take some time.       ) --- g_current_progress=3216; g_maximum_progress=3215
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3193    
update_progress_form_full(      I am now reassembling all the large files.     ,Working on file #5, slice #3193,         Please wait. This may take some time.       ) --- g_current_progress=3216; g_maximum_progress=3215
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1561: pathname_of_last_file_restored is now 
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1573: biggiestruct.filename = /var/lib/mysql/ibdata1
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1574: biggiestruct.checksum = 78161e8cd4e70e2c30ae89e5070f4ac0
[Main] mondorestore.c->restore_all_biggiefiles_from_stream#2430: I believe I have restored 
[Main] mondorestore.c->restore_all_biggiefiles_from_stream#2447: 5 biggiefiles in biggielist.txt; 5 biggiefiles processed today.
	[Main] mondorestore.c->restore_all_biggiefiles_from_stream#2470: mondorestore.c, restore_all_biggiefiles_from_stream, 2470: No biggiefiles selected. So, no biggie-EXATs to set.
Done.
	[Main] libmondo-stream.c->closein_tape#120: closein_tape() -- entering
	[Main] libmondo-stream.c->closein_tape#138: closein_tape() -- leaving
running: mt -f /dev/st0 offline > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
--------------------------------end of output------------------------------
...ran just fine. :-)
		[Main] libmondo-devices.c->eject_device#235: Ejecting /dev/st0
running: eject /dev/st0 > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
--------------------------------end of output------------------------------
...ran just fine. :-)
	[Main] libmondo-files.c->length_of_file#611: filename=/etc/raidtab
Unable to openin filename (No such file or directory)
running: ps  | grep " petris " | awk '{print $1;}' | grep -v "grep" > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
--------------------------------end of output------------------------------
...ran with res=256
running: kill `ps  | grep " petris " | awk '{print $1;}' | grep -v "grep"` > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
kill: usage: kill [-s sigspec | -n signum | -sigspec] [pid | job]... or kill -l [sigspec]
--------------------------------end of output------------------------------
...ran with res=256
	[Main] mondorestore.c->restore_everything#2716: restore_everything() --- leaving
Freeing memory formerly occupied by filelist
	[Main] libmondo-filelist.c->free_filelist#429: Finished freeing memory
	[Main] mondorestore.c->restore_to_live_filesystem#974: Tape : I don't need to unmount or eject the CD-ROM.
running: umount /mnt/cdrom > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
umount: /mnt/cdrom: not mounted
--------------------------------end of output------------------------------
...ran with res=256
running: mt -f /dev/st0 offline > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
/dev/st0: Input/output error
--------------------------------end of output------------------------------
...ran with res=256
		[Main] libmondo-devices.c->eject_device#235: Ejecting /dev/st0
running: eject /dev/st0 > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
--------------------------------end of output------------------------------
...ran just fine. :-)
	[Main] mondorestore.c->main#3194: Still here. Yay.
running: rm -Rf /storage/mondo.tmp.MXRHQj/* > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
--------------------------------end of output------------------------------
...ran just fine. :-)
		[Main] libmondo-tools.c->unmount_boot_if_necessary#1309: starting
		[Main] libmondo-tools.c->unmount_boot_if_necessary#1316: leaving
	[Main] libmondo-files.c->register_pid#815: Unregistering PID
running: umount /mnt/cdrom > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
umount: /mnt/cdrom: not mounted
--------------------------------end of output------------------------------
...ran with res=256
[Main] newt-specific.c->finish#406: Calling newtSuspend()

I want to use the "-n" option with mondoarchive, to write to an automounted nfs share. For instance, we have have a NAS appliance called pisrh11, which has space carved up for nfs shares. On our servers, we are using the automounter, which automatically maps shares on pishr11, based on entries in the /etc/auto_* files.

Here would be the automount file for application installed locally:

# more /etc/auto_apps
TRPperf		-rw	localhost:/export/appl/pkgs/&
pb              -rw     localhost:/opt/&   # PowerBroker
java            -rw     localhost:/export/appl/pkgs/&
AppManager      -rw     localhost:/export/appl/pkgs/AppManager/v8

Here is the master automount file which points to some NIS maps:

# more /etc/auto_master
/trprmt/logs    yp:auto.trprmt
/nfs            yp:auto.nfs
/apps		/etc/auto_apps

And here is the NIS entry for the mondoarchive shares:

# ypcat auto.nfs|grep Linux
-soft,bg,rw		pishr:/images_Linux/trp
-soft,bg,rw		pishr11:/images_Linux/trp

Here is the share mounted:

# pwd
/root
(piadm41)# cd /nfs/LinuxImages
(piadm41)# pwd
/nfs/LinuxImages
(piadm41)# df -k .
Filesystem           1K-blocks      Used Available Use% Mounted on
pishr:/images_Linux/trp
                     103257600   3244608 100012992   4% /nfs/LinuxImages
(piadm41)# mount|grep Linux
pishr:/images_Linux/trp on /nfs/LinuxImages type nfs (rw,soft,addr=10.22.214.26)

Thanks again.

while running mondoarchive I noticed this error.

---evalcall---E---
---evalcall---1---        Making catalog of /home
---evalcall---2--- TASK:  [*********...........]  44% done;  0:06 to go
---evalcall---E---
sh: -c: line 0: unexpected EOF while looking for matching `''
sh: -c: line 1: syntax error: unexpected end of file
---evalcall---1---        Making catalog of /home
---evalcall---2--- TASK:  [***********.........]  53% done;  0:05 to go
---evalcall---E---

It may be due to this:

Under .java/.userprefs there were directories like below:

I deleted them and mondo ran OK.

~/.java/.userPrefs/_!'8!cg"n!#4!b@"v!(}=> ls
_!'0!}@"4!&8!d@"z!'`!cg"f!'k!bg"0!'`!cg"m!'%!}w"l
_!'0!a@"u!&8!d@"z!'`!cg"f!'k!bg"0!'`!cg"m!'%!}w"l
_!'0!}@"j!()!bw"z!&8!a@"u!'}!bw==
cache
display
_!(%!d@"v!(@!~@"f!(:!bw"1!()!}w"l
equations
_!'k!~!"f!(%!d@"v!(@!~@"f!(:!e@"u!':=
language
license
macros
_!'@!~@"m!'%!d@"s!(@!|w"j!'g!}@"y!(@!|w"k!'`!~g"h!(`!b!"0!(:=
portfolio
prefs
prefs.xml
proxy
watchscreens

Hey, I noticed that even if mondoarchive is running with exclude to some directories and exclude the NFS file systems, when the mondo is making the catalog, he is 'lstat'ing ALL the files including those to be excluded later.

The problem is that we have servers with NFS mount point that holds millions of millions of files and the lstat is taking too long ( + making the NFS server work very hard).

Is it possible somehow to change this behavior ?

mondoarchive could indeed Automagically toggle the -z flag when SELinux is on.

Hello,

I have system, which contains non standard filesystem partitions (informix data parts). Mondo can't backup them (ofcourse), he ignores them. When I want to clone system, he don't know about these partitions and I have to make them by hand. When cloning multiple machines, it is annoying. I resolved this by saving (sfdisk -d) for all drives in system, and in modified post-init, if they didn't match current setup, I ask to repartition them. I wish mondo can parttion them in the same fashion.

Moreover, it is philosophical that mondo should include two basic modes: restore to original system and clone system. In restore original, the system ramdisk & bootup process could be used to ensure correct module & device initialization, repartition drives to same configuration with NO questions :). In clone mode, there could be that nice features like inserting all modules, mountlist resizing and checking, many questions etc.

Thanks

running OpenSuse? 11.1 & 11.2 64

When using

/usr/sbin/mondoarchive -Vr -d /dev/sr0 -s 4480m -g

mondoarchive asked me what device to compare, even though I have it in the command line.

(report from Robert E Laughlin)

Problem for pre script: it has to be at the root of the NFS share mounted. subdir are not handled, due to copy under /tmp as of now

During restore, the partitions are correctly sized but the lvm size appear to zero. Mondorestore will size the lvm correctly when it will continue to process. The sizes are correctly computed by the script /tmp/i-want-my-lvm. But It should be good to have the lvm size not displayed to zero.

Hi All,

I have backed up a server running drbd and restored it to another server with the same hard disk configuration.

When I try to look at the restored drbd partition using drbdadm role r0 I get the error message Unconfigured.

When I try to check my replica mount, I see that /dev/drbd0 is not mounted and the mount point is now a folder on /dev/mapper/VolGroup00-LogVol00.

I am running mondo V3.0.3-r3091.

Any ideas on how to fix this most gratefully received.

As reported on the ML:

If i boot the CD in 'UEFI' mode, i get:

        error: no such partition.
        Entering rescue mode...
        grub rescue> _

in rescue mode:

        grub rescue> ls
        (hd0) (hd1) (cd0)
        grub rescue> set
        cmdpath=(cd0)/EFI/BOOT
        prefix=(cd0,gpt2)/boot/grub
        root=cd0,gpt2


If i boot it in 'legacy' mode, i get ISOLINUX boot banner and then:

        Failed to load isolinux.c32
        Boot failed: press a key to retry...

Installing mondo withapt-get install on Debian 8 works, but there are dependencies lacking (some are mandatory, some nice to have)

I see this in the messages file about 100 times every time mondobackup runs. Why?

See attached mondoarchive.log.

Ver 2.09 I noticed that when verifying biggie files in graphic mode the progress tape never goes over 1%.

It would be nice if you could add a timestamp to the filename of the logfile. So you wouldn't override the previous logfile and bugtracking would be easier.

When I run mondoarchive using -V (verify) mondo asks for device /dev when switching from making the DVD to verifying the DVD.

During the start of the verify mondo asks for the /dev. If I answer the /dev prompt immediately mondo then asks to abort the backup. But if I wait till the dvd activity stops then enter /dev/sr0 the verify proceeds and the mondoarchive with verify succeeds.

log attached

I have restored RHEL5.1 with mondo-2.2.4-1.rhel5 and compared "rpm -Va" results taken before and after the restoration. And I found that ower user and group of symbolic links originally different from root.root was changed to root.root.

# diff node01.2008011663155/rpm-Va node01.2008011684617/rpm-Va
1218a1219,1225
> .....UG.   /usr/bin/rpmdb
> .....UG.   /usr/bin/rpmquery
> .....UG.   /usr/bin/rpmsign
> .....UG.   /usr/bin/rpmverify
> .....UG.   /usr/lib/rpm/rpme
> .....UG.   /usr/lib/rpm/rpmu
> .....UG.   /usr/lib/rpm/rpmv

These are all symbolic links to another file, for example;

<Original>
# ls -l /usr/bin/rpmdb
lrwxrwxrwx 1 rpm rpm 15 Jan 16 17:29 /usr/bin/rpmdb -> ../lib/rpm/rpmd

<After Restoration>
# ls -l /usr/bin/rpmdb
lrwxrwxrwx 1 root root 15 Jan 16 17:29 /usr/bin/rpmdb -> ../lib/rpm/rpmd

As owners of linked "real" files were not modified, there's probably no practical issue. But I think, if possible, it's better to fix it. (Sorry for that I have no idea how to fix it.)

RPMs I used are as below;

afio-2.4.7-1.x86_64.rpm
buffer-1.19-1.x86_64.rpm
mindi-1.2.4-1.rhel5.x86_64.rpm
mindi-busybox-1.2.2-3.rhel5.x86_64.rpm
mondo-2.2.4-1.rhel5.x86_64.rpm

I have run into a scenario where it would be useful to have a little more control over how recovery media boots. In particular, the boot loader timeout and default boot option.

For my purposes, it would be useful to have restoration media timeout quickly and boot into expert mode as a default. Once booted the user will be able to select backups from library disk to restore from via a script (that eventually call on mondorestore).

Using mindi versus mondo would be an option to get expert working as the default but it would require that I handle the generation of CD/DVD media externally, something which mondo does nicely already.

The changes required to implement this are minimal.

Establish globals prior sourcing mindi.conf:

MINDI_ADDITIONAL_BOOT_PARAMS="..." 
MINDI_DEFAULT_BOOT_OPTION=""
MINDI_BOOT_TIMEOUT=""

in MakeBootConfFile?, handle the mindi.conf default option and timeout for mondoarchive non-CDRECOVERY only:

MakeBootConfFile()
{
    ...
    # Compute which default option to boot from
    ...
    elif [ _"$MONDO_SHARE" != _"" ]; then
        if [ -e "$MINDI_TMP/NETFS-DEV" ]; then
            echo -en "default${sep}iso\n"
        elif [ "$MINDI_DEFAULT_BOOT_OPTION" != "" ]; then
            LogIt "Overriding default boot option: $MINDI_DEFAULT_BOOT_OPTION"
            echo -en "default${sep}${MINDI_DEFAULT_BOOT_OPTION}\n"
        else
            echo -en "default${sep}interactive\n"
        fi
    else
    ....
    # Handle timeout
    if [ "$CDRECOVERY" == "yes" ]; then
        echo -en "timeout${sep}1000\n"
    elif [ "$MINDI_BOOT_TIMEOUT" != "" ]; then
        LogIt "Overriding boot timeout: $MINDI_BOOT_TIMEOUT"
        echo -en "timeout${sep}${MINDI_BOOT_TIMEOUT}\n"
    else
        echo -en "timeout${sep}300\n"
    fi
    ....
}

A small change but one that would be useful.