As usual, the list comes through with flying colors! Thanks to those who've
responded so far:
Chentil Kumar <email@example.com>
Jochen Fritz <firstname.lastname@example.org>
David Mitchell <email@example.com>
Charles Gagnon <firstname.lastname@example.org>
Susan Thielen <email@example.com>
Thomas Leavitt <firstname.lastname@example.org>
Sean Ward <email@example.com>
David Lee <T.D.Lee@durham.ac.uk>
Dieter Gobbers <firstname.lastname@example.org>
Kevin M. Woods <email@example.com>
Sean Wilcox <firstname.lastname@example.org>
Matthew Sams <email@example.com>
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
>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.
>cp /vfstab /etc/vfstab
>edit vfstab & make the appropriate entries.
>ok boot disk1(Gotta create a devalias if needed)
>Now this should work fine.
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: firstname.lastname@example.org 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