Vikki Roemer wrote:
Kent West wrote:So boot into single-user mode, or start Linux from the lilo prompt with something like:boot: linux single init=/bin/bash or boot: linux -b (see man init)to start a minimalist system (-b = "emergency"), and see if the machine lasts for any length of time.So far, it's been up a half hour or so, and it's still ok. I used 'linux single init=/bin/bash', btw. If the problem were time-dependent, it would've hung within 5 minutes of booting. So the problem is fs corruption, I think. Does that sound about right?
Sounds about right. Unless one of the scripts is hitting some hardware that's been damaged.
Then the hardware is probably okay, and you've just got some file corruption or something similar. The "linux -b" option at the lilo prompt should allow you to then start running the startup scripts manually to find out which ones are causing you grief.Phew, ok. As I'm booted now, can I manually get to runlevel 3 and run the scripts? I had to manually run the /etc/rcS.d scripts, but I'm not sure about changing runlevels. Is there anything special about runlevels that I can't tweak manually? Or do I just change runlevels by running the scripts for the runlevel and it'll take care of itself? I'm pretty sure that if I switch runlevels the *normal* way (through telinit/init), I can't run the scripts manually. Right?
They're just scripts. When you change runlevels, with a command like "init 3", you're just initiating a process that runs the /etc/init.d/rc script with a parameter that matches the runlevel. That rc script just goes to the appropriate rcX directory and runs those scripts
So if you change runlevels, you're going to run all the relevant scripts, and you may have a hard time figuring out where the lock-up is occuring. So instead, I'd look at the scripts in that runlevel directory and run them manually to see where the lock-up is happening.
If you change runlevels, the scripts will run automatically, but you can then run the scripts manually also afterwards, assuming you don't freeze up before that point. To avoid the freeze-up, don't change runlevels; instead, run the scripts manually to find the culprit.
-- Kent