Red Hat Bugzilla – Bug 599503
document that mkmountpoint and umount-all cannot be mixed
Last modified: 2011-04-13 04:53:50 EDT
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):
Steps to Reproduce:
run this guestfish script,
$ guestfish <<EOF
sparse test.img 10M
part-disk /dev/vda mbr
mkfs ext2 /dev/vda1
mount /dev/vda1 /mnt
-mount /dev/vda1 /mnt
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
mountpoints should still be valid after umount-all.
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,
mount /dev/vda /cdrom
mount-loop /cdrom/ext2fs.img /ext2
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:
This bug is actually completely fixed (not just documented)
in libguestfs 1.10.