• Please review our updated Terms and Rules here

HP-UX 10.20 install issue

C

commodorejohn

Veteran Member
Joined
Jul 6, 2010
Messages
3,307
Location
California, USA
I'm having some trouble getting HP-UX up and running on a PA-RISC workstation I picked up at VCFW a couple years back. In brief, I'm using what I've found listed as the "HP-UX 10.20 (2000-03) S800 Install and Core OS" disc image. This boots into the install environment just fine, but runs into a couple snags with the swinstall process. First off, it seems to misidentify the workstation (a Visualize C200) as a 32-bit system, since its internal model ID matches "9000/7**" - but I can work around that by editing the configuration file. However, past that, the swinstall agent conks out during the analysis phase, whether I run it in interactive mode or just tell it to use the defaults. Looking through the resulting logs, it looks like the checkinstall script for pretty much every package is freaking out when they try to check for available disk space using du and df, which for some reason aren't present in the install environment.

The whole thing is very odd - I wonder if I'm doing something wrong, but it seems like what I have should be the correct install disc. Can anyone offer some advice on this? I'm about ready to pull my hair out here... :/
 
Isn't there different install media for HP 9000/700 workstations and for HP 9000/800 servers?

I have 10.20 install media that I have used on 712/60,80,100 and B132L machines. I'll have to take a look and see what the CD labels say.
 
Maybe try the image here, it's newer than the CD I have:

HP-UX 10.20 Install & Core OS for HP 9000 Series 700 (December 1999) [B3782-10456]

archive.org/details/HPUX10.20InstallCoreOSForHP9000Series700December1999B378210456

The 10.20 install CD I have is labeled:

HP 9000 Series 700 B/C/J Class
Part No.: B3782-10323
HP-UX Release 10.20
VUF B.10.20.00
Date Code 3821
HP-UX Install and Core OS Software
Plus Additional Core Enhancements
June 1988
 
It's not a 700 series, though...I don't think? The internal model number is 9000/782, yes, but it's a 64-bit PA-RISC 2.0 system, while the "700 series" per se are 32-bit. Just...weird. Though I suppose I can at least give it a try...?

Edit: I dunno, maybe I'm wrong about that entirely; OpenPA.net lists a pile of 64-bit workstations with 7xx model numbers internally :/
 
This is maddening. Running the 2000-06 S700 Install and Core OS image gives pretty much the same result - the install environment loads fine, and this time it doesn't kvetch about not having the correct packages, but it still craps out looking for du and df, which are right there on the CD in multiple package sets, but can't be extracted by the version of uncompress that is present in the install environment :/ I'm boggled - how did this thing ever work!?
 
The Debugging A Gorram Enterprise-Level IT Vendor's Flagship Product diary, part the nth: had a bit of a sanity check while banging my head against the wall with du and df - the compressed copies are not stored in classic compress format after all, they're gzip format.

Realizing this, I discovered that, in fact, gunzip was present in the install environment. After popping these into place for the installer, I tried again...and it crapped itself again. This time, the logs showed that A. the packages' checkinstall scripts assumed that the target volumes would be mounted to /disc when in fact they were just mounted directly to / instead, and B. when I made /disc a symlink to / in order to address this, the version of df present on the CD couldn't cope with it.

I eventually just ended up digging through the scripts and discovering that they only need df for two things - repeating the name of the target volume back (apparently?) and reporting the number of free blocks thereon. Ultimate solution: replace df with a script that responds to only these two requests and simply tells the script what it wants to hear :/

It is now finally in the process of running the install - I'm genuinely curious whether this will result in a functional system...
 
Conclusion: a qualified success! The installer kvetched a bit at points, but rendered unto me a bootable, essentially functional installation that gets all the way up to launching the X server before crapping out and dropping back to the framebuffer console. This I'm not sure about; it may actually be my fault, at least in part. This is the Xerrors log (repeated ad nauseam):

