Nuke restore fails on Fedora Core 5 using LVM

[Gregg Cranshaw]

I have a fedora core 5 with the latest updates running as a mail server using LVM. I downloaded and installed the latest FC5 packages from Mondo's website and installed them. I create an ISO backup of the server using the mondoarchive command. Burn the ISO's to CD's and boot off them to do a restore. At first it would halt with a kernel panic error each time I tried to boot off the CD's, but I then used the ramdisk_blocksize=1024 setting with nuke at boot and it loaded fine. After it wiped the hard drive and partitioned it, it crashed during the formating showing garbage on the screen and stating it needed a reboot to fix the problem. I did so, but had the same results. Are there any issues with Fedora Core 5, LVM and Mondo? I just want to be able to script a backup using mondo for disaster recovery purposes. I can provide whatever info you need.

[Bruno Cornec]

Please attach the /var/log/mondoarchive.log (source system) and the /var/log/mondorestore.log (target system) in order to see what happens.

[Gregg Cranshaw]

The system was blown away during the attempted restore. I did a full image creation, does it also backup the mondo log files in the image? If so, what is the easiest way to get the log files out of the image? If not, I'll have to rebuild the server and redo the image create. I can then attach the mondoarchive log file. Where would the mondorestore.log file be located when restoring from a boot disc?

[Bruno Cornec]

mondoarchive backups by default the /var/log dir on the image. The problem is that the log file may be incomplete as is taken at one moment in time, but the backup isn't finished. Anyway, would ne bnice to get what you have.

The mondorestore.log is under /tmp during the restore and moved later on at the end. So in your case should still be there.

Also be sure to use 2.2.3. 2.2.2 had a flow with bzip2 compression. If you are in that case, there are mails on Mondo ML describing how to solve the issue.

[Gregg Cranshaw]

Thanks for the info. I had to work on another issue and just now had the time to start rebuilding the box I was testing the DR restore for using Mondo. I should have it back online not this coming week, but the following week. Once I do, I'll test the Mindi boot disc first and then do a mondoarchive. I'll upload the log file to this ticket. I'll follow up after attempting the restore.

[Gregg Cranshaw]

Here are the log files. I reinstalled Fedora Core5 with the latest updates, installed Mondo from the latest RPM's from Mondo's website. I first ran through an interactive restore, but it locked up the PC during it. I then ran a compare and it failed, but did not lock up the PC, so I was able to get the log files off of the running OS.

[Gregg Cranshaw]

The mondo-archive log must have corrupted when I copied it to a floppy. I'll try it again tomorrow.

[Gregg Cranshaw]

I took another look and the attached mondo-archive.log file is exactly what is on the CD image I created. I would need to recreate the system again and the image. Then I can upload the mondo-archive.log the new image creates.

[Gregg Cranshaw]

I uploaded the mondoarchive.log of the current build and creation of the images. I am no longer using LVM, just standard partitioning. With this image burned to disc, it crashes during a Nuke or Interactive restore. The attached mondorestore.log file is from doing a compare since that fails, but does not crash the restore so I am able to pull the log file. There is nothing unique about this install. I am using Fedora Core 5, installed from downloaded discs that I have checked. After installing, I upgrade to the latest release, download and install the mondo packages from mondo's website and create the image. Please let me know if you find anything. Also, I edit the /usr/sbin/mindi script and add ramdisk_blocksize=1024 to avoid the kernel panic error from the boot disc.

[Gregg Cranshaw]

I believe ticket #150 is the same issue I'm having.

[Bruno Cornec]

The problem I see in your restore log is that your partition on your disk is mounted ro (normal for a compare mode)

	[Main] mondo-rstr-tools.c->mount_device#886: command='mount -t ext2 /dev/sda2 -o ro,user_xattr,acl /mnt/RESTORING 2>> /tmp/mondorestore.log'
running: mount -t ext2 /dev/sda2 -o ro,user_xattr,acl /mnt/RESTORING 2>> /tmp/mondorestore.log > /tmp/mondo-run-prog-thing.tmp 2> /tmp/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
--------------------------------end of output------------------------------
...ran just fine. :-)

After that the rest is just failing normaly :-(

running: mkdir -p /mnt/RESTORING/boot > /tmp/mondo-run-prog-thing.tmp 2> /tmp/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
mkdir: Cannot create directory `/mnt/RESTORING/boot': Read-only file system
--------------------------------end of output------------------------------

So there is a bug here for sure in compare mode. Now in restore mode, the mount is done rw so that problem should not happen.

Now remains to see what goes wrong in that other case.

[Gregg Cranshaw]

The only problem with restore mode is it crashes and I'm unable to get to the temporary restore log file. I have also run the compare mode two other times and they both crashed as well dumping to the screen. If the restore log is the only way to find out what is going wrong, how can I get to it if the restore or compare crashes? Since it is dumping to the screen, I can try and restore it to a vmware PC so I can get a screen shot of the dump...

[Bruno Cornec]

You can take a picture of your screen at crash time and attach it here. You can also try to mount a USB key, if you have the drivers included.

Concerning the bug, it may be related to a FC5 kernel bug. Could you try using an older kernel (2.6.15 or 16 based e.g.) ?

If it works or not in VMWare, we won't be able to know for sure if there is a link with your issue BTW. Abyway it's something which may reveal some useful tracks, so...

[Bruno Cornec]

Coming back to your log file, I think the mkdir error is harmless in fact. The real important error i just after, when mondorestore tries to mount the following partition on the mount point. That mount point should exist under your /mnt/RESTORING dir ! Which doesn't seem o be the case as that second mount fails :

running: mount -t ext2 /dev/sda1 -o ro,user_xattr,acl /mnt/RESTORING/boot 2>> /tmp/mondorestore.log > /tmp/mondo-run-prog-thing.tmp 2> /tmp/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
mount: mount point /mnt/RESTORING/boot does not exist
--------------------------------end of output------------------------------

If you have a prompt during restore, can you mount first your /dev/sda2 under /mnt/RESTORING, and then try the previous command to see what happens.

[Gregg Cranshaw]

Just because I had another workstation lying around, I tried to use the same discs that failed on another workstation. The one I have the install on is a Dell Optiplex GX620 with a P4, 1GB of RAM and an 80GB SATA hard drive. I used the restore discs on an old Gateway PIII with 512MB of RAM and a 30GB IDE hard drive. The restore discs worked perfectly fine after I remapped the FSTAB table during the restore. So it seems to be specific to the FC5 kernel and the workstation, possibly the SATA hard drive. The funny thing is, this Dell is my dev box. I originally had Debian 3.1 Sarge installed running as a Qmail server. I installed Debian's mondo packages and created a restore disc and successfully restored the server on the Dell. I am currently installing FC6 and I noticed it is using an older kernel than FC5. I'll try the same thing and see what happens. If you have seen anything like this let me know. If there is any other info I can provide due to the new info above let me know. I'm not sure there is much you can do at this point. I'll post the info I collect using FC6.

[Bruno Cornec]

Hello,

Any news on your problem ? Did FC6 solve it ?

[Bruno Cornec]

With no news on that bug, I'll consider it was due to a FC5 kernel issue and close it.