Hi,
This is the second summary for the "4.0D -> 5.0 upgrade crashes" question.
It gives the solution we used, and presents another problem.
The original question is attached below. Some background information is
presented:
Basically, we're trying to take a copy of a machine currently in
production A (running on AlphaStation 255), to test it on an AlphaServer
DS10, C, and then if that's successful, run it on C.
Now A is currently at 4.0D PK3. 4.0D won't run on a DS10 (we tried, but
it crashed various times). Our approach was to take a copy of A, and
place it on an AlphaServer 400, B (as A is a production machine).
Then to upgrade B to Tru64 UNIX V5.0, and then move B's disks to C.
The first post asked about crashes occuring when upgrading B.
We've since tried the upgrade again, this time with success. The only
difference from before was that
1. We booted first to multi-user mode, then used "shutdown +now" to get
to single-user mode.
2. We used Legato Networker to take a copy of A, while we used "rsync"
the first time (which did give an error about /dev/log not being copied).
3. We temporarily removed /.profile (which has some customisations to
the PATH variable).
4. As we changed the hostname and IP address, we also renamed
/usr/sys/conf/...
However, we now face a different problem. We now have B running Tru64 UNIX V5.0,
and we want to move the disks to C. When we then boot the disks from C,
(into single-user mode), "hwmgr -view devices) reveals that the device
special names are all "unknown". This is stopping the /usr and swap partitions
from being mounted.
That is our current position. Compaq is looking into it.
Scott
--- Original Question ---
> Hi,
>
> We would like to upgrade the hardware of one of our machines from an
> AlphaServer 400 4/166 to an AlphaServer DS10. Currently the machine
> is running Digital Unix 4.0DPK3 and since that is not supported on DS10
> hardware, the operating system will also need to be upgraded.
>
> Thus we have opted to upgrade the operating system to Tru64 Unix V5.0 while
> the disks are attached to the AlphaServer 400, and then to move the disks
> over to the new AlphaServer DS10.
>
> During the update procedure, we get the following error message:
>
> /sbin/installupdate: 18345 Bad system call - core dumped
>
> After this, we are returned to the prompt (#), and even commands such as
> "ls" and "cat" give a similar error message:
>
> # ls
> Bad system call
>
> What has caused this error? Can we proceed with the upgrade, or is there some
> sort of incompatibility.
>
> Scott
>
> --- More detailed information ---
> AlphaServer 400 4/166, Firmware version 7.0-9, Digital Unix 4.0DPK3,
> two external UltraSCSI disks attached externally to a wide SCSI controller,
> 128Mb system memory.
>
> PALcode: Digital UNIX version 1.46
> isp0 at pci0 slot 13
> isp0: QLOGIC ISP1040B/V2
> isp0: Firmware revision 5.57 (loaded by console)
> isp0: Fast RAM timing enabled.
> scsi1 at isp0 slot 0
> rz9 at scsi1 target 1 lun 0 (LID=2) (DEC RZ1CB-CS (C) DEC 0656) (Wide16)
> rz10 at scsi1 target 2 lun 0 (LID=3) (DEC RZ1DF-CB (C) DEC 0371) (Wide16)
>
> Unfortunately, the /var/adm/update/update.log file didn't (apparently) get
> written, but the crash occured after the following:
>
> Merging new file /sbin/init.d/.new..autosysconfig into
> existing /sbin/init.d/autosysconfig
>
> etc.
>
> *** Finished configuration mergers for Update Installation ***
>
> /updmnt/isl/updeng: /var/adm/patch/log/event.log cannot create
>
> /sbin/installupdate: 18345 Bad system call - core dumped
>
Received on Thu Oct 21 1999 - 08:55:20 NZDT