Description of problem: umount-all could result in the user-created mountpoints missing while they are actually not deleted. Version-Release number of selected component (if applicable): libguestfs-1.3.18 How reproducible: Always Steps to Reproduce: run this guestfish script, $ guestfish <<EOF sparse test.img 10M run part-disk /dev/vda mbr mkfs ext2 /dev/vda1 mkmountpoint /mnt mount /dev/vda1 /mnt umount-all -mount /dev/vda1 /mnt -mkmountpoint /mnt EOF Actual results: guestfish outputs error with the last mount as if the /mnt mountpoint was never made, ><fs> mount /dev/vda1 /mnt libguestfs: error: mount: you must mount something on / first but when trying to create the mountpoint again it says it already exists, ><fs> mkmountpoint /mnt libguestfs: error: mkmountpoint: /mnt: File exists Expected results: mountpoints should still be valid after umount-all. Additional info: calling umount with the mounted device will not cause this problem.
What happens here inside the daemon is that we set the root_mounted flag to 0, which renders the mountpoint created by mkmountpoint unusable. This is a fairly obscure corner case, and a comprehensive fix for it is complex and risky. It may be better to just document this behaviour.
(In reply to comment #1) > This is a fairly obscure corner case, and a comprehensive > fix for it is complex and risky. It may be better to just > document this behaviour. Yes. If you are going to document this please also consider another special behaviour that comes with umount-all. We have an iso image inside which there is an ext2 image file. This is just like the situation described in the help text of mkmountpoint. If we do this, mkmountpoint /cdrom mkmountpoint /ext2 mount /dev/vda /cdrom mount-loop /cdrom/ext2fs.img /ext2 umount-all we get 'device is busy' error from the umount-all. The key point is we did the first mount at a place which has a longer path than the second one does. umount-all decides the umount order by sorting the mountpoints through their lengths. This is ok with most cases, but problematic with the very special case described above. However this is still not a severe problem in my eyes, hence I'm not opening another bug for this. Just please be aware of this case.
Updating summary to reflect that we're not going to fix this, just document the 2 cases described in this bug.
Patch posted upstream: https://www.redhat.com/archives/libguestfs/2010-October/msg00070.html
This bug is actually completely fixed (not just documented) in libguestfs 1.10. (commit 77df7d6d537cebe05e06bf07e6e4a2082fe6656a)