Root and Single User Mode

[CelesteG]

Okay. How many administrators does it take to tell one administrator, "you screwed up."

Here's my problem. I have a system, which is a stand-by system, no one hardly ever logs into this box, including myself. I go to log in with my general user account...disabled because lifetime has expried. Then I try to log in as the root account at the console....disabled because it is administrativetly locked. Tis has happend before and the fix was in the /tcb/files/auth/whatever/. I simply took out the encrypted password and viola!!!

So, I boot down to single user mode, get in (this is a secure server by the way running 10.20) head down to /tcb/files/auth directory and start messing around with my account file and the root account file. To make a long story short, I removed the contents of the root secure file except for the encrypted UID entry and the encrypted password entry because I didn't want to get caught up on password lifetimes, or expirations, or being locked out and now....I'm sure you can guess the outcome. The server won't boot up and I cannot reach single user mode because I keep receiving and error that says

"INIT:Single User Mode"
"su:Your own ID is not known"

And this basically scrolls across the screen until I shut the machine off.

So, I've screwed up the root account, which makes it really hard to do administration and this server was built before my time, however, no one in our Software Compliance department has record of 10.20 CD's being on-site, (really sucking to be me right now.)

These servers (the production and the stand-by)are about to be upgraded to 11.0 in the next month and a half, which will give it new hardware and a new OS, so it is really nothing to stress over since I didn't muck up the production server. My whole deal is that I screwed it up so I want to fix it or at least know how.

I've tried different commands at the IPL prompt, but they all want to go into single user mode. (hpux -is, hpux -lm, .....) Okay, now dumb question time. Is there a way to get to the operating system underneath single user mode? Is there a command that breaks the boot sequence. Not the 10 second location but once the system actually starts booting the primary path...I remember that there was something like CTRL+SHIFT+|(pipe) that I learned from an HP Technician way back when. I tried that but it didn't work. It could be because of the type of keyboard I have and I need to use some other combination??? Is anybody familiar with this?

Your response is appreciated.

Celeste Gainey

[Denver Osborn]

You'll need to boot from recovery cd or use a make_recovery tape if you've got it.

If you don't want to go that route or it isn't an option, I guess you could put the disk on another box (10.20 or 11.0.. 11i even), then import the volume as something like vg00fix. After imported activate the vg and fsck/mount lvol3. Once mounted get in there and fix tcb entry for root.

Hope this helps,
-denver

[Rajeev Shukla]

If you have one more system to play with i would suggest you to take out the OS (root) disk of this dead system and connect it to another bootable system and mount this disk and edit the files or restore from some backup and fix it.

Other option if you have a unused disk. Connect this unused disk to this system and load any version of HPUX and mount the old original root disk and edit and fix the files

[DCE]

A couple of options come to mind

easiest - boot from the recovery CD supplied with the OS and set up root account correctly

easy - boot from a make tape recovery/make net recovery and select the recovery option

potentially more involved - use a make tape recovery/make net recovery from a similar system, and select the recovery option instead of the install OS

[KapilRaj · Accepted solution]

Do you have CDs for any other version of HPUX ? If yes, I think it is possible to get into a recovery shell using the boot CD. And then 'loadfile' the required commands , like ioscan , mount and stuff like that. Then import the rootvg onto the recovery shelll , do the recovery. I hope you have backup of files which you modified.

I would give it a try. Or else would open the system take the disk to another server and try importing this rootvg and fix it.

Best of luck...

Regds,

Kaps

[CelesteG]

Sorry that it took me so long to post points or to reply back. Once I start digging into something I find it hard to pull myself away. Ultimately, You guyz simply ROCK!!! With your help I have gotten my system back up in it's original state and can now access the root account.

I tried using some ignite boot tapes we had created back in March of '05 but kept receiving an IPL checksum error when attempting to boot from it. Thought about relocating the disk and importing but the production server was the only other server avaiable.

So, I ended up loading a HP-UX 11i CD into this server (Thanks Rapil, I just assumed that I would need a 10.20 CD but 11i worked just fine). I launched the Recovery Shell and ran thru the instructions at the bottom of this post. You all probably know this but in case someone else has the same problem one day.

