I have been invited to spearhead the writing of a new "sticky" for this forum. Here is the current draft, and I will edit this post #1 with each new draft. Please comment. Do you see any technical errors? s, would this sticky actually help you? Is everything that I am saying crystal clear? "Old hands," what did I leave out? How can I make it better?

Please make your feedback comments here, as comments to this thread, not as private messages to me! Let's all be able to read one another's comments!

It is very important, here at LQ, that we provide the very best and most-helpful information about the Linux OS that we possibly can. Your feedback will help very greatly in our efforts to meet this goal.

= = = = =
You look at the console of your suddenly-dead Linux system and see this message:

Kernel Panic (not syncing): attempted to kill init!

... but, what does it mean?

The message is actually composed of three entirely-separate parts, as follows:

1. Kernel Panic
2. (not syncing)
3. attempted to kill init!

• Kernel Panic: This indicates an unrecoverable error condition within the kernel which prevents Linux from proceeding any further. As you saw, the system halts in its tracks and the CPUs stop.
• (not syncing) This indicates that the system was not in the middle of writing data to disk when it died. (There may be cached data that never got written to disk, but the panic did not occur during a disk-write.)
• attempted to kill init! ... actually means that "process #1" (which these days could be init or systemd) either stopped running for any reason, or could not start.

When Linux starts, it "manually" constructs one user-process, which is always process #1. It relies upon this process to perform certain functions (which need not concern us here), such that it cannot run – or, continue to run – without it. This privileged process is otherwise like any other user process.

The most common explanation for the "attempted to kill init" message is actually that the process could not start. Messages immediately preceding the panic will show Linux attempting to start the process and, for some reason (given in those messages) failing to do so.

My knowledge is not deep enough to critique this, but, given that we seem to have had a spike in "kernel panic" posts recently, I think that addressing the issue is a great idea.

By-the-by, I learned something from the above.

Is this symptom a characteristic of init or systemd, or both/either?

When init doesn't start, you usually get "no init found" as the third part. At least that's been my experience. I don't think I've ever seen that "attempted to kill" message. Otherwise your summary is excellent.

"Process #1" can be either one, as far as I know, and the kernel message does not change. The message is produced if "process #1" cannot be started or if it terminates for any reason.

Yes, if it cannot find the program-file, a different panic message is produced.

"Process #1" is used for a number of purposes including dealing with orphan processes. If the parent dies, leaving orphans, they get parented to process #1, which promptly "reaps" them. (Bye, bye, orphans ...) This maintains the concept that every process, except #1, always has some parent ... and "process #1 never dies."

Hi,

I agree that any information that will help a new user is important. I suggest that you as OP should consider gleaning from a search here at LQ information or posting by new members point of view for this topic. I found that you were very active to response to newbies for this very subject. I believe that if you look at the issue from their perspective and making relative solutions based on that point will help future queries for this subject so a user will understand thoroughly.

By including a direct relationship with the member/user you will likely produce a very helpful sticky.

LQ is a world community and we as participants must take that into consideration when responding in a manner that everyone can understand.

Hope this helps.
Have fun & enjoy!

I have seen that.

I think we need to make clear that "kernel panic" doesn't mean that there's anything actually wrong with the kernel. I'd say something like

* Kernel Panic: This indicates that the kernel has started running, but either it can't find any instructions on what to do next or the instructions it can find are unusable. All it can do is give up.

* attempted to kill init! This means that the initialisation process never actually started, as the kernel couldn't find how to do it.

That would eliminate the need for your next two paragraphs. Instead we need a simple explanation of the common causes, how to look for them, and what to do about them. Since I have legacy Grub on one computer and Lilo on the other, I'm not well placed to suggest text for that part!

A "kernel panic" is a condition from which the kernel cannot recover – and, because of it, cannot continue running. Linux literally(!) has no choice but to stop dead in its tracks. (In the MPE operating system of the oldie-but-goodie HP-3000 minicomputer, the privileged function call was SuddenDeath(). )

The kernel also has "Oops!" conditions which represent non-fatal kernel errors, but this is off-topic for this sticky.

I agree with the idea in general (and also with David in post #7) and like Frank learned a few things by reading post #1 of this thread (thanks sundialsvcs, on ya!!).

I would also recommend a sticky for Kali Linux, given that people seem to not want to read it's website for whatever bizarre reason(s). As it's a complete waste of members time and kind heartiness, to answer questions that could be easily answered by visiting it's website (particularly the "Should I use Kali Linux?" part of it).

Just my anyway.

Hi,

All comments are great and thank you to sundialsvcs to start this out. It can go into the Linux->Kernel forum, or Newbies, or another place. Therefore it may be helpful to hear best where members feel it should be posted.

Our intentions would be to organize a final draft of all thoughts and make a one post sticky, ideally.

I specifically invite anyone who wants to ... to re-write it! Post your version! Let's make this a great "sticky."

What I suggest is that you continue in this thread, but also create a blog entry where you cite a link for it repeatedly as inputs occur. Then edit your blog to coherently detail the whole intended sticky. This way you can capture a draft of it, update it, without repeating it in this thread, but also engender new discussion points by those who view this thread.

I would cross refer to this link as part of the blog, for now, so as to continually tie each item together as references. Note that users who read your blog entry can offer comments either moderated by you, or freely, depending how you set it up.

Looks like you have a few blogs and even as of this year, therefore you have experience with LQ's blog interface.

It's been a few years for myself compiling a custom bootloader and kernel. However I do feel that part of this sticky advice would apply greatly to the persons who have rebuilt their kernel for some reason.

My experiences are more uboot (for things like MIPS or ARM).

My main feedback is that printk() is your friend. I've done so very many custom drivers where they have nearly zero chance of working until they get correctly set up. Meanwhile there are oddball things like the mappings of I/O or interrupts ... floats for some reason, and therefore one needs to know all the possibilities they can or may encounter at boot time. Thus my experiences from that time were that we needed to put in printk's to illustrate "got here", ... "and here ...", "made it! ... file/line", where we'd fix one item, move forwards half a step and have to fix more items, and then discover a remapped I/O if we had a system configuration change. Multiple boots, very tedious, however that was it. We could've used a BIOS debugger or an emulator for the x86. It took a lot and in the very early startup code, you don't get symbolic debugging, you have to compare the object code PC against a symbol file, and re-base that off of the location in memory where it is running from. I don't really have a clean way of saying that all, however just trying to emphasize that printk() is your friend, ... and why.

I'm of the group where KDB was rare to ever work, and really never gave me any worth.

I plan to leave this thread open for about another week before submitting a final draft for consideration by the gods.