swacl and users other than root

[Bob E Campbell]

Well, I ask a question that finally gets us somewhere...

That INDEX file is the data that swlist is trying to display. That file being gone is obvious, but not clear why it is gone.

INDEX is a master file built from the fileset data. Does the command:

# find /var/adm/sw -name INDEX

find an obviously large selection of files? If so then the master should have been rebuilt when the new SD was installed.

Is /var tight on disk space?

Do you see any messages in /var/adm/sw/swagent.log for the last install or remove that point to the failure? What is the full data for the seg fault?

If the logs are clean try running again after setting the envar SDU_DEBUG=2. If you need something to install try Software Assistant (SWA - https://www.hp.com/go/swa)

For the record, /var should be 555 bin:bin and /var/adm should be 755 adm:adm.

[Armin Kunaschik]

My questions assumed that the system config is sane... sadly it seems not to be.

There is a way to recreate the INDEX file... since it's not there anymore, there is no risk in creating it.
Try the following:
# cd /var/adm/sw/product
# find . -name INDEX -exec cat {} >>INDEX.new \;
# mv INDEX.new INDEX
# chown root:sys INDEX
# chmod 644 INDEX

Then check sw-commands again.
If the INDEX files of all products are still there, this will successfully recreate the INDEX. Otherwise something very destructive happened to the IPD and you might need to reinstall the OS...

My 2 cents,
Armin

[Armin Kunaschik]

@Bob BTW: running a tusc trace would probably lead to the same results... the missing INDEX file.

[Peter Biron]

I have tried what Armin suggested.
I do get some product listings now after it spews out a ton of these types of messages:

The duplicate product has been marked as corrupt, and its tag
attribute changed to "_product_230813".
ERROR: Duplicate definition for the product "PHKL_38736", beginning
at line 230883. This product defines the same values for the
same version attributes as another product or bundle contained
in the root (installation). Those attributes are

PHKL_38736,l=/,r=1.0,a=HP-UX_B.11.11_32/64,v=HP

[Peter Biron]

Also it did not fix the issue with any user other than root being able to run swlist. I still get the Memory fault when I try that as a non-root user.

[Armin Kunaschik]

Hm... looks like your IPD is not in the best condition. Please remove the mentioned block manually from INDEX for testing. What errors/warnings is "swverify \*" displaying now?

My 2 cents,
Armin

[Bob E Campbell]

I would advise caution here. It is possible that there is minor corruption of the IPD and the system is fine but it is just as likely that there is true system corruption of one type or another.

A full backup followed by a cold-install of the system will get you back to a known good state. While this is a big hit, I *really* love known good states.

If that is not an option you might want to contact HP support. I have faith in my skills, but would not choose to do brain surgery without system access...

That said, if you want to continue start with posting the /var/adm/sw/swagent.log for the command "swverify \*".

[Peter Biron]

:/var/adm/sw $grep -i swverify swagent.log|more
* File "/usr/sbin/swverify" could not be removed. It was renamed
* File "/usr/sbin/swverify" could not be removed. It was renamed
* File "/usr/sbin/swverify" could not be removed. It was renamed

I did not expect that. What does that mean?

[Peter Biron]

Maybe we should start over here. All the functionality of the SW commands work fine - as long as I am root. If I become any other user I get seg faults and memory errors. This would leave me to believe the commands and system all seem to work UNLESS I try as a non-root user. Commands as root all work as advertised. Sorry if that wasn't clear before. That said I did reinstall the SD suite with the reinstall option set to true. Same boat. I'm thinking it HAS to be some kind of permissions issue. How do I make sure all the perms are correct? Thanks.

[Bob E Campbell · Accepted solution]

Do not worry about those swrverify messages, they are normal. If a file is busy during an installation it is moved out of the way and removed at a later time. The sw* commands are all hardlinked and should be expected to be busy during a swinstall.

What does the swagent.log show after a "swverify \*" command? That will find any permissions problems and/or broken dependencies or corruptions.