After going through the steps I was able to cd to /ROOT and put the /tcb/files/auth/r/root file back into place...(yes Rapil, I did make a backup..whew!)

I reboot and was releived when the machine actually booted. I did receive however "account locked in commercial security database". So I took it back down to single user mode and executed /usr/lbin/modprpw -k on my account and roots account.

She's running like nothing ever happend. I love UNIX and I learned so much through this experience. Thanks again guyz!

===========================

1.) run the recovery shell
2.) skip networking when prompted
3.) select 'recover and unbootable HP-UX system'
4.) verify the device file used for /
5.) recover the bootlif/os partitions
6.) verify the path to the bootlif
7.) verify the boot string (mine was 'hpux' - it took me a while to figure out how to find this info)
7.) run fsck
8.) mount the root disk and exit to a shell
9. execute 'loadfile chroot'
10.) execute 'chroot /ROOT /sbin/sh'

[Patrick Wallek]

One thing to keep in mind here. IF the root id gets disabled, you should ALWAYS be able to login from a DIRECT ATTACHED console (serial, LAN or WEB all work the same) if you log in as root directly.

I have had root get disabled on machines several times and have never had to resort to rebooting to reactivate it. You may get the message that the account is locked, but it should still log you in.

I know I'm a little late to the party here, but hopefully someone finds this useful.

[Matthew Ghofrani]

Just another FYI for the above:
If your /etc/security exists but no referance to "console", then even at console you would not be able to log in as root.

Matthew From Boston

[Patrick Wallek]

You mean /etc/securetty

[Matthew Ghofrani]

Yes I did.

[CelesteG]

These are very good points and I agree that it should work this way.

=====
# cd /etc
# ll securetty
-rw-r--r-- 1 root sys 8 May 29 2004 securetty
# cat securetty
console
#
=====

securetty is in place and populated with 'console'. However I could not log into the console machine as root. At first I received "account is disabled", then I received " account locked in commercial database." I directed this console question/issue our network guyz to see what their view is. I don't personally do any of the hardware or cabeling but was under the impression that our servers were connected directly to the LAN. However the behavior I saw when trying to access this server was not one of a console.

Thanks Patrick and Matthew. All information is helpful information.
================================
1st response:
"The NICs on these servers is plugged directly into the equipment in the server room that formulate our network/LAN. When you say 'console' I picture a terminal hooked to a serial port."

My response:
"So, technically, these are not consoles?"

2nd response:
"I guess they are not technically consoles. At least by my understanding of what one is. However definitions change sometimes. To answer your question there is nothing between the server and the LAN."

[Bill Hassell]

The "console" is a very specific interface. It is the RS-232 serial port to which you hook a dumb terminal or PC with a dumb terminal emulator such as Hyperterminal. Now newer computers (not K-class or D-class or older boxes) such as N-class, L-class and the rp-series usually have a special LAN port. It is not a NIC that can be seen in HP-UX. So to answer your question, there is only one console port and for newer boxes, the special LAN console port (labeled as such on the main chassis). Everything else is just another port and is not the 'console'. Once your system is running, when you login, use command tty to see what you are using. The console is called /dev/console.

You probably know this already but editing the /tcb files is never recommended. You can fix a locked root account (logged in on the console) using the passwd command. It will properly handle the fields in the /tcb database files. Some of the fields are not optional (as you've seen).

[CelesteG]

Very good info Bill. Made me go take a look after I found a terminator and cable drawing on the web diagraming the back of this class server (c-class). And....we have two un-cabeled serial ports which from your post this c-class would be utilizing if a console were connected. So this server is basically connected to the LAN via the LAN port and I have no console.

Yes, I found out the hard way that these fields below are required for the system to be able to boot.
name:
u_name:
u_uid:.
u_pwd:
chkent: <--I took this out, whis basically ends the database entry for each user.

[Patrick Wallek]

Since this is a C-class machine, which is technically a workstation, you have to be extra careful about the console. Most workstations have a graphics card of some sort installed and as a result the console is usually set to the graphics card.

If this is the case and you were to just plug a console into the serial port, you would not necessarily have a console automatically. You would have to manually set to console path to the hardware path / hardware address of the serial port.

I know people on the forums have talked about how to do that. I believe this thread could help in that respect, specifically Andrew Rutter's response:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1069837