[lug] Booting issue. Deb Etch

[Gary Hodges]

Gary Hodges wrote:
> Nate Duehr wrote:
>> Gary Hodges wrote:
>>> Gary Hodges wrote:
>>>> I attempted an upgrade (Sarge -> Etch) on a AMD K6-III machine, and 
>>>> was having an issue during the boot process.  I finally gave up and 
>>>> just reinstalled.  Same problem.
>>>>
>>>> The problem:
>>>> During the boot process it gets to a boot message saying udev is 
>>>> being fully populated.  Then I get two messages about the BusLogic 
>>>> adapter being successful, then...
>>>>
>>>> INIT: Cannot execute /sbin/getty
>>>> INIT: Id 1 respawning too fast: disable for 5 minutes
>>>> INIT: Id 2 respawning too fast: disable for 5 minutes
>>>> INIT: Id 3 respawning too fast: disable for 5 minutes
>>>> INIT: Id 4 respawning too fast: disable for 5 minutes
>>>> INIT: Id 6 respawning too fast: disable for 5 minutes
>>>> INIT: no more processes left in this runlevel
>>>> INIT: Id 5 respawning too fast: disable for 5 minutes
>>>>
>>>> If left it seems to repeat in some sense.  If I hit Ctrl C after the 
>>>> second BusLogic message it sometimes completes the boot process.  It 
>>>> sometimes produces those INIT messages too.  I don't know if Ctrl C 
>>>> does anything, but it gives me something to try.
>>>>
>>>> I have the 2.6.18-6-486 kernel installed.  I tried the 2.6.18-6-686 
>>>> kernel but it segfaults during the boot.  Once running the machine 
>>>> seems to be OK.
>>>
>>> A little research later...  I'm gathering from some web searching 
>>> that maybe I should comment one or more, or maybe all, of the 
>>> following lines from the /etc/inittab file.
>>>
>>> 1:2345:respawn:/sbin/getty 38400 tty1
>>> 2:23:respawn:/sbin/getty 38400 tty2
>>> 3:23:respawn:/sbin/getty 38400 tty3
>>> 4:23:respawn:/sbin/getty 38400 tty4
>>> 5:23:respawn:/sbin/getty 38400 tty5
>>> 6:23:respawn:/sbin/getty 38400 tty6
>>>
>>> Does this sound right?
>>
>> If you don't know why getty is dying, yes ... that would stop the 
>> respawning.  Init is just trying to do what it was asked... start up 
>> terminal getty's on tty1 through tty6.  Perhaps those devices don't 
>> exist (renamed during upgrade, symlinks busted, who knows).
>>
>> Are there other lines in there with gettys running for your console? 
>> That's what those are... under older versions.  If you take them all 
>> out, you may find yourself without console access.  Make sure you have 
>> SSH up and running and tested before you dump them so you can get back 
>> in and fix it -- in other words, don't lock yourself out.
>>
>> My Etch machine has all of those...
>>
>> durango:~# cat /etc/inittab | grep tty
>> # /sbin/getty invocations for the runlevels.
>> # characters of the device (after "tty").
>> # Note that on most Debian systems tty7 is used by the X Window System,
>> # so if you want to add more getty's go ahead but skip tty7 if you run X.
>> 1:2345:respawn:/sbin/getty 38400 tty1
>> 2:23:respawn:/sbin/getty 38400 tty2
>> 3:23:respawn:/sbin/getty 38400 tty3
>> 4:23:respawn:/sbin/getty 38400 tty4
>> 5:23:respawn:/sbin/getty 38400 tty5
>> 6:23:respawn:/sbin/getty 38400 tty6
>> # Example how to put a getty on a serial line (for a terminal)
>> #T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
>> #T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100
>> # Example how to put a getty on a modem line.
>> #T3:23:respawn:/sbin/mgetty -x0 -s 57600 ttyS3
>>
>> It's whining that it can't execute /sbin/getty.  Have you checked it's 
>> permissions?  Something whack permissions in /sbin?
>>
>>  From my Etch box here...
>>
>> durango:~# ls -al /sbin/getty
>> -rwxr-xr-x 1 root root 14796 Dec 22 06:47 /sbin/getty
>>
>> What do you get if you type....
>>
>> durango:~# getty
>> Usage: getty [-hiLmw] [-l login_program] [-t timeout] [-I initstring] 
>> [-H login_host] baud_rate,... line [termtype]
>> or      [-hiLmw] [-l login_program] [-t timeout] [-I initstring] [-H 
>> login_host] line baud_rate,... [termtype]
>>
>> That's what I get.
>>
>> Or perhaps you mashed the permissions in /dev somehow, or udev did, 
>> or... (insert other unknowns here)...
>>
>> crw------- 1 root root 4, 1 Mar 31 14:36 /dev/tty1
>> crw------- 1 root root 4, 2 Mar 24 17:03 /dev/tty2
>>
>> ... etc.  Check those.
>>
>> This stock Etch box has 755 permissions and root ownership on the 
>> /sbin dir, also... might check that if you did something and whacked it.
>>
>> drwxr-xr-x  2 root root   4096 Feb 20 13:07 .
>>
>> And lovely Crapcast (Comcast) just crapped out to the remote location 
>> where my Etch box is, or I'd send you some more... see if any of that 
>> above looks wrong on yours...
>>
>> I just logged into a different location and Etch box and confirmed all 
>> of the above.
>>
>> Also it's listed as an "essential" package, but I suppose during your 
>> upgrade you may have missed an error installing the util-linux 
>> package.  Check to see that it's really installed and not flagged as 
>> held back, etc.
>>
>> root at anotherbox:~# dpkg --get-selections | grep util-linux
>> util-linux                                      install
>>
>>
>> Nate WY0X
> 
> Thank you for your comments Nate.  I was getting ready to dig in, but it 
> seems I may have a hardware problem.  It will be tomorrow before I can 
> work on it more.  I'll report back what I find.

It turns out the SCSI card was bad (BusLogic BT-958) .  This computer 
ran continuously for three or so years.  After the upgrade it didn't 
work right so I didn't suspect the hardware.  Well, I suppose something 
may have changed in the drivers between Sarge and Etch, though I'd find 
that surprising.

Kernel 2.6.18-6-686 still segfaults.  I read a post or two that 
guaranteed the AMD K6-2 and K6-III CPUs were supported in this kernel. 
I guess not.

Sorry you wrote that long reply Nate when it turned out to be a hardware 
issue.

Gary