on Thu, Jan 05, 2006 at 04:59:41PM -0700, jonathan ferguson ([EMAIL PROTECTED]) wrote: > > on Wed, 4 Jan 2006 19:06:46 -0800 Karsten M. Self" > (kmself@ix.netcom.com) wrote: > > >> For mysterious reasons a Dual-boot (Windows/Linux) Toshiba 5105-s901 > >> running Debian/GNU 3.1 Sarge 2.6.8 (with updates) suddenly fails to > >> mount read-write the root partition during boot. > > > >This can indicate a problem with the filesystem is throwing errors. > >Your root filesystem is typically mounted with an 'errors=remount-ro' > >option, meaning the drive is remounted read-only if an error occurs. > > > > thanks. problem solved. mea culpa. > > after digging a little further, i discovered that *someone* (myself > probably) had inadvertently set the mount point for swap in the fstab > as /, instead of none. i reset the mount point and all was well, so > while the fstab file had not changed since the new drive install, it > was not very sane. however, that the system would have worked for a > number of months, in spite of the error, baffles me. i suppose it is > possible that autofs mounted / in spite of a broken fstab.
I'm guessing you made the change at some point after booting.
/etc/fstab isn't used to correct mountpoints, it just tells the mount
command what to mount where, when it mounts them. For system partitions
and swap, this is generally once, at boot.
> FYI: a couple of strange--- and rather obvious to see--- things happen
> when one makes this error. for the sake of posterity i'll enumerate
> them here:
>
> output from df and mount utilities in single-user mode fail to
> actually list any file systems other than memory file systems like
> /proc.
A number of utilities use /etc/mtab to gather information on currently
mounted filesystems. This naturally leads to a bit of confusion when /
itself is behaving strangely. I generally double check that /proc is
mounted (or mount proc elsewhere -- you can do this) and check what
/proc/mounts has to say about things. This _is_ kernel state, and
unless you've got a misbehaving kernel (or possibly disk or CPU), this
should be pretty sane.
> dmesg does appear to log even when unable to write to the root
> partition. fancy that.
'dmesg' should tell you the current state of the kernel ring buffer
though, even if /var/log isn't writeable.
>
> >Watch your boot process carefully.
>
> thanks. booting a number of times helped me debug the problem. and
> helped me identify that the root partition was not, in fact, a
> journaled partition. KNOPPIX and tune2fs helped rectify that problem as
> well.
Right.
> >
> >Triple-check your autofs config. If that's the change, try disabling
> >it
> >and seeing if the problem disappears.
> >
>
> i apt-get removed autofs just to see... and it had no apparent impact.
If you're still trying to figure out what it is/was doing, you might
want to post /etc/auto.master and /etc/auto.misc to this list.
Peace.
--
Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/
What Part of "Gestalt" don't you understand?
gconf-editor: reimplementation of the MS Windows Registry for
GNU/Linux, with the concommitant problems of undocumented settings,
cryptic keys, inability to comment settings, and use of a single,
specialized application to access the configuration settings.
- Karsten M. Self
signature.asc
Description: Digital signature
