(last updated: 30-Jan-2017)
The current configuration is in its original 'as acquired' condition.
05-May-2010
This is one-half of a pair of HP PA-RISC machines that were offered locally on Craigslist. I couldn't resist, having become somewhat of a UNIX bigot, of late. The price was right...$50, which included the main CPU, keyboard, monitor, three-button mouse, external hard disks and CD-ROM drives, along with an HP PostScript inkjet printer, UPS and documentation and HP-UX 11.0 installation media.
The system needs a little cleanup, and is almost operational. It seems that the system is not booting due to lack of proper connection to a network, or the Internet. The seller suggested that if I can somehow break into the boot sequence I should be able to get a singe-user prompt, allowing me to login and reconfigure the network setup.
Also, an external drive (the plain rectangular box) is need as a boot disk, so I need to be sure to connect that up when I try to boot the unit.
08-May-2010
Just a little dusty, not to bad. A Windex cleaning on the exterior and a vacuuming of th interior made things nice. Inside, I was a little surprised to see the method for mounting the drives is nothing more than some polystyrene foam cradles that hold the drives! (photos)
08-May-2010
Inside the system is a very small main PCB, a 3-1/2" HDD, and a 3-1/2" FDD, and that's it! The PCB has four (4) DIMM sockets, all full. Each DIMM (double-sided, Kingston KTM-8MX40) has eighteen (18) 0116400J1E chips.
The hard disk is a Seagate Hawk ST31230N (1.2GB) drive set as SCSI ID 6, the floppy is a TEAC FD-23HG.
The TOY batter is a BR2325.
External disks:
- Plain rectangular "Legasys" (s/n TZ163389) contains: -- Seagate ST15230N (5.2GB) drive.
- Double-height "Legasys" (s/n TZ282341) contains: -- Seagate ST19171N (9.1GB) drive in the lower bay. [bootable to 10.2 "fish"; root password unknown] -- Seagate ST15230N (5.2GB) drive in the upper bay. This unit has been dropped; the rear panel has been shoved inward and the lower SCSI connector has been bent. I'll try to fix it.
- No-name single drive (s/n A096746) contains: -- Seagate ST19171N (9.1GB) drive. [won't spin up]
- HP CD-ROM drive
- HP DAT Tape drvie
- Legasys CD-ROM drive
I tried all of the hard drives, trying to find one that would boot this machine.
The internal drive boots to a Console Login: prompt but rejects everything with a "audswitch: Not owner" error and repeats.
The single "Legasys" drive won't boot, behaves as if there is no boot partition.
The single no-name drive won't even spin up.
Finally found that the lower drive in the double-decker "Legasys" box would boot to 11.0 graphical interface, but I couldn't log into the root account using the password that Peter gave me. The upper drive behaves as if it has no boot partition.
13-May-2010
I spent a few minutes reading the "Model 712 User's Guide" and learned the standard SCSI IDs for HP 9000 systems:
- ID 7 = CPU/Controller - ID 6 = Internal hard disk - ID 3 = DSS tape drive - ID 2 = External CD-ROM drive
13-May-2010
As I discovered a few days ago, the system will not allow me to break into the boot sequence and issue my own boot commands. While reading the "Model 712 User's Guide" I ran across the section related to a Secure Boot Mode (Appendix D, page 15) which describes its purpose and how to defeat it. To defeat it, and get to the boot console prompt, one must disable all bootable devices, then power up, and let the system fail-back to the boot console. Then issue the command:
BOOT_ADMIN> secure off
At that point the secure mode is disabled. By reconnecting the desired boot devices, the system can be restarted and will be in non-secure mode.
14-May-2010
I had a few free minutes this morning and wanted to attempt to get past this secure mode. Using the information gleaned last night from the Users's Guide, I opened the chassis and disconnected the power from the internal hard drive. I then made all the external connectios, including the LAN cable, and powered up. The system presented the boot screen, indicated that it was searching for boot devices, and then nothing. It just stayed that way for almost five minutes. Pressing ESC, or any other key or key combination, had no effect.
Then I realized that it is possible to boot these systems over the LAN, and so I shutdown, disconnected the LAN cable, and re-powered. As usual, I saw the boot screen, the message that it was searching for boot devices, then (at last!) another message indicatin that no boot devices were found, and then it waited. At this point, pressing ESC did indeed drop me to the boot prompt! Wahoo!
Using the boot console commands I checked secure mode with:
BOOT_ADMIN> secure secure mode on
which confirmed that secure mode is on. I turned it off with:
BOOT_ADMIN> secure off secure mode off
and checked it again. Off is shown.
I also checked the system information:
BOOT_ADMIN> informationProcessor revision 2.2 60MHz Instruction Cache Size: 32768 Data Cache Size: 32768 Memory Size: 128 MB Built in floating point coprocessor Board Serial Number 401101RGZW
BootRom Version 1.6
auto boot on auto search on fastboot off
Primary boot path: scsi.4.0 Alternate boot path: scsi.5.0 Console path: graphics
I powered down the system, reconnected the LAN cable and the hard disk power cable and powered back up. This time, the system dropped itself into the boot console since the primary boot device is set for SCSI ID 4, and the internal disk is ID 6. At that point I entered:
BOOT_ADMIN> boot scsi.6.0
and the system begain the normal boot sequence using the internal hard disk. This is very good! There is no valid IP setup (for my local environment) I'm sure, and there were long waits in the boot sequence while the system tried to start various networking deamons. Eventually (~45 minutes) the system tries to start the GUI, but it can't, and just cycles trying over and over.
When I press
Thinking I might get somewhere if I could boot into single-user mode I tried:
BOOT_ADMIN> boot scsi.6.0 islISL> hpux -is
and unfortunately I get a few messages that look like it is going to boot but only get a continuous repetition of:
INIT: SINGLE USER MODE setgroups: not owner su: Unable to initialize group access list
so it would seem that this 'not owner' is a problem, whatever it may mean, for both regular boot and single-user.
Okay, back to using the double-decker external SCSI subsystem that I know is bootable. From the boot console information we see that the primary boot device is expected to be ID 4 and alternate is ID 5 which is what this double-decker subsystem is set up for. Hooked it all up and re-booted.
Works fine! Looks like this setup (HP-UX 11.00) is using LVM. I don't know how that works so need to learn more. Still, the system is up and I'm logged in as root with access. First, I checked the /etc/passwd file and, lo!, it has all the passwords, including root's, set to '*' which prevents anyone from logging in. I don't get it. Also, looks like /bin (/usr/bin) is empty so many utilities and commands are not available.
I mounted the internal hard disk (which has HP-UX 10.20 on it) and can now browse around. The root on this system has a password set in /etc/passwd.
I cannot run ifconfig since all files are lost from /bin, but using set_parms I learn that the IP config is:
address: 129.219.45.155 subnet: 255.255.255.192 gateway: 129.219.45.129domain: la.asu.edu dns: 129.219.17.5
I changed the following:
address: 192.168.1.160 subnet: 255.255.255.0 gateway: 192.168.1.1 domain: (no change) dns: 192.168.1.1
then rebooted into single-user mode. Unfortunately, ping is missing like everything else! But pinging from another machine fails too, so I don't think that the network is working yet.
15-May-2010
After further research last night, learning about HP's Trusted Computer Protocol (TCP), or whatever it stands for, I started to believe that this system might have that enabled. This morning it turns out that TCP is turned on on the external subsystem (scsi.4.0, HP-UX 11.00), but the internal disk is not using TCP. The reason I can't login when booting from the internal disk is that the root password is not what Peter believes it to be. I checked with my handy-dandy password program on eligos and here's what the password should look like if it is 'melodious' using a seed of 'ua':
uaXEKWbEcT7Ic = 'ua'+'mel0dious'
Here's what is in the /etc/passwd file:
uaOYYoKEwQo..
and this shows that using the same seed the password is *not* 'mel0dious'.
I booted into single-user mode using the external subsystem, and then mounted the internal disk. I edited the /etc/passwd file to use my newly brewed password, though this proved difficult since I have no available /bin stuff on this external boot device! I ended up renaming the original and creating a new passwd file with my brewed version of 'mel0dious':
# mv /etc/passwd /etc/passwd.orig # echo "root:uaXEKWbEcT7Ic:0:3::/:/usr/bin/csh" > passwd
I rebooted the system and tried to login, but no go! Okay, let's try again, this time with my favorite password:
# echo "root:..Bmc55MzeFrw:0:3::/:/usr/bin/csh" > passwd
Same result. So either I'm not updating the correct passwd file(!) or there's something else going on. It doesn't look like a 'secure' mode is installed, that does a shadow passwd file style of improving passwords. I'll have to scan the whole system for more password files and see what I can turn up.
16-May-2010
Today I took a different approach, booting from the 11.00 core installation CD, then dropping out to the shell, mounting the internal hard disk and making my changes that way. Also, a little scouting on the HP-UX forums on hp.com showed that the errors I was seeing when trying to boot indicated that the permissions and ownership of some key files was incorrect. Using that forum discussion information and having booted to an 'recovery' shell from the installation CDs, I made changes to four files:
Ownership changed from (101:users) to (root:sys) on:
- /etc/passwd - /etc/group - /usr/sbin/login - /usr/sbin/su
The 101 user turns out to be called 'junk1' in the passwd file, and my guess is that Peter went into the system before selling, trying to clean it up, and somehow messed up the ownership. Or, maybe he did a total restore of the system from some backup tape and the ownerships were not set correctly.
Anwyay, with these changes I can successfully boot into single-user mode with:
BOOT_ADMIN> boot scsi.6.0 isl ISL> hpux -is
I tested my new root password by su'ing to 'peter' (which required no password since I was already root), and from there su'ing to 'root' which required a password. My favorite password worked fine. I haven't yet tried to init to different run levels.
When I let the system boot normally all the way to the graphical login, it gets to the Console Prompt: stage, and then tries to launch the GUI which fails and drops back to the Console login: prompt. At this stage I *cannot* login as root with my newly chosen password. I don't get it, it should be the same.
17-May-2010
After yesterday's adventures I was determind to figure out what's going on. It occured to me that there might some kind of security setup that prevents root from logging in directly from the console. The behavior of the single-user boot, then su'ing to another user, then to root, seems to confirm this. So, now that I have a stable single-user mode, I updated the /etc/passwd file by adding a new user 'jared' with no password, generally taking the UID/GID of the user 'peter'. Indeed, this works. I rebooted the system letting go all the way to the GUI login attempt and fail-back to the Console Login: prompt. There, I logged in as 'jared' with no problem. The I su'd to 'root'. Again, no problem. So it would seem that there is a restriction on root logging in, maybe to prevent telnet logins from 'root'.
17-May-2010
Well, with that sorted out, I still want to get the networking configured. I manually changed the system's IP config using ifconfig:
# ifconfig lan0 inet 192.168.1.59 broadcast 192.168.1.255
which was successful. I can ping the system from another machine, but for some reason I can't run ping, I get:
# ping 192.168.1.1 ping: socket: Permission denied
so it looks like sockets aren't working either. Maybe a missing sock deamon that failed to start because the networking is mis-configured. Okay, then, let's officially change the IP setup:
# set_parms ip_addresschanged from 129.219.45.155 to 192.168.1.59
# set_parms addl_netwrkchanged netmask from 255.255.255.bc to 255.255.255.0 and broadcast from 129.219.45.191 to 192.168.1.255
It took a couple of rounds to get these new settings to take, but all works now.
I'm now having difficulty running certain commands, probably becuase of user or group ownership mixups, as was the case with login and su. I think someone really messed up this system!
26-May-2010
Did it! Using the HP 715/100 as a host, I imaged this system's disk so that no matter what happens now, I can always go back to this point in time.
I removed the disk drive from the chassis so that I could attach it externally to the 715/100 using a combination of SCSI cables and terminator, and I used a spare PC power supply to power it. I also changed the drive's SCSI ID from 6 to 5 for this operation so that it wouldn't conflict with the host system's drive.
With this done, I powered up the system, but left the drive turned off so that it wouldn't be inadvertently mounted as part of the normal boot. I tried a single-user mode boot first for this reason, but have no network connectivity in that runlevel, thus the boot to multi-user mode. Sure enough, the system complained about a drive 5 that it couldn't find. I'm glad I left the drive unpowered.
After the boot was complete, I powered the drive. The after a quick test to check the setup using:
# mount 192.168.1.10:/home/jared /dtrium # dd if=/dev/dsk/c0t5d0 of=/dtrium/HP712.dsk bs=512 2051460+0 records in 2051460+0 records out #
It feels good to have this complete. Now I will be more bold in my explorations and attempts to get a valid login under multi-user mode.
I beleive that this system's secure boot mode is indicative of a general philosophy of the original installer to keep this system as secure as possible, and based on that I beleive that the installer has set up whatever 'extended' security HP-UX 10.20 offers. I still need to learn more about it, and find a way to change the login password, but now I can do so without worry of loosing this whole software installation to some silly mistake. At worst, now, I can always restore tonight's disk image and start again.
28-Aug-2013
These external storage units were acquired without the necessary power supplies. They require 12V via a DIN connector. I found an eBay seller ("jadescomputer") offering three matching supplies with a Buy-It-Now price of $13.95 each including shipping. I purchased two and they arrived today.
After a quick cleanup of the two supplies I tried them out. They work just fine! However, there were some issues that turned up, on on each drive.
The CD-ROM drive's internal fan is worn and will not spin up on when oriented in the normal horizontal way. It will spin when the drive is tilted forward. I removed the cover and lubed the drive with the liquid nylon, and it seemed to work for a time, but an hour after reassembling the drive, the problem returned. More work required.
The DAT drive would not load a tape. It would just spit it back out. I opened the drive and found lots of dust bunnies. I vacuumed it and then with the drive cover still off, I exercised the drive's mechanism a few times and eventually it loaded the tape reliably many times.
18-Aug-2014
On my HP 9000/715/100 I have experimentally tried several times to install HP-UX 11.00 to a scratch disk, to experience the process, and to develop a better understanding of HP-UX on a 'throw-away' installation. Sadly, in those past attempts, while the installation process seemed successful, after I logged in GUI CDE login screen, I would be informed by a popup that the X system couldn't locate the system, and would only give a single OK button, which when clicked would return to the CDE login screen. Thus I was never successful at a 'virgin' installation.
Well, tonight on this system, I tried again. The process was long on the wall clock (approximately 6 hours in all), but it did complete. Sadly, I saw the same behavior, and couldn't get logged in to the desktop!
However, recent adventures with the 715/100 had given me a bit more experience with HP-UX, and I concluded (rightly) that the trouble all stemmed from the fact that the software subsystems were trying to locate the local system using networking, particularly DNS. Even with an up to date /etc/hosts file the system still failed me. Until...
I realized that the system was trying to locate itself on the network, but since I don't have a local DNS server, and the system was installed without defining a domain name, it couldn't successfully do a DNS lookup on itself. And, because I had not been successful at logging in, and therefore hadn't yet fine tuned the networking configuration, I was in a catch-22 situation.
Nevertheless, I could circumvent the networking subsystem by selecting a "Failsafe" login from the CDE screen, and once logged in that way, I was able to run SAM and modify the networking to the required configuration. This solved the problem!
The key steps are these:
- Perform a "Failsafe" login as 'root' and get to the desktop
- Update the /etc/hosts file as needed
- Run SAM and navigate to Networking and Communications -> Name Service Switch
- Adjust 'hosts' line, choosing '/etc/hosts' as primary, and 'DNS' as secondary
That's it! Once the networking configation (/etc/nsswitch.conf) was set up to read /etc/hosts before querying DNS, all worked as desired. No trouble locating itself, other local systems, and all internet hosts.
05-Sep-2014
With this system running again, I want to add it to my 'rack' of systems that are operated remotely from time to time, with no need for keyboard, mouse or monitor.
Well, I've discovered that the system requires a keyboard at the very least, or it fails to start. I can find no way in the PROM configuration to disable this requirement. Some web searching turns up nothing either, except one reference that indicated that it wasn't possible, confirming the requirement for the keyboard. So be it.
Also, a mouse is required for the system to start the X Windows system. Otherwise, it just tries over and over the fire up X without success. I can still login remotely, or on the local terminal, again as long as the keyboard is attached.
25-Apr-2015
Cruising the internet I came across a couple of archives, one of HP-UX 9 and the other of HP-UX 10, from winworldpc.net. These are 7z files and I 'unzipped' them using 7za on a PuppyLinux 5.2.8 box. Each set included two .ISO files and I burned each set.
A quick scan of the CDs shows that the v9.0.7 CDs are not ISO-9660 format, but the 10.20 set is. I'm guessing the v9 discs are in HPFS format, and it turns out the INSTALL disc is indeed bootable using the IPL facility. The 10.20 discs are NOT bootable. Hmm. how to use them?
In any case, I went ahead with booting the system from the v9 INSTALL disc and proceeded with the installation. After initializing the disk drive (using a scratch unit) the installer puts a mini system on the hard disk and reboots. I inserted the CORE OS disc and elected to install all packages. The process took about 30 minutes and the system rebooted, with a New System Welcome screen, and then drops to the console login. That's it. No GUI is offered.
Poking around I was able to get X-Windows started with 'x11start', and once there I discovered some help files that suggested I could run the Ignition configuration tools. Yes! From the root dir (/) I ran '/etc/newconfig/Ignition/configure.sh' and it presented me with a few choices. I selected the one that has the system boot into the VUE desktop. After a reboot, it works!
30-Apr-2015
I installed a new BR2325 TOY battery, removing the CR2025 used temporarily.
25-Jun-2016
I have returned to working with the original software installation on the internal disk drive. I found that the system would (eventually!) boot and end up in a never-ending cycle of trying to start the CDE login environment (X-based) and fail, then try again. I found that I could remotely telnet into the system, logging in as root without trouble. Once in the system, I edited /etc/fstab commenting out the lines for the extra drives (atrium, btrium and ctrium) and rebooted.
This time, it boots (eventually!) and lands at a textual login prompt. I logged in as root and then ran 'startx mwm' to start X11 with the motif window manager. It worked! I don't have the 'desktop' tools, but I can open an xterm window and then go from there. An interesting development anyway.
Copyright © 2006-2025 Jared Blaser. All rights reserved.