Ignite-UX client boot error

[David Burgess]

I'm having trouble with my Ignite-UX client. When it boots it moans about the INSTALL file not being valid and that the servers IP address is missing. I don't have the exact syntax. I've rebooted the client with hpux /stand/vmunix at the ISL prompt.

Previously after during an install attempt the it hung after copying the INSTALLFS file to /stand on the client.

The server cannot reboot the client anymore. I'm guessing /opt/ignite/boot/INSTALLFS is corrupt.

I get the message

instl_adm: Cannot read superblock.
instl_adm: Cannot open file: "/opt/ignite/boot/INSTALLFS": Function is not available.

Is it possbible to recreate INSTALLFS?

I don't have a backup as I am still testing.

Regards,

Dave.

[Steven E. Protter]

This stuff is almost always triggered by networking.

Gotta boot off the built in lan card, add in gigabits don't work for boot, though the transfer can be routed after boot through the faster cards.

IT seems counter-intiutive, but its rpobably not the INSALLFS. If the disk checks out that its sitting on its almost always networking

Checklist:

1) lanadmin -x 0 # adjust the number to the card. Make sure 100 BT cards are hard coded in /etc/rc.config.d/hpbtlanconf
2) inst_adm -T test the setup
3) instl_adm -d displays networking setup.

instl_adm -d can be directed to a file, which you can edit and read with instl_adm -f

Server Diagnostic:
tail -f /var/adm/syslog/syslog.log while attempting a client boot. See if you notice anything unusual.

ps -ef | grep boot. There should be two little daemaons running to support proper boot.

netstat -i 3

Will show tranfer stats on the Server NIC.

These tools, may if I'm correct lead you to more information and eventual solution.

SEP

[David Burgess]

Thanks for the response. I was getting nfs errors last week during a previous test and also had the server ip address issue last week.

I missed off that

instl_adm: Cannot read superblock.
instl_adm: Cannot open file: "/opt/ignite/boot/INSTALLFS": Function is not available.

was the output from instl_adm -d.

Whilst looking for the problem I vi'd INSTALLFS and edited out what I thought was corruption. So if it wasn't corrupt it is now. Someone shoot me and take away my keyboard!

On the server the header of INSTALLFS was originally missing the servers ip address etc. The client has this information in its INSTALLFS file (except for the ip address being the client not the server). I've got the output of a previous instl_adm -d saved away.

I've moved INSTALLFS on the server to INSTALLFS.old and ftp'd a good copy from the client. The client is 11.00 and the server is 11i.

On the client I have run

instl_adm -d > /tmp/cfg

and then copied the header (changing the server ip address line to match the server) into the previously good output of instl_adm -d on the server before I vi'd INSTALLFS.

I then ran instl_adm -f /tmp/cfg on the server.

instl_adm -T -f INSTALLFS doesn't error

instl_adm -d now works.

The client now reboots, the install moans that the version on the server (B.4.3.91) is different to the version that the client booted (B.4.2.110) The system then halted.

Obviously I need the correct version of INSTALLFS. Is it as simple as copying the file from the original install CD and then running the instl_adm -f /tmp/cfg command again or have I screwed it totally!?

Regards,

Dave.

[David Burgess]

I've copied version B.4.3.91 of INSTALLFS from the June 2003 11i install CD to the server and run the instl_adm -f and the client now boots without error. I am back in business.

Something interesting is that the June 11i install cds have version B.4.3.91 of Ignite-UX and March has version B.4.3.110.

Is it normal to have older versions on newer CDs? Was there a bug with 110?

Regards,

Dave.

[David Burgess]

It's all gone horribly wrong. The install completes successfully, but when the client reboots for the second time it can't find vmunix. I guess that's kind of fundamental!

Does /opt/ignite/bin/INSTALLFS on the ingite server have a relationship to /stand/vmunix on the client?

Prior to the reboot, when my custom script mirrors vg00, lvextend complains that /dev/vg00 is not in the lvmtab.

Worse case should I be looking at reinstalling ignite-ux? I may as well go for a later version. What's the best way to do this to preserve my client configs and software depots?

Regards,

Dave.

[David Burgess]

Problem solved.

I finally got the post scripts os_arch_post_l and os_arch_post_c working.

The problem was that os_arch_post_l runs

rm -f /stand/vmunix

hence the client had no kernel on boot!

The issue with vg00 not being in the lvmtab I think was due to the client hostname not being set correctly by dhcp and the rcp failing to copy /etc/lvmpvg to the client in the post script prior to mirroring.

Regards,

Dave.