Date: Fri, 23 Jan 2004 15:03:23 -1000 (HST) From: Clifton Royston <cliftonr@bass.tikitechnologies.com> To: FreeBSD-gnats-submit@FreeBSD.org Subject: kern/61810: mounts done within a chroot show up wrong and can't be unmounted from outside. Message-ID: <20040124010323.74A387CE53@bass.tikitechnologies.com> Resent-Message-ID: <200401240110.i0O1AFU3083872@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 61810 >Category: kern >Synopsis: mounts done within a chroot show up wrong and can't be unmounted from outside. >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Jan 23 17:10:15 PST 2004 >Closed-Date: >Last-Modified: >Originator: Clifton Royston >Release: FreeBSD 4.8-RELEASE i386 >Organization: Tiki Technologies >Environment: System: FreeBSD bass.tikitechnologies.com 4.8-RELEASE FreeBSD 4.8-RELEASE #3: Tue Jul 8 09:29:40 HST 2003 baron@bass.lava.net:/usr/obj/usr/src/sys/LAVA i386 FreeBSD 4.8 (RELENG_4_8) >Description: Mounting any special device from within a chroot results in mount (even outside the chroot) displaying the mount point relative to the chroot, which is not valid in any other context. Attempting to unmount the file outside the chroot either by the associated device, the displayed mount-point directory, or the full path to the mount point fails. The result is a mount that can only be removed by going back into the chroot environment from which it was mounted and unmounting it there. (If the chroot directory had subsequently been removed, you would probably have to reboot the server without unmounting it.) This may sound unlikely, but I found it by stumbling across it. After a "make release" failed due to an oversized floppy image I ended up with one of these non-unmountable mounts of /dev/vnn0c on "/mnt". The first time it happened I ended up having to reboot the server to clear it. The second time I tracked it down more closely, resulting in this report. >How-To-Repeat: The easiest way to replicate this is on a system set up to make releases which is how I stumbled across it. Otherwise, create a chroot directory (as /var/release in the example below), populate it with an empty /mnt, a basic /etc, /dev and with appropriate binaries referenced below such as /sbin/mount* and sbin/umount, and then execute: bass:/home/cliftonr# chroot /var/release mount /dev/fd0 /mnt bass:/home/cliftonr# mount /dev/da0s1a on / (ufs, local) /dev/da0s1d on /altroot (ufs, local) /dev/da0s1e on /data (ufs, local, soft-updates) /dev/da0s1f on /home (ufs, local, soft-updates) /dev/da0s1h on /usr (ufs, local, soft-updates) /dev/da0s1g on /var (ufs, local, soft-updates) procfs on /proc (procfs, local) /dev/fd0 on /mnt (ufs, local) bass:/home/cliftonr# umount /dev/fd0 umount: unmount of /mnt failed: Invalid argument bass:/home/cliftonr# umount /mnt umount: unmount of /mnt failed: Invalid argument bass:/home/cliftonr# umount /var/release/mnt umount: /var/release/mnt: not currently mounted bass:/home/cliftonr# chroot /var/release umount /dev/fd0 bass:/home/cliftonr# mount /dev/da0s1a on / (ufs, local) /dev/da0s1d on /altroot (ufs, local) /dev/da0s1e on /data (ufs, local, soft-updates) /dev/da0s1f on /home (ufs, local, soft-updates) /dev/da0s1h on /usr (ufs, local, soft-updates) /dev/da0s1g on /var (ufs, local, soft-updates) procfs on /proc (procfs, local) >Fix: When the situation arises, if the chroot and mount point still exist chrooting back into them to execute the umount works, as shown above. However, it seems to me to be a bug that the initial mount stores the mount point information - something which has visibility and pertains to the whole system, outside the chroot - in a form which ends up being invalid outside the chroot, both for display and for use with umount. No real clue how to fix it - maybe have mount also store the device ID and inode/vnode along with the path when the mount succeeds, and be able to rederive a full path from that? -- Clifton >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040124010323.74A387CE53>