help.. my system is down..

[gbruner]

i need to apply the dst patch to 3 pa-risc production servers running 11.0.
i dont want to apply patch directly to production, so wanted to use a test box.
we had 3 test server possibilities for that purpose however these are systems have not been used in 6 months.

on all 3 test systems, all passwords expired.
Have to access through single-user mode.
root password to all 3 test systems are lost.
all 3 were trusted systems with boot authentication.

in an attempt to get around this boot authentication, i took the following action on one of the test servers:

in single-user mode, created a new id "super" with superuser priveleges.
rebooted.
logged in as "super" and went to /tbc/files/auth/r
in file "root", deleted all lines after the password line so that file look like this:

root:u_name=root:u_id#0:\
:u_pwd=Uz5WF27durNLs:\

now i was able to su to root and a password was not even required.
as root, i applied the dst patch to the system.
rebooted.

so far so good. now it gets ugly.

the system automatically dropped into single-user mode during the boot process when it got to /sbin/ioconfig for some unknown reason.

i searched these forums for correct answer as to what could be the problem causing this automatic drop into single-user mode. i found what i'm sure is the wrong answer, and, unfortunately, applied it.

i did /sbin/ioconfig -c

if there was some problem that was causing the system to drop into ioconfig, it probably doesnt matter now. sitting in single-user mode, the only filesystems that show when i type 'mount' are '/' and '/stand'.

is there any way to recover this system now?

with the other servers, can anyone see where i might do something differently with my hack into root that would prevent the system from dropping into ioconfig upon reboot? i assume that is what caused the problem of automatically dropping into single user mode..

[Peter Godron]

Hi,
the DST patch is a non-reboot required patch.
It may be a co-incidental disk crash?
Have you tried mount -a to get /etc as there should be a copy of the ioconfig file to the one on /stand.

And, of course, you have made backups before you started this, right ? ;-)

Please update us as you go.

Please also read:
http://forums1.itrc.hp.com/service/forums/helptips.do?#33 on how to reward any useful answers given to your questions.

[gbruner]

Actually, HP has advised a reboot for the DST patch because they admit that they may not have identified all of the O/S services that are caching tztab. cron and syslogd cache tztab and would need to be restarted at the least if you are not going to reboot.

and, no, i did not do a system backup before my hack attempt. bad mistake. if i have to recover then at least i am recovering on a test system that has been retired for the past 6 months.. but it is best practice to always do the full backup before making any changes to system files like this.

what im trying to determine now whether it has come to the issue of reinstalling o/s from scratch after doing an ioconfig -c..

i have an ignite tape and a backup tape from 6 months ago.

[Court Campbell]

You should be able to login as root through the console even with the account locked. I am not sure what is causing you to boot into single-user mode. My first guess would be to look at the inittab file and see what the initdefault is. If I remember correctly ioconfig is apart of the boot process and not a n init level.

[Court Campbell]

Found here:

http://docs.hp.com/en/B2355-90691/ioinit.1M.html

If /etc/ioconfig is corrupted or missing when the system reboots, ioinitrc brings the system up in single-user mode. The user should then restore /etc/ioconfig from backup or invoke the ioinit with the -c option to recreate /etc/ioconfig from the kernel.

Hope this helps.

[gbruner]

Court, yes I saw that piece about ioconfig and I think that has what has got me into trouble. I did ioconfig -c and I thought that afterwards rebooting would lead me into a normal boot, however I rebooted after doing that command and was dropped into single-user mode again..

My problem with dropping into single-user mode is somehow related to my edit of the /tbc/files/auth/r/root file.

[Patrick Wallek]

What you might need to do is edit the /tcb/files/auth/r/root file and put back the extra lines you deleted.

Why exactly did you delete those?

The encrypted password is only on the ':u_pwd' line. If you wanted to blank out the password all you needed to do was make the :u_pwd line look like this:

:u_pwd=:\

The other lines contain other important information that is apparently needed by the system.

[Court Campbell]

Sorry, i was thrown off by your original post. You stated that you did

i did /sbin/ioconfig -c

and I think you meant to say you ran

i did /sbin/ioinit -c

[gbruner]

Patrick, that is a good idea, but I am sitting in single user mode now and I am only able to see '/' and '/stand'.. If I try to 'mount -a', thats all that shows up.. I guess that was because of the ioconfig -c I did..

[Court Campbell]

what happens if you issue

vgchange -a y vg00

[Jeff Gyurko]

Can you boot to lvm maintenance mode (hpux -lm) and export vg00, then import it? If you used standard lvol naming and let the system create the name, you should be fine after that. Boot to single user after you have imported and see if you can issue the mount -a.

When you issue the ioinit -c (this is what you meant right?) that caused all previous binding to hardware devices to become lost. Be aware that your ctd's may not be the same as they were so you may have to check devices before you import.

[Court Campbell]

Last question:

Are the three test servers identical? If so you get root's account unlocked, etc on one of the other servers and make an ignite image using:

make_tape_recovery -I -x inc_entire=vg00

This assumes you have a tape drive attached. Then restore the ignite image to the troubled test server. At this point is may be faster to do this, or re-install, since it is only a test box.