Date: Fri, 2 Dec 2005 10:41:59 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: current@FreeBSD.org Subject: After crash, / comes up mounted read-only, but in multiuser; mfs /tmp? Message-ID: <20051202103751.T83839@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051202103751.T83839>