After crash, / comes up mounted read-only, but in multiuser; mfs /tmp?

From: Robert Watson <rwatson_at_FreeBSD.org>
Date: Fri, 2 Dec 2005 10:41:59 +0000 (GMT)
While testing the new DRM update (went badly :-), I crashed my system and 
had to power cycle it.  When it came back up, not surprisingly, the file 
systems weren't clean.  When I reached a login prompt, I logged in to 
modify /etc/rc.conf, and to my surprise, was told that /etc/rc.conf wasn't 
writable.  Turns out it was because / was mounted read-only:

ad0: 57231MB <HTS541060G9SA00 MB3IC60H> at ata0-master SATA150
acd0: CDRW <HL-DT-STCD-RW/DVD DRIVE GCC-4246N/0X05> at ata1-master UDMA33
Trying to mount root from ufs:/dev/ad0s3a
WARNING: / was not properly dismounted
Loading configuration files.
kernel dumps on /dev/ad0s3b
Entropy harvesting: interrupts ethernet point_to_point kickstart.
swapon: adding /dev/ad0s3b as swap device
Starting file system checks:
/dev/ad0s3a: INCORRECT BLOCK COUNT I=16528 (4 should be 0) (CORRECTED)
/dev/ad0s3a: UNREF FILE I=16528  OWNER=root MODE=100444
/dev/ad0s3a: SIZE=0 MTIME=Dec  2 10:33 2005  (CLEARED)
/dev/ad0s3a: FREE BLK COUNT(S) WRONG IN SUPERBLK (SALVAGED)
/dev/ad0s3a: SUMMARY INFORMATION BAD (SALVAGED)
/dev/ad0s3a: BLK(S) MISSING IN BIT MAPS (SALVAGED)
/dev/ad0s3a: 2378 files, 78670 used, 175145 free (441 frags, 21838 blocks, 0.2%
fragmentation)
/dev/ad0s3e: DEFER FOR BACKGROUND CHECKING
/dev/ad0s3d: DEFER FOR BACKGROUND CHECKING
WARNING: /usr was not properly dismounted
WARNING: /var was not properly dismounted
/var: mount pending error: blocks 4 files 1
Setting hostname: sesame.cam.watson.org.
bge0: link state changed to DOWN
bge0: no link ....bge0: link state changed to UP

...

/dev/ad0s3a on / (ufs, local, read-only)
devfs on /dev (devfs, local)
/dev/ad0s3e on /usr (ufs, local, soft-updates)
/dev/ad0s3d on /var (ufs, local, soft-updates)
/dev/md0 on /tmp (ufs, local)

The rc scripts helpfully mounted an MFS /tmp for me, which while friendly, 
succeeded in masking the problem and allowing the system to come up in a 
rather undesirable state (from my perspective).  So it sounds like maybe / 
wasn't remounted properly, and then the scripts were too helpful thinking 
it was a diskless system.

Robert N M Watson
Received on Fri Dec 02 2005 - 09:42:03 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:48 UTC