Code: 
Tue Mar 24 18:49:15 2020
error (pid 1339): Hostname paparisc is invalid. Setting DISPLAY to ':0'
Skipping library: /usr/lib/X11/Xserver/brokers/extensions/Dpms.1
Unsupported broker interface version reported, Version #: 1.1
Supported broker interface version is, Version #: 1.0
Skipping library: /usr/lib/X11/Xserver/brokers/extensions/HpCr.1
Unsupported broker interface version reported, Version #: 1.1
Supported broker interface version is, Version #: 1.0
Skipping library: /usr/lib/X11/Xserver/brokers/extensions/PolyPrim.1
Unsupported broker interface version reported, Version #: 1.1
Supported broker interface version is, Version #: 1.0
Skipping library: /usr/lib/X11/Xserver/brokers/extensions/Record.1
Unsupported broker interface version reported, Version #: 1.1
Supported broker interface version is, Version #: 1.0
Skipping library: /usr/lib/X11/Xserver/brokers/extensions/Slsdx.1
Unsupported broker interface version reported, Version #: 1.1
Supported broker interface version is, Version #: 1.0
Skipping library: /usr/lib/X11/Xserver/brokers/extensions/Sync.1
Unsupported broker interface version reported, Version #: 1.1
Supported broker interface version is, Version #: 1.0
Skipping library: /usr/lib/X11/Xserver/brokers/extensions/Xie.1
Unsupported broker interface version reported, Version #: 1.1
Supported broker interface version is, Version #: 1.0
Skipping library: /usr/lib/X11/Xserver/brokers/screens/HpCfb.1
Unsupported broker interface version reported, Version #: 1.1
Supported broker interface version is, Version #: 1.0
Skipping library: /usr/lib/X11/Xserver/brokers/screens/Pinn.1
Unsupported broker interface version reported, Version #: 1.1
Supported broker interface version is, Version #: 1.0
Skipping library: /usr/lib/X11/Xserver/brokers/screens/Slsd.1
Unsupported broker interface version reported, Version #: 1.1
Supported broker interface version is, Version #: 1.0
Skipping library: /usr/lib/X11/Xserver/brokers/screens/VrxObsolete.1
Unsupported broker interface version reported, Version #: 1.1
Supported broker interface version is, Version #: 1.0
Skipping library: /usr/lib/X11/Xserver/brokers/screens/Wd.1
Unsupported broker interface version reported, Version #: 1.1
Supported broker interface version is, Version #: 1.0

Fatal server error:
Unable to resolve DDX Broker bids!: /usr/lib/X11/Xserver/brokers/screens/.
The part where it's complaining because the versions of things it provides are newer than the versions of things it supports is...odd, and that one probably isn't on me, but the invalid hostname may very well be. I've never entirely understood what *nix systems expect the hostname to be, other than an identifier for the system - is it supposed to be DNS-resolvable? Can I just put an entry in the hosts file pointing it to the loopback address?
 
Okay, interesting discovery. On a whim, I tried re-doing the install from the same CD - but this time, I chose to run swinstall in non-interactive mode, letting it worry about everything past the initial configuration options. This worked like a charm - not only in resolving the issues with the final installation, but with the whole crazy business about the installer scripts crapping out. I can't for the life of me figure out why that would be, but it ran through the analysis phase without issue, without me having to do anything hacky about du/df. Very strange that only interactive mode would be affected by that, but there you go.

I did still run into the issue with CDE complaining about being unable to contact itself, but changing nsswitch.conf to refer to the hosts file before going to DNS so that the hostname could be resolved to itself sorted that out. Only problem now is that the video driver appears to have defaulted to the HP LEGO standard as a fallback - and after looking it up, it looks like the Visualize FX10 (which is what I have in there, the card that it came with being crashy and showing the wrong colors) was only even announced about the same time this release of 10.20 (the last one I was able to find) came out. Did 10.20 ever support the FX5/10 series? I may end up having to go with 11 after all...
 
Well, it was mostly banging my head against the wall until I managed to bust through the sheetrock :lol: One of the folks over on the IRIX Network forums was able to provide the FX5/FX10 drivers for 10.20, too, so it's pretty well up and running at this point. Now I just need to get some actual software loaded on there...
 
Just found this thread :) Congrats for getting it going. It's nice to see other PA-RISC fans out there.

There was in some of the later 10.20 SD's the FX5/10 support bundled. They're essentially the same card from a 2d perspective. The FX10 has afair 2 or 4 PA-RISC 7150 based processors on it to do vector and geometry calculations for 3d. Usually using PHEGS or StarBase rather than OpenGL if memory serves.
 
There is an OpenGL support package for 10.20, but I haven't really done anything more than the basic spinning-cuboid type tests with the thing so far...really be fun to get some kind of GLQuake or later source port running on this baby, but that'll likely be a long-term project. Maybe at next year's VCF West, if civilization is still here by then...
 
There is a version of Doom that runs on HP-UX 10.20. It even comes preinstalled with the standard system software distribution for HP / Agilent 16700 series logic analyzers. (The 16700 series run on a 150Mhz PA-7300LC CPU).
 
DOOM is also excellent, but unless you're running one of a couple different latter-day ports, it's all software rendering and doesn't serve as a test/demo for the GPU.
 
You must log in or register to reply here.
Back
Top