"INIT: cannot execute '/etc/rc.d/rc.S'" - Slack not booting, help needed
 

Hi! Yesterday I went bed and left my Slack 10.2 (2.4.29) box running. When I woke up, the computer was "frozen" with a kernel panic. Okk, so I turned it off and on and for my surprise it wouldn't boot up. I get the following error after the "Freeing unused kernel memory" line:

INIT: version 2.84 booting
INIT: cannot execute "/etc/rc.d/rc.S"
INIT: Entering runlevel: 3
INIT: cannot execute "/etc/rc.d/rc.M"
INIT: cannot execute "/sbin/agetty"

...and so on. I'm not sure of what is happening or what can I do to fix it. I'm on Slax now and turning to you guys for help. Anyone got a clue?

Thanks on advance, Daniel

* Pardon me for the rough english, not my native language.

If you have a rescue disk available, boot from it and run fsck on your HD. It looks like your HD crashed, and needs to be cleaned up. (If possible -- If it was a hard crash, you may need a new disk drive and to restore from your back-up system.)

Hi PTrenholme, thanks for your response. I had to run fsck in force mode. Apparently it did found an error in my hard disk, but even after correcting it I can't boot my machine. Any other guess?

Thanks, Daniel

Slightly off topic, but nonetheless related, I recommend that users who are comfortable with recompiling a kernel enable the SysRq kernel reboot option. I have seen my share of system freezes and with this option enabled I can use the keyboard sequence of Alt-SysRq-r, Alt-SysRq-k, Alt-SysRq-e, Alt-SysRq-i, Alt-SysRq-s, Alt-SysRq-u, Alt-SysRq-b, to safely reboot my box. I seem to recall only one time when this sequence failed to reboot a locked box. Very handy.

Related to the thread, if you possibly can do this, type at the command line touch /etc/forcefsck. That command will create a zero byte file. During the next reboot the Slackware scripts are written to look for this file and will automatically force a file system check on all file systems on the disk.

I'm not sure what you mean by "force mode," but if you mean you asked it to proceed when the file system was not mounted "read only," ignoring the warning that this was likely to kill your drive, you have probably lost the partition contents.

If you followed my suggestion and ran fsck from a Linux rescue CD, then you need to reinstall the damaged file(s) -- the ones listed when fsck reported the error location(s). Those files should be in your dump files, so just restore them.

That assumes that you have been running dump on a regular basis to maintain a backup-up. If you haven't been making regular system backups, then you'll have to try to copy the files from your installation disk(s). Again, you can do this from your rescue CD.

Hi PTrenholme and Woodsman, thanks for your responses. With a bit of luck I solved the problem. I just had to search here on LQ for topics reporting similar errors. I found out that most likely the problem was related to corruption of whether the inittab, the init scripts or the interpreter. After some attempts, turned out that replacing some glib files (which I guess bash needs to run properly) fixed it.

PTrenholme, hehe, actually I don't even know what dump is for. You can see that I haven't been running it regularly. Now I'll learn what it's for and do it. :) Ohh, by "force mode" I meant when I first ran fsck it reported my filesystem was clean. So I had to force it to check it anyway with the -f tag, I guess.

Woodsman, thanks for the SysRq tip but would you mind explaining to me a bit further how to implement it?

Grateful, Daniel

Try this:

Compiling the 2.4.x Linux Kernel

Check step 21.

I never have tinkered with the 2.6 kernel, so you are on your own for that, although I expect the process is similar.