I sent this to just comp.sys.sun.hardware a few mins ago. Ignore that -
it was not tee most appropriate place.







I received today a couple of 147 GB FC-AL disks that I want to put in my
Blade 2000 and replace the 73 GB disks. One disk was no problem, but the
boot disk is presenting me problem. All I basically want to do is remove
the old 75 GB boot disk, copy the data to a 147 GB disk and boot from that.


The machine originally booted from a 19 GB partition on the 73 GB disk,
with a 40 GB partition on the disk too:


Filesystem size used avail capacity Mounted on
/dev/dsk/c1t1d0s0 19G 7.1G 12G 38% /
/dev/dsk/c1t1d0s3 40G 18G 22G 46% /usr/local



1) Put the new disk into the machine at SCSI ID=2 (upper slot)
2) Run format and labled the disk
3) Partitioned the disk similar to above, with a 19 GB rook partition, 8
GB of swap and the remainder (about 105 GB or so) as /usr/local

3) Made file systems
# newfs /dev/rdsk/c1t2d0s0
# newfs /dev/rdsk/c1t2d0s3


3) Mounted the new file system /dev/dsk/c1t2d0s0 on the mount point /mnt.

# mount /dev/dsk/c1t2d0s0 /mnt

4) Copied the root file system from the old disk to the new one

# ufsdump 0f - / | ( cd /mnt ;ufsrestore xf - )


5) Installed the boot block
installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c1t2d0s0


6)shut down

7) Moved the new 147 GB disk which was in SCSI ID 2, into 1 - obviously
removing the old boot disk first!!!!.

Since the machine booted from SCSI ID 1 before, I assumed it would boot
from this new larger disk,


8) When I switch on, instead of booting it prints

"The file just loaded does not appear to be executable"

I then came to the conclusion it was not attempting to read from the
disk at all.

9) Typing at the ok promt

ok> boot disk


causes it to try to boot. It never actually succeeds to give a login
prompt, but it knows the host name, says networking is up etc.

I suspect boot -r may have been better than a normal boot here. Perhaps
that is my problem.


Looking in the EEPROM I see:

boot-device=/pci@8,600000/SUNW,qlc@4/fp@0,0/disk@w21000004cfa13aed,0:a
/pci@8,60

I think that is a very specific boot device - possiblly specific to the
original disk? Clearly it has some information which looks like serial
number or similar - far more than the controller, scsi id and partition.
I assume I am supposed to reset boot-device - is that correct? If so,
what do I set it to?

Anything I have forgotten, which may have caused this to
a) Not find the disk at all unless I tell it to 'boot disk'
b) Fail to boot properly, even though it does try, so clearly has found
the boot block.

I suspect I made two mistakes

1) Did not reset EEPROM, but dont know how to
2) Did not do a reconfigure boot.


Is there anything else I have overlooked, before I have another go at this?

