Kent West wrote:
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.
Ok. I'll assume not at this point because that seems, to me at least, to be somewhat more unlikely than filesystem corruption. And I'd rather deal with 1 problem at a time-- starting with the most likely. :)
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
Ok, right. I was wondering if there was more to changing runlevels than just running scripts; guess not. Sorry I wasn't clear on that, I didn't get much sleep last night (I need the hum of the computer to sleep, apparently); I just got back from taking a nap now that the computer's up. :) Anyway, so just cd into /etc/rc3.d and run the scripts manually like I did in /etc/rcS.d, ok.
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.
Right, that's what I was going to do. Just wanted to make sure that a runlevel wasn't, like, some sort of magical mode that the computer had to change itself, or something, that it was just an indicator of which scripts had been run.
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.
Righto.BTW, what do I do once I find the problem script? Just remove the symlink and then use apt to reinstall it after I get the box back up on its feet? (Hopefully apt and dpkg didn't get fried....)
--- [This E-mail scanned for viruses by Declude Virus]