Root and /usr fsck okay but cannot mount read/write

[Fred Noz]

After a reboot, the / and /usr filesystems are mounted read-only.
However, dropping into single-user mode and running fsck on them
shows their state to be okay. Neither attempting to remount them
or reboot puts them back into read/write. Here are the details:

Netra X1 running Solaris 8. The disk containing / and /usr is
mirrored using Solstice Disk Suite. Metastat shows the mirrors to be
Okay. The mount command shows:
/ on /pseudo/md@0:0,10,blk read/write/setuid/dev=154000a on Wed Dec 31
19:00:00 1969
/usr on /dev/md/dsk/d60 read
only/setuid/intr/largefiles/onerror=panic/dev=154003c on Sun Nov 10
20:39:50 2002
/proc on /proc read/write/setuid/dev=3f80000 on Sun Nov 10 20:39:52
2002
/dev/fd on fd read/write/setuid/dev=4040000 on Sun Nov 10 20:39:56
2002
/etc/mnttab on mnttab read/write/setuid/dev=4100000 on Sun Nov 10
20:39:59 2002
/var on /dev/md/dsk/d50
read/write/setuid/intr/largefiles/onerror=panic/dev=1540032 on Sun Nov
10 20:40:00 2002
/var/run on swap read/write/setuid/dev=1 on Sun Nov 10 20:40:00 2002

Although mount shows "read/write" for / it is read-only. After
running
"init S" to go into single-user mode, I run fsck on /dev/md/rdsk/d10
(the device for /) and on /dev/md/rdsk/d60 (device for /usr) and there
are no errors. Running fsck -m shows:
ufs fsck: sanity check: /dev/md/dsk/d10 okay
"fsck -o f,p /dev/md/dsk/d60" shows that /usr is okay also.

After rebooting, / and /usr are mounted read-only again. Attempts
to remount read/write using:
mount -o rw,remount /dev/md/dsk/d10 /
shows
mount: the state of /dev/md/dsk/d10 is not okay
and it was attempted to be mounted read/write
mount: Please run fsck and try again
Attempting this for /dev/md/dsk/d60 gives the same message.
Running fsck and trying again does not help.

The Netra X1 does not have a CD ROM drive nor floppy. I do not
have a Jumpstart server on my network.

How can I get Solaris to mark these filesystems okay and mount them
read-write? Thank you.

- Fred

[Anthony Mandic]

Fred Noz wrote:
>
> After a reboot, the / and /usr filesystems are mounted read-only.
> However, dropping into single-user mode and running fsck on them
> shows their state to be okay. Neither attempting to remount them
> or reboot puts them back into read/write.

There was a similar thread here around the tail end of August.
Try a Google search. The Subject was "Interesting metadb paradox".

-am © 2002

[Frank Batschulat]

Thats sounds a lot like bug:

4392663 ufs mount fails when the timestamp on the filesystem overflows 31bits

this has just been patched back onto the latest S8 KU 108528-17.

Did the TOD battery of your netra just died recently ? this can
lead to incorrect timestamps on the FS superblock.

frankB

[Fred Noz]

Frank, you are absolutely right. After the system had booted and
could not mount the filesystems properly, I noticed the date was
wacky. I set it back to the correct date and "fsck -y" all my
filesystems, except for / and /usr. I just noticed that the date on
my root directory is Apr 1 1908 and a core file in / is Mar 31 1908!

I will install this kernel update on my other systems right away. How
can I correct the FS timestamps on my / and /usr filesystems so I can
get this system working again? As my Netra has no CD-ROM and I don't
have a jumpstart server, the only thing I can think of is to
temporarily attach the drives to another Netra I have and fsck from
there.

Thank you.

- Fred

Frank Batschulat <frank.ba...@IHATESPAM.Sun.COM> wrote in message news:<3DD5626C...@IHATESPAM.Sun.COM>...

[Frank Batschulat]

Fred Noz wrote:
>
> I will install this kernel update on my other systems right away. How
> can I correct the FS timestamps on my / and /usr filesystems so I can
> get this system working again? As my Netra has no CD-ROM and I don't

fsck itself can not fix this problem,
the only gross hack I know of as a workaround is the following:

!! Note, this is provided with no guarantee, no accident insurance and
!! if you do this it's on your own risk !

The workaround actually suggests that 'dd' and 'adb' to be used. Here's how:
Lets say /space is mounted on /dev/dsk/c0t0d0s7. (This is the filesystem
on which the timestamp has overflowed)
Step 1. dd if=/dev/rdsk/c0t0d0s7 of=/tmp/z bs=8192 skip=1 count=1

Step 2. adb -w /tmp/z
0x538?X
538: fc269878
0x538?W 0
538: 0xfc269878 = 0x0
0x538?X
538: 0
$q

Step 3. dd if=/tmp/z of=/dev/rdsk/c0t0d0s7 bs=8192 oseek=1 count=1

Step 4. fsck /dev/rdsk/c0t0d0s7

Step 5. mount /dev/dsk/c0t0d0s7 /space
The above mount will succeed.

frankB

[Scott Howard]

Fred Noz <Fr...@noz.net> wrote:
> I will install this kernel update on my other systems right away. How
> can I correct the FS timestamps on my / and /usr filesystems so I can
> get this system working again? As my Netra has no CD-ROM and I don't
> have a jumpstart server, the only thing I can think of is to
> temporarily attach the drives to another Netra I have and fsck from
> there.

If you can attach the disk to another system I'd suggest doing something
like this :
1. Patch the new system with this patch.
2. Connect the problem disk to this system, fsck it, and mount it as /a (which
should work as the machine you're mounting it on has been patched)
3. Do the same for /usr on this disk, mounting it under /a/usr.
4. Same again for /var if it's on it's own partition.
5. Using "patchadd -R /a" apply the patch to the "problem" disk.
6. Shut everydown down, and remove the disk
7. Connect the disk back to the original machine, and it should boot OK.

The other option is just to mount it readonly, back it up, then newfs
the partitions and restore the backup!

Note that this is off the top of my head and has not been tested - use at
your own risk!

Scott