In intrepid, /etc/init.d/umountfs will unmount tmpfs, then swap, then local filesystems, so I assume it is fixed, albeit in a major refactoring.
I haven't verified loop devices or other things that might gridlock a umount so it may still have that variant of the bug. It does attempt to remount read-only and release loop devices given the options. umount itself has a "lazy" option but that is not used in the script (but would resolve the problem, e.g. if /dev/sdb1 has a loopback mounted, it will be detached and marked, and when umount gets to the loopback and unmounts it, /dev/sdb1 will follow automatically. In the umount manpage it mentions the case of umount opening libc and specifically suggests the lazy umount (kernels 2.4.11 or later, but that should include most). The lazy umount option if added should take care of any swapfile problem (i.e. when the swapfile is turned off, the pending umount will complete), though as I've noted it appears solved. One other method if possible, it should umount in the reverse order of mounting (since a drive would need to be mounted before the fsimage file could be loopbacked) and I'm not sure if the scriptography employed in getting the list of mounts in umountfs does this. another is simply to repeat the umount until nothing changes. -- Improper filesystem unmount order (swap on files) https://bugs.launchpad.net/bugs/48517 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