On Oct 19, 7:09 pm, Dave <nowh...@nowhere.com> wrote:
> I sent this to just comp.sys.sun.hardware a few mins ago. Ignore that -
> it was not tee most appropriate place.
>
> I received today a couple of 147 GB FC-AL disks that I want to put in my
> Blade 2000 and replace the 73 GB disks. One disk was no problem, but the
> boot disk is presenting me problem. All I basically want to do is remove
> the old 75 GB boot disk, copy the data to a 147 GB disk and boot from that.
>
> The machine originally booted from a 19 GB partition on the 73 GB disk,
> with a 40 GB partition on the disk too:
>
> Filesystem size used avail capacity Mounted on
> /dev/dsk/c1t1d0s0 19G 7.1G 12G 38% /
> /dev/dsk/c1t1d0s3 40G 18G 22G 46% /usr/local
>
> 1) Put the new disk into the machine at SCSI ID=2 (upper slot)
> 2) Run format and labled the disk
> 3) Partitioned the disk similar to above, with a 19 GB rook partition, 8
> GB of swap and the remainder (about 105 GB or so) as /usr/local
>
> 3) Made file systems
> # newfs /dev/rdsk/c1t2d0s0
> # newfs /dev/rdsk/c1t2d0s3
>
> 3) Mounted the new file system /dev/dsk/c1t2d0s0 on the mount point /mnt.
>
> # mount /dev/dsk/c1t2d0s0 /mnt
>
> 4) Copied the root file system from the old disk to the new one
>
> # ufsdump 0f - / | ( cd /mnt ;ufsrestore xf - )
>
> 5) Installed the boot block
> installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c1t2d0s0
>
> 6)shut down
>
> 7) Moved the new 147 GB disk which was in SCSI ID 2, into 1 - obviously
> removing the old boot disk first!!!!.
>
> Since the machine booted from SCSI ID 1 before, I assumed it would boot
> from this new larger disk,
>
> 8) When I switch on, instead of booting it prints
>
> "The file just loaded does not appear to be executable"
>
> I then came to the conclusion it was not attempting to read from the
> disk at all.
>
> 9) Typing at the ok promt
>
> ok> boot disk
>
> causes it to try to boot. It never actually succeeds to give a login
> prompt, but it knows the host name, says networking is up etc.
>
> I suspect boot -r may have been better than a normal boot here. Perhaps
> that is my problem.
>
> Looking in the EEPROM I see:
>
> boot-device=/pci@8,600000/SUNW,qlc@4/fp@0,0/disk@w21000004cfa13aed,0:a
> /pci@8,60
>
> I think that is a very specific boot device - possiblly specific to the
> original disk? Clearly it has some information which looks like serial
> number or similar - far more than the controller, scsi id and partition.
> I assume I am supposed to reset boot-device - is that correct? If so,
> what do I set it to?
>
> Anything I have forgotten, which may have caused this to
> a) Not find the disk at all unless I tell it to 'boot disk'
> b) Fail to boot properly, even though it does try, so clearly has found
> the boot block.
>
> I suspect I made two mistakes
>
> 1) Did not reset EEPROM, but dont know how to

ok> setenv boot-device disk

> 2) Did not do a reconfigure boot.
>
> Is there anything else I have overlooked, before I have another go at this?

I assume you did take care of /usr/local.


If your another go does not work, you may consider

1. Install new OS in c1t2d0s4(4GB, It would be better to use
c1t3d0s0).
2. boot disk1:e
3. mount c1t1d0s0 and c1t2d0s0, ufsdump and ufsrestore them. Do the
same for c1t1d0s3.
4. swap disks and boot disk.

Victor

Dave wrote:
> I sent this to just comp.sys.sun.hardware a few mins ago. Ignore that -
> it was not tee most appropriate place.
>
>
>
>
>
>
>
> I received today a couple of 147 GB FC-AL disks that I want to put in my
> Blade 2000 and replace the 73 GB disks. One disk was no problem, but the
> boot disk is presenting me problem. All I basically want to do is remove
> the old 75 GB boot disk, copy the data to a 147 GB disk and boot from that.
>
>
> The machine originally booted from a 19 GB partition on the 73 GB disk,
> with a 40 GB partition on the disk too:
>
>
> Filesystem size used avail capacity Mounted on
> /dev/dsk/c1t1d0s0 19G 7.1G 12G 38% /
> /dev/dsk/c1t1d0s3 40G 18G 22G 46% /usr/local
>
>
>
> 1) Put the new disk into the machine at SCSI ID=2 (upper slot)
> 2) Run format and labled the disk
> 3) Partitioned the disk similar to above, with a 19 GB rook partition, 8
> GB of swap and the remainder (about 105 GB or so) as /usr/local
>
> 3) Made file systems
> # newfs /dev/rdsk/c1t2d0s0
> # newfs /dev/rdsk/c1t2d0s3
>
>
> 3) Mounted the new file system /dev/dsk/c1t2d0s0 on the mount point /mnt.
>
> # mount /dev/dsk/c1t2d0s0 /mnt
>
> 4) Copied the root file system from the old disk to the new one
>
> # ufsdump 0f - / | ( cd /mnt ;ufsrestore xf - )
>
>
> 5) Installed the boot block
> installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c1t2d0s0
>
>
> 6)shut down
>
> 7) Moved the new 147 GB disk which was in SCSI ID 2, into 1 - obviously
> removing the old boot disk first!!!!.
>
> Since the machine booted from SCSI ID 1 before, I assumed it would boot
> from this new larger disk,
>
>
> 8) When I switch on, instead of booting it prints
>
> "The file just loaded does not appear to be executable"
>
> I then came to the conclusion it was not attempting to read from the
> disk at all.
>
> 9) Typing at the ok promt
>
> ok> boot disk
>
>
> causes it to try to boot. It never actually succeeds to give a login
> prompt, but it knows the host name, says networking is up etc.
>
> I suspect boot -r may have been better than a normal boot here. Perhaps
> that is my problem.
>
>
> Looking in the EEPROM I see:
>
> boot-device=/pci@8,600000/SUNW,qlc@4/fp@0,0/disk@w21000004cfa13aed,0:a
> /pci@8,60
>
> I think that is a very specific boot device - possiblly specific to the
> original disk? Clearly it has some information which looks like serial
> number or similar - far more than the controller, scsi id and partition.
> I assume I am supposed to reset boot-device - is that correct? If so,
> what do I set it to?

