You are on page 1of 3

# Need to get rid of device trees since the will not work from one box

# to the next. Also need to nuke the path_to_inst file.

rm -rf /a/dev /a/devices
rm /a/etc/path_to_inst
# Need to restore the device tree from what is actually created during
# the net boot process.
cd /
find devices dev -depth -print | cpio -pdm /a
# Now we need to create a new path_to_inst
devfsadm -r /a -p /a/etc/path_to_inst
# Need to recreate dev entries that got blown away
devfsadm -i random -i ipf -i md -r /a -p /a/etc/path_to_inst
That would be great, but when dealing with an E10k domain, things get a bit
Matt Ungaro basically agreed to Derek.
Buddy sent us his detailed receipt.
detach the submirror for this disk (third mirror as you describe below)
mount the underlying disk slice of that disk to /mnt
edit /mnt/etc/system and uncomment line that sets rootdev
edit /mnt/etc/vfstab and change lines from metavolumes to /dev/dsk/cxtxdxsx
run the following commands:
rm -r /mnt/devices
rm -r /mnt/dev
Pre-Solaris 8:
rm /mnt/etc/path_to_inst
drvconfig -R /mnt
devlinks -R /mnt
disks -R /mnt
ports -R /mnt
Solaris 8 or newer:
devfsadm -p /mnt/etc/path_to_inst -r /mnt
Now on Solaris 2.6, boot from new disk with -a option and when prompted,
re-create path_to_inst. Although it is undocumented, -p option to devfsadm
does this automatically (truss it and you will see). It doesn't work with
drvconfig though.
For Solaris 8 or newer, your done. Boot from the new disk.
Steve gave us his outlook:
I think you may have to install a new bootblock on the "transplanted" disk.
I am concerned that the kernel ( /kernel/genunix ) is for a Sun4U-1
(E10K), but you are doing to attempt to run it on a Sun4U architecture (E420
Ultra80)... and I fear the consequences. Also, anything on that transplanted
disk that references /platform/<architecture> or /usr/platform/<architecture>
will be potential problems.
I am fairly certain that what you propose is "unsupported" by Sun and is the
kind of thing that would cause me and my fellow call center E10K support
engineers to shake our head in wonder at the stupidity of our customer(s)
and wonder just what the hell they were thinking.
Oh, don't forget to disable all /etc/init.d/ startup scripts that attempt
to start all sorts of E10K-specific daemons etc.
Great feedback of an evidently experienced professional. Other reply from him
(about booting only to a single-user mode)
My guess: some E10K specific scripts and/or daemons are stopping the boot
process; they may be logging errors, or they may be waiting to
speak to a non-existent control board or SSP. Without
/var/adm/messages and/or `dmesg' output and/or /var/log/syslog
log files (among possibly other files)... I can only speculate
at this point.
An then, Anand Chouthai came along. He told he works with such scenarios for
Yes , it will work, One of the steps I see missing is to take out any
references to ssp. Also it will work 99% times if the original E10 install
is done Entire distribution with OEM support.
And at last what seems to be the "voila"
Take the disk which has the E10K image and put it on E420R:
Boot from cdrom in single user mode ( same OS on the E10K image) or boot
from jumpstart in single user mode
mount the disk with the E10000 image on /a
cd /a
mv dev dev.dr
mv devices devices.dr
mkdir dev devices
cd /dev
find . -depth -print | cpio -pdm /a/dev
cd /devices
find . -depth -print | cpio -pdm /a/devices
cd /a/etc
mv path_to_inst path_to_inst.dr
cp /tmp/root/etc/path_to_inst .
change the vfstab to appropriate disk config
If the E10000 disk was encapsulated then take the rootdev entries out
from system file
install bootblk on the disk
cd /a/etc
mv ssphostname ssphostname.dr
init 0
ok> boot -rasvw
when it comes to single user mode <ctrl D> to go to multi user mode.
Hope it works. Good luck.
Well, thats all. As I mentioned, we didn4t try it yet, but it seems to be the
way to get the work done. Anyway I will let the list know how it worked.