mondo doesn't work on x86_64

[Bruno Cornec]

At least 3 persons have reported issues with mondo on x86_64

[Tadej Janež]

I've come a little further with my x86_64 backup.

My steps so far:

1. Rebuilt 64bit versions of rhel 4 src.rpm packages (mondo, mindi, afio and buffer) on my CentOS 4.4 x86_64 machine and installed them

2. Made backup with mondoarchive using command: mondoarchive -O -i -d /mnt/nfsbackup -p samsontest-20060926 -N -I "/" -E "/home /mnt /media /tmp" -F -s 700m

3. Burned the first .iso and rebooted the machine to try the backup.

4. On the same machine, using interactive mode, mondorestore finds my LVM partitions and after skipping 'format', 'partition' and 'restore all data' options, I chose the 'restore some data' option to test if mondorestore works. Indeed, I was able to restore a testing file, mondo successfully mounted and unmounted my LVM partitions, I skipped bootloader options, everything seemed to be working fine.

5. Then I tried to do a bare-metal restore on a different x86_64 capable machine. I inserted the cd, chose interactive mode and then 'read from cdr disks' option. At this point mondorestore tried to mount the cd and 'hung' with 'I'm thinking' sentence being displayed on the screen. I tracked down this particular issue and found out that mondorestore was trying to do something with the floppy, but this machine didn't have any floppy device. I was able to work around this bug with this trick: boot with 'expert' option, do 'rmmod floppy' and run 'mondorestore'.

I thought that I'll be able to do a bare-metal restore now, but another problem came up. On the original machine, I had a single hard disk recognised as a /dev/sda device, but this machine apparently doesn't have hard disk at /dev/sda but somewhere else and mondorestore complained that my mount list wasn't working. I proceeded anyway, but mondorestore failed with a fatal error when trying to partition and format my hard drives. I wasn't going to give up, so I tryed to track down the info about the hard drive and where it is residing. I looked at dmesg and messages log files but they were filled with enormous amouts of lines like 'ext3 ... feature not supported' and 'nfsd ... something'. I was able to find out that my cdrom is seen as /dev/hda device but no info on my hard disk. I think there are too many ext3/nfsd error lines in messages/dmesg log so the previous lines had to be deleted, but I need that info for my restore.

This is as far as I got.

I'll attach my fstab file if it helps somehow.

I'll be willing to test any fixes you come up with and provide any info you need. Thank you for your time, Tadej

[Bruno Cornec]

Comments from Brendan Bouffler brendan.bouffler_at_hp.com :

---

Essentially 2 fixes:

1) ldconfig stuff - mod to ld.so.conf in mindi's rootfs tree, to include lib64-style paths. Also includes the ldconfig binary in the deplist.txt and has a call to ldconfig from sbin/init (in the rootfs tree again) so that the ld.so.cache gets cooked once all the unpacking of tarballs and images has taken place and mindi is ready to start getting down to business.

2) mods to cope with RHEL4's pecularities about handling device volume labels. In here, there's essentially two fixes:

2.1) Mindi failed on my RHEL4u3 system, which was kickstart installed by RH satellite, and had included a FS label on the root filesystem device of '/'. Mindi's usual method for finding the device that matched this label was to do a blkid and grep for '/' in the label, which is bound to return multiple false positives (and did) and so on my system I ended up with no root filesystem in the mountlist.txt :-( Findfs is better to use, if it's available, so I've put it in as a 0th (ie before the 1st) method to try. 2.2) The whole swap device labelling issue, especially for swap devices that are on smart-array controllers, and so have long device names which spill over the 16 byte limit.

I take your point about having an executable written to use a c-library which makes the appropriate call, but I think for now, using dd if=/dev/cciss/some/device bs=1 skip=1052 count=16 is pretty good for the time being, and certainly works better than the current solution :-) Having said this, from everything I understand, this offset isn't expected to change until kernel v2.(7|8), which is when.... ? Anyhow, I think it'd be pretty safe to use. I'm keener on a solution sooner rather than later.

---

Thanks Brendan for the patches. They're part in rev [853] I'll will now test you version on my side to see how it works for me as well.

[Bruno Cornec]

Indeed even with Brendan's patches, it's still not working on x86_64 with PXE+NFS. There is a missing link at least on libc.so.6 under /lib64/tls

Investigation is going on.

[Bouffler, Brendan]

I'm going to be out of the office until Tue 3 Oct (Monday is a public holiday here in Sydney).

If you need me urgently, please try contacting me on my mobile/cell on +61 404 097 837.

Regards,

-- brendan bouffler

[Bruno Cornec]

rev 870 should now be correct for x86_64 issues. There was a script which did not include /lib64 and /usr/lib64 in the process, so I wonder how others on x86_64 had a working env !

Does Debian have no /lib64 dir ?

[Bruno Cornec]

I restored a rhel4 x86_64 through PXE+NFS without problem with rev [871].

[andree]

Yes and no:

andree@aurich64:~$ ls -l /lib64 lrwxrwxrwx 1 root root 4 2006-10-02 20:04 /lib64 -> /lib

Cheers, Andree

[Bruno Cornec]

That explains why you were not seeing the bugs I found for rhel4. Thanks for the feedback Andree.