set boot-device = disk

>
> Anything I have forgotten, which may have caused this to
> a) Not find the disk at all unless I tell it to 'boot disk'
> b) Fail to boot properly, even though it does try, so clearly has found
> the boot block.
>
> I suspect I made two mistakes
>
> 1) Did not reset EEPROM, but dont know how to
> 2) Did not do a reconfigure boot.
>
>
> Is there anything else I have overlooked, before I have another go at this?

I had the same problems as you are having when I first started to clone a boot
drive for a Blade 1000. As you have discovered these drives work different
than scsi drives. My notes to clone a Blade 1000/2000 disk drive:

Blade 1000/2000 disk drive clone notes
After cloning the harddrive do the following:
1. mv /a/etc/path_to_inst /a/etc/path_to_inst.original
2. rm /a/etc/path_to_inst.old
3. devfsadm -v -C -r /a
Then try to boot. If boot fails then take note as to what
file system can't be fsck'd, boot net (or cd/dvd), mount disk on /a,
and edit /a/etc/vfstab to point to whatever location the
fsck was complaining about.
The diskdrives on the Blade 1000/2000 seem to magically change
from /dev/dsk/c0t1d0s0 to /dev/dsk/c1t0d0s0 to /dev/dsk/c0t0d0s0
to whatever...


--
----------------------------------
Randy Jones
E-Mail: randy@jones.tri.net
----------------------------------

On Oct 20, 11:49 am, Randy Jones <ra...@jones.tri.net> wrote:
> Dave wrote:
> > I sent this to just comp.sys.sun.hardware a few mins ago. Ignore that -
> > it was not tee most appropriate place.
>
> > I received today a couple of 147 GB FC-AL disks that I want to put in my
> > Blade 2000 and replace the 73 GB disks. One disk was no problem, but the
> > boot disk is presenting me problem. All I basically want to do is remove
> > the old 75 GB boot disk, copy the data to a 147 GB disk and boot from that.
>
> > The machine originally booted from a 19 GB partition on the 73 GB disk,
> > with a 40 GB partition on the disk too:
>
> > Filesystem size used avail capacity Mounted on
> > /dev/dsk/c1t1d0s0 19G 7.1G 12G 38% /
> > /dev/dsk/c1t1d0s3 40G 18G 22G 46% /usr/local
>
> > 1) Put the new disk into the machine at SCSI ID=2 (upper slot)
> > 2) Run format and labled the disk
> > 3) Partitioned the disk similar to above, with a 19 GB rook partition, 8
> > GB of swap and the remainder (about 105 GB or so) as /usr/local
>
> > 3) Made file systems
> > # newfs /dev/rdsk/c1t2d0s0
> > # newfs /dev/rdsk/c1t2d0s3
>
> > 3) Mounted the new file system /dev/dsk/c1t2d0s0 on the mount point /mnt.
>
> > # mount /dev/dsk/c1t2d0s0 /mnt
>
> > 4) Copied the root file system from the old disk to the new one
>
> > # ufsdump 0f - / | ( cd /mnt ;ufsrestore xf - )
>
> > 5) Installed the boot block
> > installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c1t2d0s0
>
> > 6)shut down
>
> > 7) Moved the new 147 GB disk which was in SCSI ID 2, into 1 - obviously
> > removing the old boot disk first!!!!.
>
> > Since the machine booted from SCSI ID 1 before, I assumed it would boot
> > from this new larger disk,
>
> > 8) When I switch on, instead of booting it prints
>
> > "The file just loaded does not appear to be executable"
>
> > I then came to the conclusion it was not attempting to read from the
> > disk at all.
>
> > 9) Typing at the ok promt
>
> > ok> boot disk
>
> > causes it to try to boot. It never actually succeeds to give a login
> > prompt, but it knows the host name, says networking is up etc.
>
> > I suspect boot -r may have been better than a normal boot here. Perhaps
> > that is my problem.
>
> > Looking in the EEPROM I see:
>
> > boot-device=/pci@8,600000/SUNW,qlc@4/fp@0,0/disk@w21000004cfa13aed,0:a
> > /pci@8,60
>
> > I think that is a very specific boot device - possiblly specific to the
> > original disk? Clearly it has some information which looks like serial
> > number or similar - far more than the controller, scsi id and partition.
> > I assume I am supposed to reset boot-device - is that correct? If so,
> > what do I set it to?
>
> set boot-device = disk
>
>
>
> > Anything I have forgotten, which may have caused this to
> > a) Not find the disk at all unless I tell it to 'boot disk'
> > b) Fail to boot properly, even though it does try, so clearly has found
> > the boot block.
>
> > I suspect I made two mistakes
>
> > 1) Did not reset EEPROM, but dont know how to
> > 2) Did not do a reconfigure boot.
>
> > Is there anything else I have overlooked, before I have another go at this?
>
> I had the same problems as you are having when I first started to clone a boot
> drive for a Blade 1000. As you have discovered these drives work different
> than scsi drives. My notes to clone a Blade 1000/2000 disk drive:
>
> Blade 1000/2000 disk drive clone notes
> After cloning the harddrive do the following:
> 1. mv /a/etc/path_to_inst /a/etc/path_to_inst.original
> 2. rm /a/etc/path_to_inst.old
> 3. devfsadm -v -C -r /a
> Then try to boot. If boot fails then take note as to what
> file system can't be fsck'd, boot net (or cd/dvd), mount disk on /a,
> and edit /a/etc/vfstab to point to whatever location the
> fsck was complaining about.
> The diskdrives on the Blade 1000/2000 seem to magically change
> from /dev/dsk/c0t1d0s0 to /dev/dsk/c1t0d0s0 to /dev/dsk/c0t0d0s0
> to whatever...
>
> --
> ----------------------------------
> Randy Jones
> E-Mail: ra...@jones.tri.net
> ----------------------------------- Hide quoted text -
>
> - Show quoted text -

