Mondo restore process automatically deletes all files on NFS share

[univ]

This is probably more related to mindi but I'm hoping to catch more attention if I select "mondo" instead. This should be fixed asap.

There is a crucial issue: when booting from a mindi CD in order to restore from an ISO image which is sitting on a remote NFS server, mindi/mondo will, after completing the restore process (really just the last thing it does before dropping you to the shell after a successful restore and telling you to reboot via "exit"), delete (!) all files on the mounted NFS share! (Of course this only works if you have write permission to the mounted NFS share)

Using:

• mondo-2.2.7-1.rhel5.x86_64.rpm
• mindi-2.0.4-1.rhel5.x86_64.rpm
• mindi-busybox-1.7.3-1.rhel5.x86_64.rpm

On CentOS 5.2 64bit (x86_64)

How to repeat:

• Create an image using mondo with e.g.

mondoarchive -On 192.168.0.1:/export/backup -d /testserver -E '/mnt /mnt/cdrom /tmp /proc /mnt/floppy' -T /tmp -s 700m -N -l GRUB -f /dev/cciss/c0d0

• Take the mindi ISO and burn it to a CD. This one:

/var/cache/mindi/mondorescue.iso

• Boot from the mindi CD and restore from the above mentioned NFS share (this will be mounted under /tmp/mondo[something]/nfsdir or /tmp.old/mondo... or similar to that).

• At the very end of the successful restore process it will drop you to a shell and offer something like: enter "exit" to reboot. A couple of lines before that you will see that the restore script executed two "rm" commands on /tmp and/or /tmp.old (not sure, info comes from from memory, sorry.). You will notice this because it will report some errors like "file or directory busy" (something like that) when trying to delete. The rm commands seem to be recursive and since the NFS share is mounted there as well this probably results in all data on the mounted NFS share being deleted.

I grep'ed through the scripts and it appears to be something about this file:

/usr/lib64/mindi/rootfs/sbin/init

Possibly somewhere around here where some rm's are being executed (the following can be found at around line 488 in /usr/lib64/mindi/rootfs/sbin/init):

LogIt "Great. Pivot succeeded w/ size=$size" 1 echo -en "Pivoting /tmp..." umount /tmp/tmpfs mkdir -p /tmp.old mv /tmp/* /tmp.old/ # Try to Deal with a busybox bug on inexistant links cp /tmp/* /tmp.old/ rm -f /tmp/* $mount_cmd /tmp mv /tmp.old/* /tmp/ # Try to Deal with a busybox bug on inexistant links cp /tmp.old/* /tmp/ rm -rf /tmp.old mkdir -p /tmp/tmpfs mkdir -p $GROOVY

If you need more info write me at ms2 at lightupnet dot de.

[Bruno Cornec]

So seems that #270 is not solved when using mondorestore interactively. Of course, doing what mondo now does at restore time (mounting the NFS share ro) solves the issue.

Of course, mondorestore process shouldn't try to remove the dir anyway, so I'll have a look to find what I missed the first time.

Sorry for that.

[univ]

Replying to bruno:

Of course, doing what mondo now does at restore time (mounting the NFS share ro) solves the issue.

Hi Bruno. Could you explain this in more detail? What do you mean with "what mondo *NOW* does"... if I see it correctly I'm running the latest version (2.2.7 from rpm) and obviously the NFS share is not being mounted ro, or the issue I described wouldn't have happened. Or am I misunderstanding something here? Or do you rather mean that the NFS share will be by default mounted ro in the next version (2.2.8)?

Regards Markus

[Bruno Cornec]

Replying to univ:

Hi Bruno. Could you explain this in more detail? What do you mean with "what mondo *NOW* does"...

I mean that it does mount the NFS share read-only, when you're booting on the recovery media to do the restore.

But it doesn't deal with that phase when you launch mondorestore manually, because I had not fixed the mount call :-( This is now done in [2061] and will be in 2.2.8. However, I still need to find where the rm occurs.

[Bruno Cornec]

Report on the mailing list show that this bug is still not solved in 2.2.9 beta. However, it's *not* link to the Pivot of /tmp, as the NFS mount is not yet done at that point, so the rm done there can not delete the ISOs on the NFS.

Still searching.

[Bruno Cornec]

FTR, I've not found any suspect by looking at all rm -r calls in current 2.2.9 tree. So still no idea how all this is triggeerd :-(

[Bruno Cornec]

However the rev [2361] will fof sure improve stuff, so 2.2.9 should be more protected against that case.

[Bruno Cornec]

How to reproduce:

From your restored system (booted from mondo media) launch a first time the mondorestore command with NFS share mounted. Quit mondorestore, and relaunc with mondorestore -Z nuke, and then your NFS share doesn't contain anything anymore.

[Bruno Cornec]

Milestone 3.1.0 deleted