Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 21 Nov 2007 18:02:10 +1100 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Yuri <yuri@tsoft.com>
Cc:        freebsd-bugs@freebsd.org, freebsd-gnats-submit@freebsd.org
Subject:   Re: misc/118160: unable to mount / rw while booting 7.0-BETA3
Message-ID:  <20071121170349.X81263@delplex.bde.org>
In-Reply-To: <200711210234.lAL2Y7cU041129@www.freebsd.org>
References:  <200711210234.lAL2Y7cU041129@www.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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:
> <here goes the list of file systems that it reports, this is ok>
> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071121170349.X81263>