Install fails on PWS 433au
Eric
RAM, a 9 GB disk, and a S3 Trio64 2MB video card. I am able to boot
the CD and it continues to where it complains about the time in the
filesystem and about having no swap device, then states it's
initializing the system for installation, where it comes back with
"Illegal instructions" (similar to the following):
INIT: SINGLE-USER MODE
Initializing system for Tru64 UNIX installation. Please wait...
-: 33 Illegal instruction
-: 34 Illegal instruction
-: 36 Illegal instruction
-: 38 Illegal instruction
-: 40 Illegal instruction
#
Anyone have any ideas what could be the problem?
Kari Uusimäki
Have you checked the console parameter boot_osflags?
The command is
>>> show boot_osflags
It should be as follows, when you want to boot Tru64:
boot_osflags = A
You can always override it temporarily by issuing the boot command with
the flag like follows:
>>> boot -fl A <device>
Then it would be also good to check the parameter
os_type
which should be UNIX or OSF/1
Kari
Eric
The os_type was set to unix, and I set boot_osflags to A. I still get
the illegal instructions and get dropped to the prompt. At the prompt
everything that I type gives "Illegal Instruction" back.
I had OpenVMS running on this system previously and I haven't changed
anything to the systems since (except swapping the keyboard).
H Vlems
>
> - Tekst uit oorspronkelijk bericht weergeven -
I'm not a unix expert (I run VMS at home) but generally if an Alpha
runs VMS then it will run Tru64.
I have one system that runs Tru64 most of the time, occasionally
netBSD (4.0.1) and VMS.
It is an Alpha Server 800 and it is a supported platform for all those
OS's.
Apparantly your pws boots off the distribution cd, so the main
settings are all right. The OS_type doesn't matter much.
netBSD sets it automatically to Tru64 and VMS changes the value to vms
whenever that boots.
The boot flag does matter, but you must have had that set correctly or
the system wouldn't even have started.
The time problem ("preposterous date and time set") comes from running
VMS (I guess), I get the same error when VMS is started on the 800.
A tongue in cheek message from one os group to another I guess.
So what is happening here.
The "illegal instruction" message may be an indication that your
particular model is not (or no longer) supported in this version of
Tru64.
The 633au was sold to Tru64 users mainly. Is it possible for you to
install 5.0?
Failing that, what does the Tru64 Software Product Description say
regarding supported platforms?
Hans
PS
I read the OP again, and you mention 1.5 GB of main memory. Is that
supported on that platform?
Michael Kraemer
> So what is happening here.
> The "illegal instruction" message may be an indication that your
> particular model is not (or no longer) supported in this version of
> Tru64.
> The 633au was sold to Tru64 users mainly. Is it possible for you to
> install 5.0?
> Failing that, what does the Tru64 Software Product Description say
> regarding supported platforms?
> Hans
>
> PS
> I read the OP again, and you mention 1.5 GB of main memory. Is that
> supported on that platform?
The PWS's came rather late to the alpha game so they
should be able to run the latest Tru64 versions.
Only the support for some of the oldest Turbochannel alphas
has been officially dropped somewhere in 5.x
I run a PWS500 with Tru64 5.1B.
1.5GB is the max amount of RAM one can stuff into these boxes.
As for the OP's troubles: I'd look at a failing
hardware component, reseat cables and RAM modules and such.
Is the boot CD good (original or burnt) ?
I've also seen strange PWS failures with bad (or "unsupported")
RAM modules, it took me quite a pile of RAM sticks until
I found the pairs which did not crash the machine.
The strange thing is that some may pass the initial
hardware test but will crash the machine later when
Tru64 boots. If possible, get original parts, even
if they cost more.
Kari Uusimäki
I wonder if your installation medium is good. If you get those errors
continuously it seems that the boot didn't finish correctly.
Have you tried booting to single user mode?
>>> b -fl s <device>
Does that behave similarly?
If you cannot boot to the single user mode and then get a root prompt,
the medium or the CD drive must be faulty.
Could you post or mail the output from the boot attempt?
Kari
H Vlems
Hello Michael, thanks for the PWS details, I didn't know that.
So where does that leave the OP?
Was the system moved recently? If so, it may help to remove all memoru
boards and pci boards and put them back, properly seated.
Hans
Eric
The CD is an official CD (not a burned CD-R).
I did a quick check inside after I started getting those errors and
nothing seemed loose. I'll will have to pull everything out and
reseat when I get a chance.
Eric
I reseated the ram, the cd and disk cables, and the video card. I
still get the same errors.
Just to check, I reinstalled VMS on the machine and it seems to be
running fine (the only things I changed with the os_type and
bootflags).
Kari Uusimäki
Have you checked that the firmware on your PWS is the most recent?
You find the latest firmware at:
http://h18002.www1.hp.com/alphaserver/firmware/readmes/digitalpw.html
H Vlems
>
> - Tekst uit oorspronkelijk bericht weergeven -
Well , at least that proves that the hardware itself is alright
doesn't it?
VMS is rather fussy and if the firmware isn't at the correct level
then VMS will print a warning banner.
So, either there's something wrong with the Tru64 palcode on the
machine, or, unlikely as it may be, your distribution media are
faulty.
As a test you could download netBSD 4.0.1 for Alpha. It uses the same
hardware and firmware as Tru64.
Hans
Doesnt Compute
of any new Alpha I take over/acquire is to load new PAL code from the
latest CDROM supporting that hardware.
I believe the Console 6.6 CDROM would be appropriate. I've not worked
with the -433 but it **should be** much like the other Personal
Workstations. Reload the code even if the version is the same. It's
just reflashing a flash chip. No big deal If it fails, then replace
the flash chip (no, I've no idea how to do that!).
The fact VMS seems to boot/run would seem to mean the Alpha CPU is
fine (processor paths, cache, etc.) and would seem to indicate RAM is
atleast acceptable enough to be corrected, should a bit be out here or
there. I use a VMS hard drive to test new machines. It just makes
sense.
If all of this fails, and the doc shows 5.1B is really supported on
the -433, I might be tempted to load the Alpha CPU version of FreeBSD
(which is always in my toolkit for times like these). If you have not
burnt a copy, download it, burn it and boot it. It does not matter if
you actually INSTALL it, just boot the CDROM and see if it works or
not. You can even target that same drive as you were using, start the
FreeBSD install and just turn the machine off if it seems to be
loading, or let it finish and have a decent OS loaded. VMS and
FreeBSD on the same box really does rock. LOL
Hope you figure out the issue, it's nice using these (old) Alphas for
something useful!!! I'm putting money on PAL code corruption/
version. ;)
-- Robert
Hardware shack: AS ES40, AS 4000, AS 2100, DEC 3000/400 /600 /700 x 2,
PWS1000, PWS600au, DEC 5000/240
Eric
I have upgraded the firmware, still no-go. I'm going to try swapping
the video card and ram to see if that does anything.
H Vlems
> On Feb 24, 1:03 pm, Doesnt Compute <doesntcomput...@gmail.com> wrote:
>
>
>
>
>
> > I would echo the setiment concerning PAL code. My normal "break in"
> > of any new Alpha I take over/acquire is to load new PAL code from the
> > latest CDROM supporting that hardware.
>
> > I believe the Console 6.6 CDROM would be appropriate. I've not worked
> > with the -433 but it **should be** much like the other Personal
> > Workstations. Reload the code even if the version is the same. It's
> > just reflashing a flash chip. No big deal If it fails, then replace
> > the flash chip (no, I've no idea how to do that!).
>
> > The fact VMS seems to boot/run would seem to mean the Alpha CPU is
> > fine (processor paths, cache, etc.) and would seem to indicate RAM is
> > atleast acceptable enough to be corrected, should a bit be out here or
> > there. I use a VMS hard drive to test new machines. It just makes
> > sense.
>
> > If all of this fails, and the doc shows 5.1B is really supported on
> > the -433, I might be tempted to load the Alpha CPU version of FreeBSD
> > (which is always in my toolkit for times like these). If you have n
> > you actually INSTALL it, just boot the CDROM and see if it works or
> > not. You can even target that same drive as you were using, start the
> > FreeBSD install and just turn the machine off if it seems to be
> > loading, or let it finish and have a decent OS loaded. VMS and
> > FreeBSD on the same box really does rock. LOL
>
> > Hope you figure out the issue, it's nice using these (old) Alphas for
> > something useful!!! I'm putting money on PAL code corruption/
> > version. ;)
>
> > -- Robert
>
> > Hardware shack: AS ES40, AS 4000, AS 2100, DEC 3000/400 /600 /700 x 2,
> > PWS1000, PWS600au, DEC 5000/240
>
> I have upgraded the firmware, still no-go. I'm going to try swapping
>
> - Tekst uit oorspronkelijk bericht weergeven -
At this point I'd be swapping hardware too. But before you start
ripping things out:
1) when the system ran VMS did you try the SHOW ERROR and SHOW MEMORY
commands?
Robert mentioned that VMS can run with imperfect memory provided the
errors may be corrected. However the errors are logged and reported
with SHOW ERROR.
If there aren't any errors reported then there aren't any. VMS
supports ECC but is very fussy about memory errors.
2) have a look at the SRM parameters. Especially those for the
ethernet device(s). Example (on an AS 800):
>>>sho e*
enable_audit ON
ewa0_arp_tries 3
ewa0_bootp_file
ewa0_bootp_server
ewa0_bootp_tries 3
ewa0_def_ginetaddr 0.0.0.0
ewa0_def_inetaddr 0.0.0.0
ewa0_def_inetfile
ewa0_def_sinetaddr 0.0.0.0
ewa0_def_subnetmask 0.0.0.0
ewa0_ginetaddr 0.0.0.0
ewa0_inet_init bootp
ewa0_inetaddr 0.0.0.0
ewa0_inetfile
ewa0_loop_count 2
ewa0_loop_inc d0
ewa0_loop_patt ffffffffffffffff
ewa0_loop_size 100
ewa0_lp_msg_node 8
ewa0_mode Fast
ewa0_protocols MOP
ewa0_sinetaddr 0.0.0.0
ewa0_tftp_tries
bus_probe_algorithm new
pci_parity off
pka0_host_id 7
pka0_soft_term on
reset_boot_arg0 0
reset_boot_arg1
reset_boot_arg2
scsi_poll ON
scsi_reset ON
3) did you boot netBSD or freeBSD from cdrom? If that fails I'd
suspect an error in the Tru64 palcode.
If all that fails, remove the video card altogether, provided you've
set the SRM variable CONSOLE to SERIAL before doing so (and shutting
off the system)
and reboot with a DB9-to-DB9 cable on the console port.
Hans
Eric
Just an update. I swapped the video card for a ELSA Gloria Synergy
(PBXGK-BB), which I just got a hold of. Still got the errors.
I also tried installing NetBSD, which paniced in the middle of
untaring something.
I started playing around with it and just for grins booted into
AlphaBIOS. It's memory test seems to have hung, so I'm starting to
think it's memory issues. I'll put VMS back on it and check if it
complains about anything, while I look for different RAM.
Michael Kraemer
> I started playing around with it and just for grins booted into
> AlphaBIOS. It's memory test seems to have hung, so I'm starting to
> think it's memory issues. I'll put VMS back on it and check if it
> complains about anything, while I look for different RAM.
As I wrote before, I'd suspect the RAM.
"Unsupported" RAM really can give you issues,
and according to my experience, having passed
the initial RAM test doesn't mean much.
Peter Ljungberg
What happend?
Did you solve the problem?
You could always try Alpha emulators.
http://www.emulatorsinternational.com/en/personalalpha.htm
^P