From owner-freebsd-bugs@FreeBSD.ORG Wed Nov 21 07:02:37 2007 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4672116A417; Wed, 21 Nov 2007 07:02:37 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by mx1.freebsd.org (Postfix) with ESMTP id DFE4D13C461; Wed, 21 Nov 2007 07:02:36 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail18.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lAL72A4c008417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2007 18:02:13 +1100 Date: Wed, 21 Nov 2007 18:02:10 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Yuri In-Reply-To: <200711210234.lAL2Y7cU041129@www.freebsd.org> Message-ID: <20071121170349.X81263@delplex.bde.org> References: <200711210234.lAL2Y7cU041129@www.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-bugs@freebsd.org, freebsd-gnats-submit@freebsd.org Subject: Re: misc/118160: unable to mount / rw while booting 7.0-BETA3 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 07:02:37 -0000 On Wed, 21 Nov 2007, Yuri wrote: >> Description: > After recompiling and reinstalling the current BETA3 my system has a reboot problem. > While booting log says: > Starting file system checks: > > mount: : Operation not permitted. This is probably a secondary problem. You apparently have the root device mounted on "" or something like that. > Mounting root file system rw failed, startup aborted. > /etc/rc: WARNING: $true is not set properly - see rc.conf(5) Whatever caused this is probably the main problem. > and system gets to single user mode. > In single user mode / is read-only. And command 'mount -uw /' fails Operation not permitted. I count't find the workaround so far. Please keep line lengths below 80 in mail. What does mount shouw for the root device? > The major bug seems to be in the 'mount' system call. 'man mount' says that EPERM is returned if "The caller is neither the super-user nor the owner of dir." I am root. THis was broken in GEOM somewhere near g_vfs_access(). g_vfs_access() returns EPERM for all errors involving exclusive access. This breaks the documented behaviour of [n]mount() returning EBUSY for attempts to mount the same device more than once (unless all mounts are r/o -- multiple r/o mounts are broken differently, by allowing them and panicing on a garbage bufobj pointer later). You are apparently attempting to mount the same device twice (even though -u specifies an already-mounted device, the kernel is apparently confused about where it is mounted). > The secondary problem is this printout: WARNING: $true is not set properly - see rc.conf(5) > It shouldn't print $true FIx this first. > Another secondary problem is with man mount(2). Isn't is supposed to mention that setting securelevel also makes 'mount' return EPERM? I think securelevels break a lot of man pages like that. > So now I can reboot normally only choosing "single user mode" when I boot and running "mount -uw /" as a single user. And then continuing the boot process. Yes, it makes some sense for mounting / r/w in the right place gets it mounted r/w before other things mess it up. Don't forget to run fsck -p manually before continuing. I can now see a plausible way to reach the bad state: - after booting, the root device is mounted on / r/o with no problems - mistype a mount command or have $true generate a wrong mount command, so that the root device is mounted somewhere else (I don't know how it can be on "", but it could be on " " or on any valid pathname). If you preemptively mount it r/w, then this other mount will fail -- look in the logs for messages about this. - now try to remount / r/w normally. This will fail due to the r/o mount not on /. - if there is only 1 extra r/o mount of /, then the r/w mount should work after unmounting the extra. If there are several extras, then unmounting them in a certain order should give the bufobj panic. The EPERM instead of EBUSY error is very confusing. Another variation on it is that after shutdown to single user mode (using "kill -TERM 1" or similar), and unmounting all devices except / an /dev, and remounting / r/o, "fsck -p" and "fsck /" are broken due to problems near g_access(). They fail with the now familiar error EPERM. Some file systems have a a hack to allow them fsck to work after booting, but it doesn't apply later. Bruce