from ok prompt

boot -rvs,

this will boot to single user mode with verbose andreconfigure
options. The will giv you exact problem by which it is gettig strucked.

On 2007-10-20, Dave <nowhere@nowhere.com> wrote:

> I think that is a very specific boot device - possiblly specific to the
> original disk?

It is. FC/AL disks have a unique number - the WWN - World Wide Number. You have
to set that number in the boot device and in path_to_inst.

For example, here's my boot device entry in the eeprom;

boot-device=/pci@8,600000/SUNW,qlc@4/fp@0,0/disk@w21000000871a2049,0:a disk net

You can find out the WWN by putting the disk in the machine, with it booted from
the disk that works and using "luxadm probe -p"

[huge@anubis ~]: luxadm probe -p
No Network Array enclosures found in /dev/es

Found Fibre Channel device(s):
Node WWN:20000000871a2049 Device Typeisk device
Logical Path:/dev/rdsk/c1t1d0s2
Physical Path:
/devices/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w21000000871a2049,0:c,raw
Node WWN:2000000c507aa7f2 Device Typeisk device
Logical Path:/dev/rdsk/c1t2d0s2
Physical Path:
/devices/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w2100000c507aa7f2,0:c,raw
[huge@anubis ~]:

The "Physical path" bit is what you need, only change "ssd@..." to "disk@..."
(dunno why, you just need to)

You may need to change "path_to_inst", too.

> I assume I am supposed to reset boot-device - is that correct? If so,
> what do I set it to?

You should be able to work it out from the above...


--
"Be thankful that you have a life, and forsake your vain
and presumptuous desire for a second one."
[email me at huge {at} huge (dot) org <dot> uk]

On 2007-10-20, Dave <nowhere@nowhere.com> wrote:

> I received today a couple of 147 GB FC-AL disks that I want to put in my
> Blade 2000 and replace the 73 GB disks.

Dave,

You're welcome to drop me a private email about this, if you want. Email address
in my .sig.

--
"Be thankful that you have a life, and forsake your vain
and presumptuous desire for a second one."
[email me at huge {at} huge (dot) org <dot> uk]

