11.00 patch mismatch? telnet/tcp: accept: invalid argument

[mvpel]

So I thought I'd be ambitious and patch up an old B180 system we have here to the latest (2004) 11.00 Quality Pack and associated recommended standalone patches from the patch finder, since we're not yet allowed to scrap it.

However, once I finished that the inetd was no longer able to function properly, complaining as follows:

telnet/tcp[123]: accept: invalid argument

Identical errors, except for the /etc/services protocol name, for rlogind, ftpd, etc. X-windows doesn't work either.

This suggested to me that there's a mismatch between the inetd version and the library which contains the accept() call, where a newer inetd is expecting functionality that the older version of the library's accept() call doesn't recognize, or vice versa.

I tried reinstalling the ARPA transport cumulative patch, but realized that that was just kernel libs in /usr/conf, not shared libs.

Any suggestions aside from backing out patches? Are there any salient patches not included in the Quality Pack that I should apply?

[Steven E. Protter]

Shalom,

A mismatched patch would fail to install.

Take a look at the swjob log of the installation for clues.

You may need to restore this system to an Ignite backup to correct this problem.

SEP

[Duncan Edmonstone]

does this help:

http://www11.itrc.hp.com/service/cki/docDisplay.do?docLocale=en&docId=emr_na-c01012460-2

HTH

Duncan

[mvpel]

Duncan - I don't have access to that document. Evidently my account isn't linked to our support contract yet.

[Patrick Wallek]

In a nutshell, it sounds like some dependent patches were not installed for some reason.

You need to install the main ARPA patch, plus all of its dependencies, which are listed below:

PHNE_27886 s700_800 11.00 cumulative ARPA Transport patch

Dependencies:
PHNE_27651 s700_800 11.00 Cumulative STREAMS Patch
PHKL_21857 s700_800 11.00 enable IDS/9000, fix accept() syscall errors
PHKL_22142 s700_800 11.00 Cumulative LOFS, select(), IDS/9000 support

[Patrick Wallek · Accepted solution]

Further research:

The newest ARPA patch is PHNE_35729, released in Feb. 2007.
http://www11.itrc.hp.com/service/patch/patchDetail.do?patchid=PHNE_35729&sel={hpux:11.00,}&BC=main|search|

It's dependencies are:
PHCO_21187, PHCO_23651, PHCO_23791, PHKL_18543, PHKL_19202, PHKL_20016, PHKL_23409, PHKL_27980, PHKL_28766, PHKL_29385, PHKL_35742, PHKL_35828, PHNE_27902

[mvpel]

That turned out to be the problem - I had pulled that latest ARPA cumulative patch into the bundle from the patch database, but didn't pull all its dependencies. Backing out that patch restored everything to proper operation.

I was surprised that the SD didn't grouse about missing dependencies, but it is 11.00 after all. When I tried "match what target has" on the patch depot, it couldn't find anything to mark.

But it looks like the patches have at least fixed the original problem of spurious EMS alerts about the CD-ROM drive, so hopefully this will be the last thing we have to do to the system before it's shredded and turned into a bumper or brake disc. At least it'll be useful then. :D

[mvpel]

Backing out patch PHNE_35729, which installed without at least one dependency.