Reboot always goes into single user mode

[Belinda Dermody]

I have a HP H50 system under 11.00. This is the first time in a since the install of HP-UX11.00, I did a shutdown -r and it would reboot in single user mode. did a shutdown -h and power back on and it would boot into single user mode. Did CNTL D and it would still just go into single user mode. Did a init 2 and it would boot completely up with all logical volumnes and application. I have not changed anything to the O/S in months.

[Pete Randall]

First, what's in your /etc/inittab?
Second, are there any error messages, either in syslog or in dmesg output?

Pete

[Jean-Louis Phelix]

Perhaps your LIF AUTO file is wrong. Try :

# lifcp /dev/rdsk/cXtYdZ:AUTO -

on your boot disk. It should contain "hpux", but in your case it can contain "hpux -is". You can change it using

# mkboot -a "hpux" /dev/rdsk/cXtYdZ

or your inittab can contain a bad default run-level :

init:X:initdefault:

Regards.

[John Palmer]

Two things to check...

1. The first line of /etc/inittab:
init:?:initdefault
The second field (?) indicates the default runlevel and should be 2, 3 or maybe 4.

2. The AUTO file on your boot disk could be set to boot single user. Check with:
lifcp /dev/dsk/c?t?d?:AUTO -
It should read hpux or hpux -lq (maybe with options in brackets), NOT hpux -lm

Regards,
John

[John Palmer]

Spot the deliberate mistake...

My previous reply should have read 'NOT hpux -is' *NOT* 'NOT hpux -lm'

Ho hum...

[Belinda Dermody]

Thanks for all the responses.

my /etc/inittab
cancun:/var/adm/syslog: head /etc/inittab
init:3:initdefault:
ioin::sysinit:/sbin/ioinitrc >/dev/console 2>&1
tape::sysinit:/sbin/mtinit > /dev/console 2>&1
muxi::sysinit:/sbin/dasetup /dev/console 2>&1 # mux init
stty::sysinit:/sbin/stty 9600 clocal icanon echo opost onlcr ixon icrnl ignpar <
/dev/systty


cancun:/var/adm/syslog: lifcp /dev/dsk/c6t1d0:AUTO -
hpux
cancun:/var/adm/syslog: lifcp /dev/dsk/c0t2d0:AUTO -
hpux (16.2.0;0)/stand/vmunix

I looked for errors when I booted after a halt and no errors showed up on the console window.

[melvyn burnard]

check for a corrupted /etc/passwd or /etc/group file
Also the /etc/inittab may also be corrupt, but you cannot see it, try a default new file from /usr/newconfig/etc

[Belinda Dermody]

Melvin

grpck and pwck came back without any information (that is good).

cancun:/root: pwck
cancun:/root: grpck
cancun:/root:

cancun:/usr/newconfig/etc: diff inittab /etc/
17a18,22
> #ups::respawn:rtprio 0 /usr/lbin/ups_mond -f /etc/ups_conf
> #ems1::bootwait:/sbin/rm -f /etc/opt/resmon/persistence/runlevel4_flag
> #ems2::bootwait:/sbin/cat /etc/opt/resmon/persistence/reboot_flag
> #ems3:3456:wait:/usr/bin/touch /etc/opt/resmon/persistence/runlevel4_flag
> #ems4:3456:respawn:/etc/opt/resmon/lbin/p_client
cancun:/usr/newconfig/etc:

[Kelli Ward]

Hi,
Can you force it to run level 3 either by hpux -i3 /stand/vmunix at the ISL> prompt or /etc/init 3 at #?
Just curious,
Kel

[Belinda Dermody]

Kelli

Yes I was able to do a init 3 and it booted the rest of the way up and all applications started ok, users have been using it for about 2.5 hours now and no complaints.

[Kelli Ward]

Hi,
Sorry about that, I didn't see the init 2 comment at the bottom of your note. I was starting to wonder about your rc scripts, but Now I'm really curious.
I'll let you know if I find anything interesting.
Kel

[Belinda Dermody]

Kelli

All the rc scripts start up ok, the system runs through them when I did the init 2, probably should have done a init 3. I will test later this afternoon, when they go home.

[Kelli Ward]

Hi,
I was leaning toward /sbin/rc itself being the culprit. If it was corrupted, I would think you would have init errors before a run-level s boot. If you have a wise-cracker with access in your midst, that could be a possibility. I know I have them. Fortunately for me (and them), they are smarter than using a production box for pranks, but my test boxes are and have been fair game. ;)
Kel

[Belinda Dermody]

Found the culprit. One of my new guys was fooling around with scripts and stuff and he changed the shell path for root in the password file to point to /usr/bin/sh instead of /sbin/sh.

I changed it back and rebooted and it cycle through without any errors.

[John Poff]

Ouch. Good catch! If I were you, the "new guy" and me would have to go out to the parking lot for a little percussive maintenance. Kind of hard to make those sorts of changes when his fingers are all broken. ;)

JP "the BOFH is my hero"

[Kelli Ward]

Hi,
I'm glad you found it.
Ah, the little things do get us.
As for the new guy, I would gently remind that person not to do it again. Explain why what they did caused the problem if they don't understand and take it an honest mistake. The first time.
Happens again, let the percussions begin. ;)
Have a good weekend.
Kel