SUMMARY Root partition not writable on Ultra

From: Bill Fenwick (
Date: Thu Jul 17 1997 - 12:28:29 CDT

As usual, the list comes through with flying colors! Thanks to those who've
responded so far:

Chentil Kumar <>
Jochen Fritz <>
David Mitchell <>
Charles Gagnon <>
Susan Thielen <>
Thomas Leavitt <>
Sean Ward <>
David Lee <>
Dieter Gobbers <>
Kevin M. Woods <>
Sean Wilcox <>
Matthew Sams <>

My original question was:

>A client of ours has an Ultra 2 running Solaris 2.5.1 . Yesterday, a system
>administrator noted that the root partition was full, could not find anything
>that was causing it to get filled up, and decided to move root to a larger
>partition. As you can guess, disaster ensued.
>The situation now is that, thanks to a very messed-up vfstab file, both the
>"old" root partition and the "new" root partition are attempting to be mounted
>as /, and the result is that whichever one is making it is coming up read-only.
>Thus, we can't fix the vfstab file or anything else. Attempts to boot the
>machine in single-user mode are also failing, with some sort of message about
>"can't change mnttab"... presumably 'cause it's read-only.
>If there were a Solaris CD there, we could presumably solve the problem by
>booting from it and mounting the appropriate partition somewhere else to make
>changes... but of course, there isn't. They'll have one tomorrow, but in the
>meantime, does anyone know of a way around this problem, i.e. some way we can
>get into the system, force changes to vfstab (or force it to boot only the old
>root partition and NOT the new one, and boot up rw), and then reboot the
>new/restored system? Or are we hosed without the CD?

Several suggested mounting the root partition with the "remount,rw" option.
 Here's what worked for us:

mount -F ufs -m -o remount,rw /dev/dsk/c0t0d0s0

"-m" may not have been necessary. It tells the mount command not to put an
entry into /etc/mnttab, and since that file was on the non-writable root
partition, I thought it better not to try writing to it.

Then we were able to edit vfstab, remove the conflict, and reboot happily.

Chenthil passed along a procedure which we didn't have to use, but in case
anyone runs into a similar situation and gets even more hosed than we were, I'll
reproduce it below:

>Do A STOP+A. At the OK prompt
>do these
>ok boot -rsw
>Enter the passwd(root) & get on to the #prompt.
>Then mount the new disk where U have the new root partition say
>/dev/dsk/c0t1d0s0 on /mnt.
>cd /mnt.
>cp /vfstab /etc/vfstab
>edit vfstab & make the appropriate entries.
>cd /
>umount /mnt.
>ok boot disk1(Gotta create a devalias if needed)
>Now this should work fine.

Other suggestions:

boot -as at the ok prompt to boot the system interactively
boot -b to bypass the bootup scripts
use eeprom to boot from a spare disk (we didn't have one, oh well)

And there were a couple suggestions to make a bootable backup, jumpstart server,
etc. to handle this situation in the future. Believe me, on my next
installation, that will be a priority!

Thanks again to those who responded!

Bill Fenwick                                     Email:
Digicomp Research                                Voice:  (607) 273-5900 ext 32

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:59 CDT