Screencast: The Linux Boot Process12 Jun
This is a little sample of some material from my training courses, covering the boot process and a little bit about runlevel management. This particular screencast is pretty Red Hat-specific, but as a trainer and consultant, I have to know whatever is thrown at me on any given assignment. It’s 45 minutes long.
Please let me know your feedback, especially if you catch a glitch in the material somewhere!
2 Responses to “Screencast: The Linux Boot Process”
Leave a Reply
I feel this missed all the interesting stuff, for instance the interaction between the initial ramdisk and the /sbin/init process, why we can run /linuxrc on the initrd and it can exit and we still get /sbin/init as process number 1.
I found comments on microkernel vs monolithic to just be annoying, and have no place in this talk. Your title is “The Linux Boot Process”, not “Why Linux is a good/bad design”.
I found the stuff on the run-levels rather dragged, but this is probably because (a) it is all pretty simple stuff, (b) lots of it is Red Hat specific (as you warned) and (c) I don’t use it.
Thanks for this feedback!
I wondered if anyone would even notice that I skipped the initrd magic. I do have slides about it, but that puts the whole presentation at over an hour. I think your comment mirrors my own feeling, which is that I should put initrd back in and take out the runlevel stuff, which would have the beneficial side-effect of making it less (not?) Red Hat-centric.
As for the whole linuxrc and /sbin/init deal, if you take your initrd, run it through cpio, like this: “cpio -i < initrd.img", you'll see in the resulting directory hierarchy that there's actually an "init" binary in there. That is run first, and then later, when the kernel has access to the root filesystem, it runs what we know as pid 1. I'll look more into the minutiae of why init is pid 1, but I have a couple of quick guesses:
1. Because the init run from initrd.img is process 0
2. Because init is the first process actually run in user space from an executable on the hard drive
3. Because init is the first process to actually be managed by a fully-functioning kernel scheduler
By the way, the bit about micro-vs.-monolithic is there because this is part of a training course I give to developers who might be experienced with Linux but don't know much about going out into the community for help with things. It would help them (greatly) to know that the debate has already been happening, and they'll attract flames with any questions about it on mailing lists. It's also a part of an ongoing theme in my training program. There's a collection of "asides" that I touch on if time allows that cover a good number of the religious debates in the community. I understand that without that context, it probably seems a little out of place.
These comments are immensely useful as I try to make a separation between training modules in the context of a whole course, and a screencast that people will actually want to listen to. Putting the content in isolation isn't so easy, and I'm also finding it annoying how long they are. I'm tempted to play more to the stereotypical notion of peoples' shorter attention spans, but I like to think the people who would be interested don't abide by the stereotype. I'll experiment. Thanks much.