Bug 663279 - chroot, mounted from losetup will never be unmounted on reboot
Summary: chroot, mounted from losetup will never be unmounted on reboot
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: initscripts
Version: 6.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: initscripts Maintenance Team
QA Contact: qe-baseos-daemons
Depends On:
TreeView+ depends on / blocked
Reported: 2010-12-15 09:25 UTC by Коренберг Марк
Modified: 2011-06-09 20:14 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-06-09 20:14:53 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Коренберг Марк 2010-12-15 09:25:51 UTC
suppose I setup chrooted environment as follow:
1. mount some losetup into /test.
2. mount --bind /proc, /sys, /dev and so on into /test/$item

when reboot command is passed, system will start __umount_loopback_loop()  from /etc/init.d/functions.

It will not be able to unmount /test because mountpoint is busy (/test/proc is mounted)

I think, __umount_loopback_loop() should detect situation when "fuser" return empty list and still can not umount.

The problem is in the lack of recursive umount functional (see http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg199613.html)
Other problem is lack of testing for underlying mountpoints in fuser tool.

As the fast way to umount /test when fuser say nothing, is to use umount -l.
I discover, that umount -l will recursively unmount submounts.

Comment 2 Bill Nottingham 2011-06-09 19:58:53 UTC
Changing this to cover all cases would be too much of a change for an update release - this should be fixed properly in the next major release.

Comment 3 RHEL Program Management 2011-06-09 20:14:53 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

Note You need to log in before you can comment on or make changes to this bug.