[lug] Booting issue. Deb Etch
Gary.Hodges at noaa.gov
Tue Apr 1 10:34:58 MDT 2008
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
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
More information about the LUG