Thanks to Alan, Richard, John, William and Mohd for their help
-Original Question:
I have a few AS2100 running DU 4.0D that I need to migrate to AS4100. Is
there a recommended approach for this? any gotchas I should be looking for?
Can I just do a dump on the AS2100 and restore on the AS4100, then
recompile the kernel (seems too simple to work...)?
-Reponses Summary:
Need to boot from generic kernel then rebuild your own.
Need to correct devices information like in fstab, /etc/fdmns, swap info, etc
-Answers received:
>> Unless you hand edit the configuration ahead of time
>> to account for the different CPU type and any location
>> changes in devices, you'll have to boot genvmunix and
>> build a new kernel. This part you noticed, but there
>> is a good chance that some devices will move around.
>> On typical 4100s there are two SCSI adapters included
>> in the base system; one for the CDROM and a 2nd for the
>> StorageWorks shelf that has the system disk in it. The
>> devices on this 2nd bus will rz8 - rz14 and tz8 - tz14.
>> On the 2100, the disk is probably in the rz0 to rz6
>> range if SCSI attached. Accounting for this may involve
>> little more than creating some special files and editing
>> /etc/fstab and /etc/rc.config to account for the difference,
>> or it may take a fair amount of work to coerce LSM into
>> using the different names.
>> With the right configuration, it could be as simple as
>> rebuilding the kernel. Or, it could be harder. You
>> didn't provide enough configuration detail to know.
------
>> I don't see why you can't do that. I would boot off the generic kernel
so as
>> to get any device drivers that differ from you 2100 configuration.
>> Remember that you can boot any and all alpha boxes off the CDrom's generic
>> kernel which sums up to mean that a kernel is a kernel is a kernel.
------
>> I've done this sort of thing more than once. Sometimes the way I've
done it has been to
>> simply move the system disk (assuming it's on a StorageWorks brick and
is NOT
>> connected to a SWXCR or other in-cabinet RAID array controller) to the
4100, boot
>> the generic kernel, and rebuild the system-specific kernel. Note that
you may well
>> have to play with mount points, AdvFS domain name-to-device mappings in
/etc/fdmns,
>> and swap space settings, but it's quite do-able.
>> If the 2100 is using a SWXCR or equivalent, then you could do a
dump/restore to the
>> new system. You'll need to boot an installation CD so you can get to a
UNIX shell
>> prompt to prepare the new system disk (disklabel, AdvFS/UFS partitions,
running
>> vrestore [after doing a MAKEDEV to make the tape device, as the
installation CD
>> process doesn't do that when you go to the shell prompt], and then
tweaking the files
>> on-disk as mentioned above).
>> I call this "repotting" a system -- think of moving a potted plant to a
larger pot.
------
>> Tru64 (and Unix in general) backup tools do not have an image backup
concept
>> VMS has. This is both good and bad.
>> When you switch hardware you always "need" to do a re-install...
>> Basically, the instalation process 'optimizes' for a particular set of
>> hardware. 9 times out of 10, this is not a big deal and can be compensated
>> for by simply booting genvmunix and running doconfig.
>> However, if the old OS doesn't know about the new hardware, you have
>> problems. In your case, 40D knows about both the 2100 and the 4100 boxes
>> (but it knows nothing about the 40E). So you "could" probably do what you
>> want to do... except that you can't do it if you use AdvFS.
>> If you are using AdvFS, the way Tru64 is designed to be "backed up" is via
>> Legato NSR. The problem with restoration is that you first must have a
>> working OS installed on the box, and THEN you can uses Vrestore to restore
>> the AdvFS information to "the other directories."
>> Digital used to recommend that you use Dump to create a backup of /, /usr,
>> /var (ie the stuff on the CD) and then use AdvFS to backup /usr/local (or
>> whatever). This is mainly because there is no "vrestore" on the standalone
>> CD.
>> If you are using ufs, you CAN simply use dump and restore by booting from
>> the distribution CD.
>> Just on general principals, whenver we swap hardware, we do a new OS
>> install and then load in the the user data via whatever mechanism...
>> usually we do it over a network connection simply because it is so much
>> faster than using tape. Also, since we try to keep user data independent
>> from any system data, we can frequently simply move the disk drives and
>> not need to do ANY data transfer.
------
>> Actually you are not far from the truth as long as you are booting from
the
>> generic kernel and rebuilding your own.
>> You may need to take care of the device names and the advise links as well
>> which most probably you already keeping in mind.
Received on Mon Aug 28 2000 - 19:11:41 NZST