In <ffceqi$rd$4@anubis.demon.co.uk> Huge wrote:
> On 2007-10-20, Dave <nowhere@nowhere.com> wrote:
>
>> I think that is a very specific boot device - possiblly specific to
>> the original disk?
>

<...>
>
> The "Physical path" bit is what you need, only change "ssd@..." to
> "disk@..." (dunno why, you just need to)
>

Because "ssd" is a driver alias maintained by the OS - the OBP doesn't
know this, but it does understand "disk".

On 2007-10-20, Ken Gray <see-sig-for-address@nowhere.invalid> wrote:
> In <ffceqi$rd$4@anubis.demon.co.uk> Huge wrote:
>> On 2007-10-20, Dave <nowhere@nowhere.com> wrote:
>>
>>> I think that is a very specific boot device - possiblly specific to
>>> the original disk?
>>
>
><...>
>>
>> The "Physical path" bit is what you need, only change "ssd@..." to
>> "disk@..." (dunno why, you just need to)
>>
>
> Because "ssd" is a driver alias maintained by the OS - the OBP doesn't
> know this, but it does understand "disk".

Thank you.


--
"Be thankful that you have a life, and forsake your vain
and presumptuous desire for a second one."
[email me at huge {at} huge (dot) org <dot> uk]

"Dave" <nowhere@nowhere.com> wrote in message news:47194738@212.67.96.135...
> Is there anything else I have overlooked, before I have another go at
this?

http://www.sunshack.org/data/sh/2.1/...doc/40133.html

Trinean

Trinean wrote:
> "Dave" <nowhere@nowhere.com> wrote in message news:47194738@212.67.96.135...
>> Is there anything else I have overlooked, before I have another go at
> this?
>
> http://www.sunshack.org/data/sh/2.1/...doc/40133.html
>
> Trinean
>
>

Thanks everyone. I *finally* got there:

Filesystem size used avail capacity Mounted on
/dev/dsk/c1t1d0s0 19G 7.1G 12G 38% /
/devices 0K 0K 0K 0% /devices
ctfs 0K 0K 0K 0% /system/contract
proc 0K 0K 0K 0% /proc
mnttab 0K 0K 0K 0% /etc/mnttab
swap 14G 1.4M 14G 1% /etc/svc/volatile
objfs 0K 0K 0K 0% /system/object
/platform/sun4u-us3/lib/libc_psr/libc_psr_hwcap1.so.1
19G 7.1G 12G 38%
/platform/sun4u-us3/lib/libc_psr.so.1
/platform/sun4u-us3/lib/sparcv9/libc_psr/libc_psr_hwcap1.so.1
19G 7.1G 12G 38%
/platform/sun4u-us3/lib/sparcv9/libc_psr.so.1
fd 0K 0K 0K 0% /dev/fd
swap 14G 1.1M 14G 1% /tmp
swap 14G 40K 14G 1% /var/run
/dev/dsk/c2t3d0s2 67G 64G 2.9G 96% /mnt
/dev/dsk/c1t2d0s7 135G 64G 70G 48% /export/home
/dev/dsk/c1t1d0s3 108G 18G 88G 18% /usr/local
/vol/dev/dsk/c0t6d0/l
622M 622M 0K 100% /cdrom/l


but not without a lot of hassles.

I was getting close at some points to thinking it would be easier to
reinstall the OS on the new disk and then copy what I needed back from
the original root partition.

What was odd was to find the root partition of a disk could be
/dev/dsk/c1t1d0s1 when in to top or bottom slot of the Blade 2000.
Unlike the SCSI disks I am used to, the 'cx' where x was 1 or 2, do not
stay constant with the two slots.

Randy's suggestion of:
1. mv /a/etc/path_to_inst /a/etc/path_to_inst.original
2. rm /a/etc/path_to_inst.old
3. devfsadm -v -C -r /a

did not work for me - it simply never updated /a/etc/install

Finally more by luck than skill I got to the point it would boot if I typed

OK> boot disk0

rather than
OK> boot disk


Then the page Trinean pointed me to on Sunshack
http://www.sunshack.org/data/sh/2.1/...doc/40133.html

got that fixed with:

# luxadm set_boot_dev /dev/dsk/c1t0d0s0

which updated boot-device in the EEPROM


Its a bit worrying I don't feel as confident at restoring data from a
damaged disk as I used to on the Ultra 80. But I guess I'll find a way!