This articles teaches you how a Linux system starts, or boots — that is, how the kernel gets into memory and how the regular system processes get started.
How Linux boots
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
For one thing, all it says about how linux “gets into memory” is “boot loader finds the kernel image on the disk, loads it into memory.”
If you know nothing about init it might be interesting, otherwise there no real material here.
I know, this is really just an article on init and how to start/stop services.
“This article is excerpted from the newly published book How Linux Works.”
you can always look up info about booting linux on http://www.tldp.org/
I know the following was from an OSNEWS news item.
http://www.pycs.net/lateral/stories/23.html
and this one I am not sure if it was linked to from OSNEWS.
http://arstechnica.com/etc/linux/2003/linux.ars-12172003-1.html
Anyway more reading for those who want to learn
If you’re going to troll, at least don’t impersonate anyone.
The thing I’ve always found cool about the linux boot process is how straight forward it is… once you get to init it’s more init’s procedures than Linux, and the beauty about having such a process as a core part of the boot is that you can boot to almost any process you want, write your own init, or even just heavily modify your scripts for something interesting — it’s quite easy to change the kernel to point at something other than the default init locations and stuff, for a small system where you have a number of compiled in modules and no real modules to load or no real services (possibly embedded spaces) you can kill init alltogether and drop right to a shell or some other app…
To respond to the “SLOW” comment, which may be moderated down by the time you see my comment, my Slack box boots in about 12 seconds from GRUB screen to login prompt — I can’t for the life of me consider that slow. This of course assumes no filesystem checks have been in place.
For x86-like architectures you might like to look at the lniux boot protocol documentation in the kernel source (linux/Documentation/i386/boot.txt). It was [probably] written for boot-loader authors, but may be interesting to anyone curious about the lower-level things that go on.
Also there is a HOWTO called Power On to Bash Prompt (or some such thing) that described the process in some detail IIRC.
An the SLOW comment was just funny. If you’re comparing against L4 (maybe the pingpong demo) then yes, Linux is extremely slow, but against any general purpose OS Linux is right up there in the [subjective] performance stakes IMHO.
And this init system is not used by all Linux distros. I personally prefer the init style used by Gentoo… A tad easier IMO.
and presenting it in a way that isn’t brain dead would be a good article. I remember reading once that someone had integrated a lot of busy box into grub and submitted it to them but was rebuffed because it was too much of a change in focus (i.e., it made sense to people who had never learnt grub).
Yet another article that misses this piece completely as well as other mentioned sources. I’d love to see such scenario added to the picture.
Yours is a typical Gentoo response.
Gentoo uses this very same init mechanism. It’s just that the runlevels are renamed, and that the rc script loads some stuff in parallel, and adds a basic implementation of the requires/provides boot model (which makes it do dumb stuff like restarting apache if you restart the network).
Before init, it’s exactly this. After init, it’s almost exactly this.
Well, here’s the whole thing about initrd
If the boot manager is configured to use a initrd, it loads it into memory along with the kernel, and sets it to be the root directory.
In the initrd disk, there is a very small boot script, which usually loads the driver for the system’s storage (for example, IDE disk driver), then calls pivot_root to switch to the “real” root.
The need for that is obvious, since you can’t read the filesystem on disk unless you have a driver, and you can’t load a modular driver from there.
So, by making the bootloader put the initrd into RAM, you work around it.
BTW: you can see your initrd by mounting it as a loop device.
for a small system where you have a number of compiled in modules and no real modules to load or no real services (possibly embedded spaces) you can kill init alltogether and drop right to a shell or some other app…
Is this how specialized live cd distros like MoviX or KnoppixMAME work?