THIS IS A FOLLOWUP TO A SUMMARY I POSTED YESTERDAY.
Nevander Holland <nevander@morse.co.uk> sent me some very interesting
information:
-----------------------------------------------------------------------------
The true solution is that the system wasnt built for that purpose. In the
original spec for the ULTRA1, it could handle 2 2.1G disks or 1 4.2g
internally, unless you did a workaround as stated. This is referring to the
1995 specifications. I would be very conscious of data integrity on the
2.1g disks
-----------------------------------------------------------------------------
I spoke to Sun technical support several times (several different people) and
was very clear about my intentions to install a 4.2GB and 2.1GB drives
internally, and noone mentioned this problem. I will try to find out
whether this 1995 spec is still the case (and I will do some testing
with my 2.1GB drive!). Thanks again Nevander.
Dave
foster@bial1.ucsd.edu wrote:
> ORIGINAL PROBLEM:
> ----------------
>
> Could not install new 4.2GB drive in Ultra. It insisted on being in
> slot 0, so I had to move the original system disk to slot 1.
> After:
>
> 1. Installing 4.2GB disk in slot 0, original 2.1GB disk in slot 1.
> 2. Modifying /etc/vfstab to reflect new SCSI target #1
> 3. boot disk1 -r
>
> I would always get an error about not being able to mount /usr, and the
> system would not boot up.
>
> There is a summary in the Sun Manager's Archives (Jan 98) entitled
> "SUMMARY: adding a disk to an Ultra1" that suggests a workaround,
> but this would have been almost as much work as my solution...
>
> SOLUTION:
> --------
>
> Here's a skeleton summary of what I ended up doing:
>
> 1. back up the 2.1GB system disk using a nifty script (ufsdump)
> 2. install the 4.2GB disk in slot 0 and the 2.1GB disk in slot 1
> 3. use format to partition the 4.2GB disk as my new system disk
> 4. restoring the system onto the 4.2GB disk (ufsrestore)
> 5. boot -r (from new 4.2GB disk)
> 6. re-partitioning the 2.1GB disk as swap and "extra room"
>
> [email me if you want more details of what I did]
>
> What a royal pain-in-the-butt! The solutions I received would not work;
> most suggested either "boot disk1 -r" (after moving 2.1GB->slot1) or
> "boot cdrom -sw", but neither of these update the device files. The
> first fails because, as I learned in the summary referred to above,
> you can't update the device files when the "new" device you need to
> configure is the boot disk! And booting from cdrom fails because
> drvconfig *insists* on writing to /etc/path_to_inst, which obviously
> fails on the CDROM; this prevents the device files from being updated.
>
> There is also another SUMMARY (May 1997) entitled
>
> "SUMMARY: Swapping disks between systems"
>
> that looked like it would be helpful (an assortment of suggestions
> involving drvconfig, devlinks, disks, updating path_to_inst, and
> copying device files from the mini-root after booting from CDROM).
> NONE of these solutions worked.
>
> I can't believe that there is no other solution, but I did not receive
> any from the list or other resources (newsgroups, FAQs, Sun tech. support).
> If anyone knows of other solutions, PLEASE post them so noone else has
> to endure this problem!
>
> Thank-you to everyone who took their precious time to answer my post!
>
> HERE IS MY ORIGINAL POST:
> ------------------------
>
> Hello Managers!
>
> I am very stuck, please tell me what I have done wrong or forgotten!
>
> TASK: Install new 4.2GB disk in Ultra1 (Solaris 2.5 with Rec. Patches)
>
> PROBLEM:
>
> The 4.2GB disk will only fit in slot 0, so the system disk (2.1GB) must be
> moved to slot 1. Here are the steps I took:
>
> 1. Modified /etc/vfstab and changed SCSI targets from 0 to 1
> (c0t0d0s? to c0t1d0s?) for all partitions on 2.1GB disk.
> 2. Installed 4.2GB disk in slot0, and 2.1GB disk in slot1.
> 3. boot cdrom -rsw
> 4. boot disk1
>
> The error message I get is:
>
> mount:/dev/dsk/c0t1d0s1 or /usr, no such file or directory
>
> PRTCONF shows that the devices are "attached", and it looks like the
> appropriate device files are in /dev/dsk. Can someone *please* tell
> me what I have left out? (Even flames are welcome at this point!)
>
> HERE ARE THE SUGGESTIONS:
> ------------------------
>
> [levinson@ll.mit.edu]
>
> Did you boot disk1 -r to rebuild it's /dev and /devices? I notice you did
> under the cdrom but your post does not indicate for the boot to the system
> disk.
>
> ----------------------------------------------------------------------------
>
> [Darren Dunham : ddunham@taos.com]
>
> If you can remount it (possibly back on 0) you might try adding an
> explicit argument in /etc/system for the root drive. It's normally
> commented out in default configurations.
>
> ----------------------------------------------------------------------------
>
> [Shubin Wang : shubin@brain2.nida.nih.gov]
>
> It's seems you did everything OK, but did you tried following
> commands before you reboot the machine?
>
> # touch /reconfigure
> # boot -r
> or
> # drvconfig
> # disks
>
> I saw a Summary posted on the list a couple weeks ago about
> the same question as yours. It's on a SS20 and it seems the
> slot0 always to be SCSI ID0. Call Sun to find out if you can
> put a system disk in solt 1.
> Good luck!
>
> -----------------------------------------------------------------------------
>
> [Christian Masopust : Christian.Masopust@tmn.sie.siemens.at]
>
> I think you forgot to reboot from disk1 with -r. boot cdrom -rsw isn't really
> necessary, but 'boot disk1 -r' (and you should set your boot-device to disk1 too)
> is absolutly necessary...
>
> -----------------------------------------------------------------------------
>
> [David Thorburn-Gundlach : david@bae.uga.edu]
>
> This is exactly like a problem that came up recently. Check the
> archives for 1998 (I think it was in January) for keywords similar to
> your problem to see what the other fellow did.
>
> -----------------------------------------------------------------------------
>
> [Chuck Simpson : csimpson@zeltech.com]
>
> Try "boot disk1 -r"
> Its just a hunch...
>
> -----------------------------------------------------------------------------
>
> [Mike Salehi : mrs@cadem.mc.xerox.com]
>
> I think ultra ignores scsi id and the id is based on position. so you need
> to modify
> your vfstab and probably your devaliases in eeprom.
>
> -------- END ----------------------------------------------------------------
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> David S. Foster Univ. of California, San Diego
> Programmer/Analyst Brain Image Analysis Laboratory
> foster@bial1.ucsd.edu Department of Psychiatry
> (619) 622-5892 8950 Via La Jolla Drive, Suite 2240
> La Jolla, CA 92037
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
******************************************************
Nevander Holland Morse Group Ltd
Systems Engineer Waterside House
11 Boston Business Park
Tel: +44 (0)181 8138100 Trumpers Way
Fax: +44 (0)181 5744567 Hanwell
London W7 2QA
mailto:nevander.holland@morse.co.uk
******************************************************
----- End Included Message -----
--Boundary_(ID_tft0mjzvRaOxArjjrjng+Q)
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
X-Sun-Charset: us-ascii
X-Sun-Data-type: html
X-Sun-Encoding-info: 7bit
The true solution is that the system wasnt built fot that purpose. In the
original spec
for the ULTRA1,it could handle 2 2.1G disks or 1 4.2g internally, unless
you did a workaround as stated.
This is referring to the 1995 specifications. I would be very conscious
of data integrity on the 2.1g disks
foster@bial1.ucsd.edu wrote:
ORIGINAL PROBLEM:
----------------
Could not install new 4.2GB drive in Ultra. It insisted on being
in
slot 0, so I had to move the original system disk to slot 1.
After:
1. Installing 4.2GB disk
in slot 0, original 2.1GB disk in slot 1.
2. Modifying /etc/vfstab
to reflect new SCSI target #1
3. boot disk1 -r
I would always get an error about not being able to mount /usr,
and the
system would not boot up.
There is a summary in the Sun Manager's Archives (Jan 98) entitled
"SUMMARY: adding a disk to an Ultra1" that suggests a workaround,
but this would have been almost as much work as my solution...
SOLUTION:
--------
Here's a skeleton summary of what I ended up doing:
1. back up the 2.1GB system disk using a nifty
script (ufsdump)
2. install the 4.2GB disk in slot 0 and the
2.1GB disk in slot 1
3. use format to partition the 4.2GB disk
as my new system disk
4. restoring the system onto the 4.2GB disk
(ufsrestore)
5. boot -r (from new 4.2GB disk)
6. re-partitioning the 2.1GB disk as swap
and "extra room"
[email me if you want more
details of what I did]
What a royal pain-in-the-butt! The solutions I received
would not work;
most suggested either "boot disk1 -r" (after moving 2.1GB->slot1)
or
"boot cdrom -sw", but neither of these update the device
files. The
first fails because, as I learned in the summary referred
to above,
you can't update the device files when the "new" device
you need to
configure is the boot disk! And booting from cdrom fails
because
drvconfig *insists* on writing to /etc/path_to_inst, which
obviously
fails on the CDROM; this prevents the device files from
being updated.
There is also another SUMMARY (May 1997) entitled
"SUMMARY: Swapping disks
between systems"
that looked like it would be helpful (an assortment of
suggestions
involving drvconfig, devlinks, disks, updating path_to_inst,
and
copying device files from the mini-root after booting
from CDROM).
NONE of these solutions worked.
I can't believe that there is no other solution, but I
did not receive
any from the list or other resources (newsgroups, FAQs,
Sun tech. support).
If anyone knows of other solutions, PLEASE post them so
noone else has
to endure this problem!
Thank-you to everyone who took their precious time to answer
my post!
HERE IS MY ORIGINAL POST:
------------------------
Hello Managers!
I am very stuck, please tell me what I have done wrong or forgotten!
TASK: Install new 4.2GB disk in Ultra1 (Solaris 2.5 with Rec. Patches)
PROBLEM:
The 4.2GB disk will only fit in slot 0, so the system disk (2.1GB)
must be
moved to slot 1. Here are the steps I took:
1. Modified /etc/vfstab and
changed SCSI targets from 0 to 1
(c0t0d0s?
to c0t1d0s?) for all partitions on 2.1GB disk.
2. Installed 4.2GB disk
in slot0, and 2.1GB disk in slot1.
3. boot cdrom -rsw
4. boot disk1
The error message I get is:
mount:/dev/dsk/c0t1d0s1 or
/usr, no such file or directory
PRTCONF shows that the devices are "attached", and it looks like the
appropriate device files are in /dev/dsk. Can someone *please* tell
me what I have left out? (Even flames are welcome at this point!)
HERE ARE THE SUGGESTIONS:
------------------------
[levinson@ll.mit.edu]
Did you boot disk1 -r to rebuild it's /dev and /devices?
I notice you did
under the cdrom but your post does not indicate for the boot to the
system
disk.
----------------------------------------------------------------------------
[Darren Dunham : ddunham@taos.com]
If you can remount it (possibly back on 0) you might try adding an
explicit argument in /etc/system for the root drive. It's normally
commented out in default configurations.
----------------------------------------------------------------------------
[Shubin Wang : shubin@brain2.nida.nih.gov]
It's seems you did everything OK, but did you tried following
commands before you reboot the machine?
# touch /reconfigure
# boot -r
or
# drvconfig
# disks
I saw a Summary posted on the list a couple weeks ago about
the same question as yours. It's on a SS20 and it seems the
slot0 always to be SCSI ID0. Call Sun to find out if you can
put a system disk in solt 1.
Good luck!
-----------------------------------------------------------------------------
[Christian Masopust : Christian.Masopust@tmn.sie.siemens.at]
I think you forgot to reboot from disk1 with -r. boot cdrom -rsw isn't
really
necessary, but 'boot disk1 -r' (and you should set your boot-device
to disk1 too)
is absolutly necessary...
-----------------------------------------------------------------------------
[David Thorburn-Gundlach : david@bae.uga.edu]
This is exactly like a problem that came up recently. Check the
archives for 1998 (I think it was in January) for keywords similar
to
your problem to see what the other fellow did.
-----------------------------------------------------------------------------
[Chuck Simpson : csimpson@zeltech.com]
Try "boot disk1 -r"
Its just a hunch...
-----------------------------------------------------------------------------
[Mike Salehi : mrs@cadem.mc.xerox.com]
I think ultra ignores scsi id and the id is based on position.
so you need
to modify
your vfstab and probably your devaliases in eeprom.
-------- END ----------------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
David S. Foster
Univ. of California, San Diego
Programmer/Analyst
Brain Image Analysis Laboratory
foster@bial1.ucsd.edu Department of
Psychiatry
(619) 622-5892
8950 Via La Jolla Drive, Suite 2240
La Jolla, CA 92037
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
******************************************************
Nevander Holland Morse Group Ltd
Systems Engineer Waterside House
11 Boston Business Park
Tel: +44 (0)181 8138100 Trumpers Way
Fax: +44 (0)181 5744567 Hanwell
London W7 2QA
mailto:nevander.holland@morse.co.uk
******************************************************
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
David S. Foster Univ. of California, San Diego
Programmer/Analyst Brain Image Analysis Laboratory
foster@bial1.ucsd.edu Department of Psychiatry
(619) 622-5892 8950 Via La Jolla Drive, Suite 2240
La Jolla, CA 92037
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--Boundary_(ID_tft0mjzvRaOxArjjrjng+Q)--