SUMMARY: Moving disk from Ultra 2 to SB2000 (errata)

Small errata:

After copying the data from /tmp/d1/* to /tmp/d2/* via ufsdump/ufsrestore,
remember to:
mv /tmp/d2/dev /tmp/d2/dev.orig
mv /tmp/d2/devices /tmp/d2/devices.orig
mv /tmp/d2/etc/path_to_inst /tmp/d2/etc/path_to_inst.orig
cp -p /etc/path_to_inst /tmp/d2/etc/path_to_inst
cd /dev;find . -print|cpio -pduVm /tmp/d2/dev
cd /devices;find . -print|cpio -pduVm /tmp/d2/devices

Sorry about that...

Vincent

> Hello everyone,
>
> I'm posting the (positive) result, in case anyone's interested.
>
> I didn't get many answers about this issue but in the end, I decided to
> try it myself and in short: it works even though the Ultra2 is
> sbus-based and the SB2000 is pci-based. Of course, if you have access
> to an enterprise network with heavily customized jumpstart servers (you
> know the kind..), this is not worth the hassle. However, in this
> specific case, the purpose was the replace my main home machine (an
> Ultra2 Creator3d) with the SB2k and do it quick (also, I don't have a
> jumpstart server at home). So here goes:
>
> - Grab an external unipack and insert a disk the size of your internal
> Ultra2 boot disk into it. In my case, it was a SUN18G. This disk will
> hold a copy of your boot disk and transport it to the sb2000.
>
> - Connect the enclosure to the Ultra2 and power it on. Don't reboot
> just yet.
>
> - Make sure you have your 02/02 CD (install CD 1 of 2) available:
> NOTE: 02/02 was installed on the Ultra2 and 02/02 was also my target
> for the sb2000. 02/02 is bootable and useable on both machines as it
> exceeds the minimum requirements for both machines. As a result, it is
> possible to think that there is a chance we can boot the U2's OS on the
> sb2000.
>
> - Make sure that your OS is "Entire distribution + OEM". Obviously, if
> you installed -only- what was need on the Ultra2, the OS just isn't
> going to be bootable easily on the sb2000 (different cpu, different
> buses, not to mention the FC-AL boot disk). Entire dist + OEM may be
> overkill but you never know...
>
> - Make sure your patches are up to date or better yet determine what
> patches need to be updated (you don't want to hit a driver bug or
> regression when you try the first boot on your sb2000).
>
> - Install whatever drivers are needed on the target machine (sb2000).
> Namely, the XVR-1000 drivers which don't come with 02/02. They =do=
> come with Solaris 9, though..
> NOTE: It appears that some SB2000 machines where shipped without
> CD-ROM's. In my case, I had to contact my local Sun support to get the
> files. If you get an Sb2000 without CD's, complain and ask for the
> CD's.
>
> - Insert CD-ROM in Ultra2, "boot cdrom -s" (or "boot cdrom" if you wish
> to do this in graphical mode).
>
> - clone the boot disk: "dd if=/dev/rdsk/c0t0d0s2 of=/dev/rdsk/c1t12d0s2
> \ bs=64k".
>
> - At this point, you don't need the Ultra2 anymore. Turn it off (yes, I
> mean it) and connect the unipack to the sb2000. Insert the 02/02 CD
> into the sb2000. Make note to announce the Ultra2 on ebay the following
> day.
>
> - "boot cdrom -s" the sb2000. Since the sb2000 boot disk already has an
> OS on the SUN73G disk, I could also boot from the internal disk. (no
> need for the CD-ROM anymore). On my sb2000, the 73G disk came up as
> c0t1, the 18g disk came up as c2t12. That's not the native controller
> order but..
>
> - Mount the root partition of the boot disk copy (SUN18G). Fix its
> vfstab before overwriting the SUN73G disk with the data from the
> SUN18G.
> (the first internal FC-AL disk on the sb2000 is c0t1 or c1t1, not c0t0
> like on the Ultra2).
> in short:
>
> mkdir /tmp/d1
> mount -F ufs /dev/dsk/c2t12d0s0 /tmp/d1
> sed -e 's/c0t0d0/c0t1d0/g' < /tmp/d1/etc/vfstab > /tmp/v.txt
> mv /tmp/v.txt /tmp/d1/etc/vfstab
>
> - Also (the ultra2 uses "hme", the sb2000 uses "eri"):
> cd /tmp/d1/etc
> mv -i hostname.hme0 hostname.eri0
> mv -i hostname6.hme0 hostname6.eri0
> mv -i hostname*.qfe? /tmp/d1/root/old/sigh/tears/
> (Last step is needed cause I don't have a Qfe PCI card but I had a Qfe
> SBUS, anyone wanna trade?).
>
> - Create your label and partitions on the SUN73G disk, let the data on
> it die silently as you newfs' your ufs partitions.
>
> - Mount your partitions (source copy under /tmp/d1,/tmp/d1/var, etc..,
> target copy under /tmp/d2, /tmp/d2/var, etc..), you are ready to copy
> them.
>
> - in bash (your mileage may vary, don't forget "/" but you get the
> idea..): for part in /usr /usr/local /opt /var \
> do ufsdump 0f - /tmp/d1/${part}|(cd /tmp/d2/${part}; ufsrestore xf
> -);done
>
> - Install the bootblock:
> installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk \
> /dev/rdsk/c0t1d0s0
>
> - Umount everything, reboot and see your new cloned system come up.
>
> So far, the system has proved quite stable and is performing as
> expected. Compilers, emulators, everything works and it is much faster
> (can't tell much about the graphics since I don't currently have a
> keyboard on my sb2000).
>
> A small note about hostid's: I was already running "hid" with an old
> hostid since the time when I first had an ss5 with softwindows95 on it
> and had to keep that hostid.. When the sb2000 booted, it came up with
> the startup scripts from the Ultra2 and switched to the ss5' hostid. So
> I didn't have any specific problem with my hostid (no, I'm not running
> VxVm).
>
> I hope these details will be useful to others who want to migrate their
> Solaris OE to a new machine without re-installing.
>
> Vincent happy sb2000 user at home..
>
>> Hello everyone,
>>
>> 	Please forgive me for asking..I acknowledge that this is indeed an
>> 	FAQ
>> however, I'd like to have other people's enlightened opinions on this
>> (specific) issue. Here is the story:
>>
>> - Source system:
>> * Ultra2 1300 Creator3d with Solaris 8 02/02 (entire OE install +
>> OEM). * Recommended cluster from 14/06/2002 (108528-15).
>> * A lot of software and no license problems that I cannot deal with.
>>
>> - Target system (will replace the U2, lucky me).
>> * SunBlade 2000 @900Mhz, XVR-1000, 73GB FC-AL disk.
>>
>> - Why bother?:
>> * lots of 3rd party packages, lots of packages, many DB's, many /opt
>> products (with corresponding /var/sadm/install/contents entries, etc..
>> gnome, softwindows, mae, lotus domino, to name a few).. I have a clean
>> /usr/local tree but that's not enough.. I'd like to avoid the hassle
>> of re-pkgadd'ing all of the installed products
>>
>> - Proposed procedure:
>> * de-encapsulate everthing on the Ultra2
>> * delete SDS meta databases on the Ultra2
>> * Insert disk from Ultra2 into unipack enclosure connected to SB2000.
>> * Boot from CD (Sol8 OE rev 02/02)
>> * label/newfs on the 73GB FC-AL disk after a CD-BOOT (mount as /a). *
>> ufsdump/ufsrestore from SCSI disk to target 73GB FC-AL disk.
>> * modify /a/etc/vfstab on the 73GB to match the new paths..
>> * copy /dev and /devices from CD boot to /a/dev and /a/devices
>> * do the same for /etc/path_to_inst (to /a/etc/path_to_inst)
>> * installboot the new boot block...
>> (plus all other steps necessary).
>>
>> I'm worrying about this:
>> 1) Is there the faintest chance that the whole stuff is going to work?
>> 2) Assuming that it works, will the result give me an install which
>> will
>> be the equivalent of a fresh install directly on the SB2000?
>> I'm quite curious about 2) since I remember that around the 2.5.1/2.6
>> times, I once tried to move a solaris 2.5.1 disk from an Ultra1 to an
>> Ultra2.. It did work (after quite a few steps) but some packages were
>> missing... Did that change in Solaris 8 if you do a Solaris OE "entire
>> dist + OEM" install? I'm very concerned about SB2k-specific drivers
>> that could possibly be missing but then again if I have the complete
>> dist + OEM...
>>
>> 3) What about the xvr-1000? Will I need special drivers? Just
>> wondering.. but if I get 1) and 2) done OK, then the XVR-1000 is going
>> to be a very very very minor problem.. (I think I'll update FFB
>> drivers up the latest up before commencing the whole operation).
>>
>> If anyone can shed some light on this issue... Thank you very much for
>> reading.. that's my new home machine.. :) :) :)
>>
>> Vincent (coyote@step.polymtl.ca)
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers