Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#669 closed defect (fixed)

mondorestore fails within archive over NFS. Same image works by CD

Reported by: Andrea Owned by: Bruno Cornec
Priority: normal Milestone: 3.0.4
Component: mondo Version: 2.2.9
Severity: normal Keywords: NFS fails
Cc:

Description

The client boots via pxe and mount a nfs directory where images are stored. The init process configure eth0 correctly, mount share NFS, mount image on /mnt/cdrom, extract necessary files from all.tar.gz . at this point, after several modprobe, it complains that ext3 format is unsupported and device-mapper not found in kernel. I have no problem if I boot from cdrom or virtual cdrom (ILO). I received the image form another team, so i was not sure about naming problem (switch -p). I made another fresh image with -p set correctly and pointing on the nfs export where the images resides. The command that I applied is: mondoarchive -On nfs://xxx.xxx.xxx.xxx:/my/dir -D -s 4480m -N -9 -p whatever The versions are: mondo-2.2.9.4-1.rhel5 mindi-busybox-1.7.3-1.rhel5 mindi-2.0.7.5-1.rhel5 kernel: 2.6.18-308.el5 Hardware : Proliant Gen-G8

I can't understand why same kernel and same initrd fails over pxe

Let me know if you need more details

Attachments (1)

mondorestore.log (64.1 KB ) - added by Andrea 11 years ago.

Download all attachments as: .zip

Change History (6)

by Andrea, 11 years ago

Attachment: mondorestore.log added

comment:1 by Andrea, 11 years ago

Version: 3.0.22.2.9

comment:2 by Bruno Cornec, 11 years ago

As oer the FAQ http://trac.mondorescue.org/wiki/FAQ#Q38Whichversionsofmindiandmondoarecompatible you need a newer version of mindi-busybox so your env works correctly. Also your log says mindi 2.1.3 when you said earlier 2.0.7.

Now you may want to use the latest versions available to avoid other issues (and get new ones ;-)

Another point you should look at is the driver supporting your server. On recent distros, hpsa replaced cciss which then needs to be explicitely excluded at restore time to avoid problems with disk recognition and support.

comment:3 by Andrea, 11 years ago

Thanks for your reply Bruno.

I'll try the solution you suggested (denymods="hpsa") when I'll have time. Another thing , but I need to double check, is the mindi version mismatched. I've taken the numbering from the restored machine, not the log .

In every case, following the table, the versions aren't compatible each other and we need to install the right versions. I didn't check versions first as the restoring system worked like a charms before to upgrade OS image to support new driver. I'll contact the OS image maintainers to adjust this point.

I'll keep you updated as I'll could do some tests.

comment:4 by Andrea, 11 years ago

Resolution: fixed
Status: newclosed

Hi Bruno, I did some tests, and I can confirm that within lasts versions of mondo release, everything works like a charm. The restore process over nfs works fine and in no gui mode finally. About the mismatched version of mindi (2.1.3 in log and 2.0.7 on machine) , originally I used an initrd gave me separately from the team who creates the images, that's why the versions differ.

Thank you very much for your job and you have a follower on your blog :)

comment:5 by Andrea, 11 years ago

Hello Bruno,

I succeeded to restore images finally. When i closed the ticket, I tested on virtual machine, recreating the initial situation. On real world, was a little bit more tricky. At first, I restore an image using the virtual media on the real server, updated mindi, mondo, mindi-busybox to latest versions accordingly and created a new boot disk. At this point, I tried a restore over pxe nfs , but it fails after lvm creation and partition formatting. This was a problem related to image prefix (mondo tried to mount mondorescue-1.iso). I solved creating a symbolic link to the image and now I have also a script to create this link dynamically in every case (I'm not the owner of these images and I can't know how they have been archived). Test n. 2: restore failed, but a little bit far, after restoring archive NFS n.3. Log file tell me that no more loop devices are available . I checked the mount filesystem and did a losetup finding that no cdrom were mounted but loop devices were fully occupied. I didn't know that over NFS each restore calls a mount and umount cdrom , this was a kind of discover for me. I tried to add more loop devices on pxe append options but it didn't work, so I decided to write a prerun script to prepare my environment. This script prepare and start the ssh server, tail the log file on the nfs server and check the loop devices in background to minimize their use. I tested different images (differents version on them) and mondorestore did his job as expected . I've read about mindi-busybox 1.18.5 where calling umount don't erase the corresponding loop device and I suppose that mondo charged from the image evidently it's not patched as new version.

Note: See TracTickets for help on using tickets.