Tag: Field test

Booted E8.4
Now I got a bootable disk, nothing stopped installing 8.4, using the Personal Alpha, being easier to handle if something goes wrong.
I left the system as I had left it yesterday:

DKA0 = the original V8.3 system disk

DKA100 = the upgradedisk (the one created yesterday from the 8.4 backup saveset)

DKA200 = the disk destined to hold 8.4 for testing. The container is a copy of the disk loaded as DKA0 – only renamed and relabeled.

DKA300 = CD drive – in case I need it

So tonight I did the upgrade, by booting PA from DKA100 – and it worked without a problem, as could be expected. Next, I rebooted the system and that invoked SYSGEN, as shown in the logfile. But the next reboot imposed a problem: It hang because DKA200 could not be mounted; the reason is obvious:
it’s the system disk. This mount is in SYSATRTUP_VMS.COM – without /NOASSSIST, that normnally isn’t required since the system is usually booted from DKA0.
Anyway, I had to stop the emulator the hard way.
Next step – which I should have done before – was moving the container holding 8.4 to DKA0, and define all normally used containers on their locations, so the only difference I have in this system is just the systemdisk.
Now I booted the system. No real trouble, just that the webserver now has a problem:

%WASD-I-STARTUP, begin
%WASD-I-STARTUP, using SSL image
%DCL-W-ACTIMAGE, error activating image SSL$LIBCRYPTO_SHR32
-CLI-E-IMGNAME, image file $3$DKA0:[SYS0.SYSCOMMON.][SYSLIB]SSL$LIBCRYPTO_SHR32.
EXE
-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image


Since WASD on this system is linked against the HP-supplied SSL files, this might have been expected, though I would prefer it didn’t happen. But the easy way out is to relink WASD and start it; it now runs.

No problem for MySQL – because that is linked against another SSL implementation, appearently. SWS did have a problem , but that has nothing to do with the upgrade; At least, I cannot think of a reason:

Syntax error on line 5 of /apache$root/conf/mod_php.conf:
Can't locate API module structure `php5_module' in file /apache$root/000000/modules/mod_php_apache-2_0.exe: function not implemented

Next step is installing it on the new PWS. That means I first need to set it up with 8.3 – which may be a problem if the CD is bad indeed. Or install it fresh – but than I’ll have to burn a CD first.

8.4 fieldtest
The Alpha safeset of the OpenVMS 8.4 environment comes as a zipped backup saveset.

First, I created a new disk on the Personal Alpha and restored the files. But that left the disk as an ordinary datadisk – it’s not bootable. Another approach involved a copy of the bootdisk, on which the backup saveset was restored, with /OVERWRITE; but that would caused another poblem: a few files could not be copied because of a lack of contiguous space; so I removed all files and retried. Now the disk started a boot, but then it failed on the second bootstrap.
Next, I tried an install from the original 8.3 CD but there is an error on it; That is: BACKUP ran into a CRC error that it couln’t pass. However, DUMP of the file where it happened went straight on, without an error…..
A next INIT of the target disk, and restoring the saveset once more, I tried SETBOOT. For Alpha, this is a foreigh command:

$ SETBOOT := $SYS$SETBOOT
$ SETBOOT DKA100:

which would setup the boot-sector as on SYS$SYSDEVICE, accoring the (rather limited) documentation.It took some time but in the end, the disk was bootable – but, again, failed on the secondary bootstrap:

>>> b dka100
(boot -file '' -flags '' 'dka100')
BOOT_RESET is ON: cold boot
Booting from the device 'dka100' file ''
Loaded the primary booter; size 0x9a000
%APB-I-FILENOTLOC, Unable to locate SYSBOOT.EXE
%APB-I-LOADFAIL, Failed to load secondary bootstrap, status = 00000910
CPU0 halted: reason: halt instruction executed
CPU0 halted: default

I’ve seen this error before, I think: when the directory holding the system was in lowercase: [vms$common], in stead of uppercase: [VMS$COMMON]. But here, there was nothing wrong with the whole environment..
Asked my collegues on the issue, and it turned out the saveset is actually an image backup.
So I reloaded the backup file onto the PA disks, and rerstored using:

$ backup/imag alphae84.bck/save dka100:

and that did the trick:

>>> b dka100

Alpha Emulator Firmware
Version 2.0.16 build Oct 8 2008 09:38:01
Initialized physical memory: 128 MB
Loaded HWRPB: physical address 2000
Initialized CPU0
(boot -file '' -flags '' 'dka100')
BOOT_RESET is ON: cold boot
Booting from the device 'dka100' file ''
Loaded the primary booter; size 0x9a000

OpenVMS (TM) Alpha Operating System, Version E8.4
© Copyright 1976-2009 Hewlett-Packard Development Company, L.P.

Now this is a 4GB disk…
Prepared 8.4 CD
Once I knew how to restore the saveset into a bootable disk, I prepared writing it to CD: Created a 1.400.000 block logical device (fits on a 700Mb CD), and restored the saveset onto it. Now this disk image it to be burned to CD – I only need to get some, I’ve none left 😉