My limited understanding is it goes like such:
Say your using a Grub bootloader
1. Machine boots up, does all of it's POST and whatnot.
2. BIOS loads what is in the MBR into memory and executes it.. In this case it happens to be grub's first stage.
3. Grub accesses the harddrive and locates the 2nd stage on the file system, loads that up and executes it.
4. This provides a limited user interface at which time it presents a menu to a end user along with a accessable command line.. Usually the user does nothing and the loader times out and uses the default menu entry.
5. This menu entry specifies a kernel, a initrd image, the location of these items and some arguements to pass to the kernel at boot time. (usually at least the location of the root file system.
Now this is were the kernel is initialized. It takes the arguements and whatnot and executes init.
Init is the first program that gets started. Each program in Linux is a fork from another one. Every proccess has a parent proccess that spawned them. Init is the first proccess.
Init then runs inside the initrd. Initrd is a initial root drive or something similar to it. It's a basic memory-only file system that contains scripts, drivers, and a miniture linux enviroment that is used to provide the nessicary drivers or prepare the real root file system before the kernel can access it directly.
This is very optional. If you compile a kernel yourself you can provide the nessicary drivers and such in-kernel that you can avoid initrd. But initrd is usefull for situations were you have things like a network boot, or software raid, or using logical volume management and stuff like that. It's used by distros because by using initrd they can provide a fast and small kernel that is capable of booting and configuring a very wide veriaty of hardware and installation systems.
After the initrd loads the modules (kernel code that is kept seperate from main kernel so that you can optionally load drivers into the kernel at any time) and prepares the root file system then then init reaches a point in the scripts in the initrd that it does a 'pivit root' so that it and the kernel starts accessing the root file system directly.
At that time it enters into various runlevels. Runlevels are different sort of 'running states' that the operating system has configured. Different Linux distros have different setups.
But generally Runlevel 0 is "halt" or "shutdown", Runlevel 6 is 'reboot'. Runlevel 1 or S is 'single user'. Other runlevels different quite a bit.
After performing the change root then the system reads the /etc/inittab file, enters runlevel 1 and uses various bash scripts (usually in /etc/rc1.d/) that it executes in a specific order that starts up basic things like checking the inegrety of the file system, hardware detection, starts basic system services and such things.
Then depending on how the distro has it setup the /etc/inittab or what the administrator has configured then it enters runlevel 2 or 3 or 4 or 5 or other such thing that starts up the network and network services, starts X and the graphical login screen, the virtual consoles and provides a login prompt for the user.
Then it's fully booted and everything should be running.
Of course this is going to differ slightly from distro to distro.