Kernel Panic, Part 2

> Hello, annoyed people. In response to my query about wanting to know
> exactly what a kernel panic error message
> means (and by implication, what to do about it) according to a Linux
> authority, I have received four replies. Let me
> comment on each one.
[...]
> Right, okay, this seems to point in exactly the same direction as two
> other
> helpful comments. I do not know how to check out what device ide0(3,1)
> refers to, nor what that has to do with mounting the wrong file system.
>
> I HAD WRITTEN
>  > I want to know what is going on from an authority who can explain every
> line of this message. Not being able to
>  > find an authority leaves me very annoyed.
>
> PERSON 4 SARCASTICALLY BUT HUMOROUSLY COMMENTED
>  > Linus is rather busy today. Maybe you could try Kofi Anan.
>
> I have used languages where I can look up any error message and get a clue
> as to what is going on. Linux being open source and all that, I kind of
> assumed it would be easier, that I could easily find out where in the code
> the error messages are generated, and back out the problem. Not. So, I am
> annoyed with the entire Linux community that it concocts cryptic error
> messages that only Linus Torvalds could figure out.
>

IMHO, the errors that Linux provides are far more useful than those from
other OSes that shall remain nameless. This aside, the error message "No
init found" does mean exactly what it says -- the kernel cannot find the
init program to which it must pass control.

The last lines of the kernel (namely init/main.c) passes control to the
execute_command string, which is either passed as a kernel option from
Lilo or GRuB or assigned a default:

    575     if (execute_command)
    576         execve(execute_command,argv_init,envp_init);
    577     execve("/sbin/init",argv_init,envp_init);
    578     execve("/etc/init",argv_init,envp_init);
    579     execve("/bin/init",argv_init,envp_init);
    580     execve("/bin/sh",argv_init,envp_init);
    581     panic("No init found.  Try passing init= option to kernel.");

So if all the above fail then the kernel panics and prints the warning,
"No init found."  What could cause this here? For one, init doesn't exist
in the places that the kernel expects it to be. It could also be that an
incorrect binary is there -- e.g., little endian MIPS kernel when it was
expecting a big-endian -- but these are unlikely. Now, if you mucked
around with the binary types that the kernel understands then that's
another story altogether.

OK, so go backwards to see what else could fail. You'd need some earlier
errors (and alas, I don't have your original post) but these may indicate
something like "Unable to mount root partition". Since /sbin/init resides
on the root partition this would cause a cascade of errors.

What could cause the inability to mount /? A few things could be the
problem: 1) Your bootloader configuration is pointing to an incorrect
device; 2) the kernel doesn't know how to mount the root fs (you'd get
previous errors); 3) the root partition is unavailable (disk offline, not
on network); 4) a genuine kernel error.

In case 1), the likely errors are usually human errors. For example, not
understanding how grub assigns numbers to partitions (it counts starting
from 0, not from 1) to adding extra stuff that doesn't belong. It might
also be that the user is misunderstanding the concept of primary and
extended partitions (these were a way of getting around the limitations of
PC BIOSes). The extended partitions are kept in the fourth partition on a
PC system (which is to say, 0,3 because we're counting from 0) and the
extended partitions are then numbered starting from 0. So 3,1 could refer
to the second extended partition.

In case 2), you'd get these for a couple reasons: a) You don't have
support in the kernel for the filesystem; b) you don't have a suitable
initrd; Well, there's actually a C) and D) but these are very unlikely. No
support in the kernel, you say? But you rebuilt the kernel and added these
as a module. That could be a problem -- the modules are stored (usually)
in /lib/modules which is on the root filesystem. But the root fs can't be
mounted because the modules are not loaded. But you can't load the modules
because the root fs is not online. OK, chicken and egg problem. Your
choice is to then either load the fs modules statically or use an initrd
which somewhat gracefully (or clunkily, depending on how many cs classes
you've had) sidesteps the chicken and egg problem.

Case 3 is so broad that I'd be here for another hour typing. If this is
indeed the problem much more information would be required to
troubleshoot.

Case 4 is quite unlikely unless you're developing fs drivers yourself.

So there, in a nutshell, are the problems that can cause the init error
that you mentioned.

OK, but this is the annoyances list and not comp.os.linux.troubleshooting.
So to bring us back on topic -- one of my bigger annoyances are those who
post messages with little information and request the *volunteer*
community to select from a vast number of possibilities the one error that
is causing the problem. Too often the requests for help look something
like:

Subject: System won't boot.
Body:  I can't get this stupid Linux system to work. It just stops with a
bunch of messages and I didn't do anything. What's wrong?

Yes, I've paraphrased this somewhat but this is about as much information
as many people provide.