HP-UX 10.20 install issue

[commod...@gmail.com]

I'm having some trouble getting HP-UX up and running on a PA-RISC workstation I picked up 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... :/

[Lothar Paltins]

Am 24.03.20 um 03:04 schrieb commod...@gmail.com:
> ... 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.
That's the wrong CD. S800 is the version for the 9000/800 servers. For a
workstation you need the 9000/700 CD.

--
Lothar Paltins ds838...@temp.mailbox.org

[John Ames]

> > ... 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.
> That's the wrong CD. S800 is the version for the 9000/800 servers. For a
> workstation you need the 9000/700 CD.

You're right, I was mistaken in my understanding of the classification (I was under the impression that it was a simple divide between the 32-bit and 64-bit systems.) However, using the S700 install CD (June 2000) does resolve the complaint re: no suitable packages being available, but the issue with the analysis stage freaking out due to the lack of du/df remains. I'm a little baffled at this - if the installer needs these, and they're not loaded in the default install environment, how did it ever work in the first place?

In point of fact, they *are* on the CD, in a couple different package sets. Unfortunately, they're stored in compressed form, but the version of uncompress present in the install environment doesn't seem to recognize them :/

[John Ames]

The Debugging An Enterprise-Level IT Vendor's Flagship Product diary, part the n-th: 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...