Root partition not writable on Ultra
2007-12-25 10:53:00
responded so far:
Chentil Kumar <chenthil@mtcts1.mt.lucent.com>
Jochen Fritz <jfritz@steptools.com>
David Mitchell <davem@fdgroup.co.uk>
Charles Gagnon <charlesg@nynexst.com>
Susan Thielen <thielen@irus.rri.uwo.ca>
Thomas Leavitt <leavitt@webcom.com>
Sean Ward <seanw@amgen.com>
David Lee <T.D.Lee@durham.ac.uk>
Dieter Gobbers <gobbers@faw.uni-ulm.de>
Kevin M. Woods <kev@emf.net>
Sean Wilcox <shadow6@bellsouth.net>
Matthew Sams <maclean@hasc.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
>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.
>halt
>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: fenwick@digicomp.com
Digicomp Research Voice: (607) 273-5900 ext 32
Comments
Got something to say?
You must be logged in to post a comment.
