> In a merry fashion, I was going along my merry way and hadn't made any
> significant changes to my system for over a week, then all of a sudden
> it starts to hang on boot. The final boot messages say:
> ...
> Init: ID "2" respawning too fast: disabled for 5 minutes
> Init: ID "3" respawning too fast: disabled for 5 minutes
> Init: ID "4" respawning too fast: disabled for 5 minutes
> Init: ID "5" respawning too fast: disabled for 5 minutes
> Init: ID "6" respawning too fast: disabled for 5 minutes
> Init: ID "1" respawning too fast: disabled for 5 minutes
> Init: cannot execute "/sbin/getty"
> ...
>
> and then it repeats this set of messages so many times I can't see
> anything above it).
> with a final message saying something like "no more processes to execute
> in this runlevel" and then it hangs there and says it can't
> execute /sbin/shutdown though it recognizes my "ctrl+alt+delete"
> keystrokes.
>
> After some searching I found that this is a somewhat common problem
> caused on many linux platforms whenever, while booting, Init tries to
> start a process in a given runlevel that has a broken library. The
> getty isn't handed what it's waiting for, so it respawns over and over
> until it's disabled. I need to determine what this broken library
> causing all this is.
>
> So, passing the init=/bin/bash parameter to grub to bypass the init
> process, I looked at /var/log/messages and /var/log/dmesg for any clues
> and couldn't identify the malodorously crashing process causing the
> getty to respawn. How do I look at the full previous set of boot
> messages? Dmesg doesn't show these boot messages about respawning.
>
> I guess to back up, has anyone seen something like this recently and
> what troubleshooting approach would work best here, because I can get my
> hands on decent logs/output that tell me what's going wrong? Thanks in
> advance!
> -Eric
The troubleshooting approach can depend on your distro. You have the right
idea in hunting down a bad or missing library. On an RPM distro you could do
something like:
1) rpm -qif /sbin/getty
This will list the package that owns the file /sbin/getty. In this case, the
getty binary is part of the mgetty package.
2) rpm -qV mgetty
This will verify the mgetty package and list files that have been modified
since installation.
If you see library files that are either missing or modified, you can
reinstall the offending package:
rpm -ivh --replacepkgs mgetty
Other possibilities:
Run strace against the binary. It will list the system calls that the binary
makes on execution. You can then look through the output for errors such as
missing files.
Or you could run ldd against the binary. It will show what libraries the
binary uses. Then, verify that those libraries exist.
-- * The Digital Hermit http://www.digitalhermit.com * Unix and Linux Solutions kwan@digitalhermit.com----------------------------------------------------------------------- This list is provided as an unmoderated internet service by Networked Knowledge Systems (NKS). Views and opinions expressed in messages posted are those of the author and do not necessarily reflect the official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:25:02 EDT