Installed 100BaseT driver; reboot failed; what now?

[jmb]

This is a D380, with 11.00 64-bit. Before installing the J3515A 100BaseT card, I installed the software for it from the Application CD, using swinstall. Everything ran without problem, and the system started the reboot. Just before the boot finished, it displayed this message "Exec failed: exec format error", then went to the ISL prompt. I used 'hpux /stand/vmunix.prev' to get around that, so believe it booted from the previous version of the kernel. I've now installed the card, but still get that message on boot. I need to fix that problem with the kernel, so I can proceed with installing the patches for the card, and get it configured.

I'm pretty sure this card should not have a conflict with 64-bit, as I checked into that before.

Any ideas? Thanks

[S.K. Chan]

After you boot up from the vmunix.prev kernel, take a look at what the log files say ..
# cd /var/adm/sw
==> swagent.log, swinstall.log, swagentd.log
Do you see any "obviuos" error ? Which software did you install for this card ? Is it J3623BA ? A HSC card right ?
The error you get "exec ..." can only mean 2 things ..
1) autoboot string is corrupted (not in your case because you can bootup with the saved kernel)
2) kernel corruption due to incomplete swinstall.
Post any findings from the log files here..

[James Murtagh]

Hi,

This error can sometimes be down to the LIF headers being wrong, but as I assume you are booting from the previous kernel from the same disk, they should be OK.

Another (obvious) reason why this error could be occurring could be due to a kernel that has been corrupted during the patch installation. This problem can occur because swinstall relies on resolving the hostname properly.

I recommend that you perform the following checks on your system:

1) Reboot your system using the backup kernel.

2) mv /etc/resolv.conf /etc/resolv.orig
(You may not have this file if you don't use a
DNS server)

3) mv /etc/nsswitch.conf /etc/nsswitch.orig
(You may not have this file in place)

4) vi /etc/hosts and make sure that the you have the following entries in the file:

127.0.0.1 localhost loopback
(ip address of the host) (hostname)

Make sure that the 127.0.0.1 line does not have the hostname of this server on this same line. They should be on separate lines as noted above.

Once the files have been fixed, reinstalling the patch should not corrupt the kernel again.

Hope this helps.

[Niel Greeff_1]

Check that the /stand file system has enough space for the new kernel

You can always rebuild the kernel yourself to see what the problem is

[jmb]

Well, first off, /stand has plenty of room. Also, the 3 log files looked normal, with possibly the only exception being from the swagent.log: "/sbin/mount" exited with a status code of "1". The following is the output from the command: /dev/dsk/c1t2d0: Device busy. Then below is an Error: Entry of filesystem "/dev/dsk/c1t2d0" in "/etc/fstab" could not be mounted." Goes on to suggest commenting out of fstab. Isn't this a red herring, though? What does that have to do with rebuilding the kernel?

I will be checking the other suggestions shortly...

[James Murtagh · Accepted solution]

Judging from the error, I would say that device is the cdrom/dvdrom. If you were installing the patch from the application cd it should have been already mounted, hence a device busy error....first check if this device is the cdrom and then check if you have an entry for the cdrom in the fstab.

[jmb]

Also, James, please clarify. After I rename those files, what is the next step? Is that when I reinstall the patch? Shouldn't I swremove first? The /etc/hosts looks fine, btw. Thanks!

[jmb]

Yes, the device is the cdrom, and yes, there is an entry in fstab for it. The /cdrom was mounted when I did the install, and when the system rebooted, should not the /cdrom have re-mounted? I had not removed the CD.

[James Murtagh]

The problem with the cdrom was not during the boot, but during the install. I can't remember every step the swinstall takes, but it may ensure all devices in the fstab are mounted in case it needs to install files in them. I can't imagine why you would need the cdrom entry in the fstab?

Regarding the reinstall, I would perform the following steps....

cd /stand
cp system.prev system
cp vmunix.prev vmunix
cp dlkm.prev dlkm (directory)

Then reinstall your patch with the same options as before and also "-x reinstall=true".

This should ensure if it does fail again the kmupdate will copy the good kernel (and links) back to .prev again.

If you want to be extra safe and have room if /stand, copy the .prev files and directory to .good extensions too. You can boot off of this if necessary.

[Sandip Ghosh]

In your case CD-Rom will be mounted but that should not have any entry in the /etc/fstab file.

Sandip

[jmb]

James, I followed your suggestions, and also got rid of the cdrom line in fstab. The re-install ran cleanly, and the reboot came back up properly. Thanks!