Problem after install

[ray_gun]

I've installed RHAS 3 update 7 for x86_64 on a DL585. After attempting to log in at the console without receiving a password prompt the message "INIT id"1" respawning too fast:disabled for 5 minutes" is displayed. I have checked /etc/inittab and everything looks good there. Also looked in /dev to make sure all ttys were character devices. What's really weird is if I install RHAS 3 update 7 for i386 is that it works fine. I am currently at a loss. Anyone else have any ideas?

[Stuart Browne]

I'm picking that it's trying to boot up into run level 5 (GUI), and is having trouble doing the graphical display.

Check the X logs in /var/log/X*, but if you don't need the X interface, change the default runlevel down to 3 (modify '/etc/inittab', change the 'initdefault' line).

[ray_gun]

Default runlevel is already 3. The installation was done through Kickstart and X was never configured although I'm not sure that would have anything to do with it. The only way I can get in through single user mode.

[Stuart Browne]

So you've gone in in single user mode, and verified it is at 3?

What is the last thing you see during the boot up?

[Manuel Wolfshant]

The first step should be to fill a bug on https://bugzilla.redhat.com. Also you could call/mail RH support, depending on the license type you have.

/etc/inittab is definitely not the problem, but one application spawned by mingetty at login. I can only assume that the problem is somewhere in the authentication chain (maybe pam, since util-linux, which provides /bin/login does not seem to be updated). Maybe /var/log/secure and/or messages can provide more details. You could also try to setup syslog to (temporary) spew the messages on a console, so that you can see them even if not logged in. You can do that by editing /etc/syslog.conf and adding a line similar to one of the following:
kern.* /dev/console
*.info;authpriv.* /dev/console

If this clutters the screen, just replace /dev/console with one of the ttys (/dev/tty7 for instance). You might also wish to replace priority level "info" with "debug". See man syslog.conf for details.


If you have the time, try to see which rpm packages are actually different in the x86_64 tree (versus the i386) and try to isolate the culprit.

[Pau Garcia i Quiles]

Edit the /etc/inittab file and add the -L flag to all of your getty entries

You can also fix that problem by installing the mingetty package and replacing all your getty entries in /etc/inittab with mingetty.

[Manuel Wolfshant]

Mingetty has been (and still is) the default getty program used by RH. So the ideas about replacing getty and/or adding -L to getty are not applicable :)

[Vitaly Karasik_1]

Can you just send us your /etc/inittab?

[Manuel Wolfshant]

Come on, Vitaly ! the inittab is not modified at update, nor by switching among architectures.

[Manuel Wolfshant · Accepted solution]

Come on, Vitaly ! the inittab is not modified at update, nor by switching among architectures.
I have the same inittab on hundreds of computers, using Athlon64 / Barton / Athlon processors and distributions since RH 7.2 till FC 4 and RHEL 3 & 4...

Since the error appears after login attempts, I would say it's rather obvious that the problem lies in the applications spawned by mingetty.

[Manuel Wolfshant]

The inittab is not modified at update, nor by switching among architectures.
I have the same inittab on hundreds of computers, using Athlon64 / Barton / Athlon processors and distributions since RH 7.2 till FC 4 + RHEL 3 & 4...

Since the error appears after login attempts, I would say it's rather obvious that the problem lies in the applications spawned by mingetty.

[ray_gun]

Thanks everyone for your help and especially you, Manuel. After changing my syslog.conf I was able to determine that the problem was PAM related. During my Kickstart I was copying a modified system-auth over and lo and behold pathing is different between the x86_64 and 386 releases. Many thanks.

[ray_gun]

Closing this thread as this issue has been resolved.