This guide shall help you understand, e.g.
- How does the OpenWrt FailSafe work?
- When does the tmpfs get mounted and
/tmpsymlinked to it and
The Machine gets powered on and some very very basic very low level hardware stuff gets done. You could connect to it over the JTAG Port port and issue commands.
- the bootloader on the flash gets executed
- the bootloader performs the POST, which is a low-level hardware initialization
- the bootloader decompresses the Kernel image from it's (known!) location on the flash storage into main memory (=RAM)
- the bootloader executes the Kernel with
init=…option (default is
- the Kernel further bootstraps itself (sic!)
- issues the command/ops-code
/etc/preinitdoes pre-initialization setups (create directories, mount fs, /proc, /sys, … )
- the Kernel
mountsthe rootfs (root file system), see .. and also udev
- if "INITRAMFS" is not defined, calls
/sbin/init(the mother of all processes)
- finally some kernel thread becomes the userspace
The user space starts when kernel mounts rootfs and the very first program to run is (by default)
/sbin/init. Please remember, that the interface between application and kernel is the
clib and the syscalls it offers.
|S10boot||starts hotplug-script, mounts filesystesm, starts .., starts syslogd, …|
|S50telnet||checks for root password, if non is set,
init daemon will run all the time. On a shutdown command,
/etc/inittabfor shutdown (default is "::shutdodwn:/etc/init.d/rcS K stop")
/etc/init.d/rcS K stop
- rcS executes the shutdown scripts located in /etc/rc.d/K##xxxxxx with option "stop"
- system halts/reboots
|K99umount||writes caches to disk, unmounts all filesystems|
After the bootloader (grub, in this example) initializes and parses any options that are presented at the boot menu, the bootloader loads the kernel.
Example from the openwrt-x86-ext2-image.kernel file entry for normal boot:
- "kernel /boot/vmlinuz root=/dev/hda2 init=/etc/preinit [rest of options]"
This entry in the boot/grub/menu.lst file tells grub that the kernel is located under the /boot directory and the filename is vmlinuz. The rest of the lines are the options that are passed to the kernel. To see how the kernel was started, you can view the options by reading the /proc/cmdline file. You can see what options were passed from grub by logging into the device and typing "cat /proc/cmdline".
For my test system, the options that were passed to the kernel at load time was:
- "root=/dev/hda2 rootfstype=ext2 init=/etc/preinit noinitrd console=ttyS0,38400,n,8,1 reboot=bios"
The options are:
- root: root device/partition where the rest of the OpenWrt system is located
- rootfstype: Format for the root partition - ext2 in this example
- init: The first program to call after the kernel is loaded and initialized
- noinitrd: All drivers for access to the rest of the system are built into the kernel, so no need to load an initial ramdisk with extra drivers
- console: Which device to accept console login commands from - talk to ttyS0 (first serial port) at 38400 speed using no flow control, eight data bits and one stop bit. See the kernel documentation for other options
- reboot: Not sure, but I believe that this option tells the kernel how to perform a reboot
The first program called after the kernel loads is located at the kernel options entry of the boot loader. For grub, the entry is located in the openwrt–.image.kernel.image file in the /boot/grub/menu.lst file.
[ NOTE: See the man page on grub for all of the grub parameters ] In this example, the entry "init=/etc/preinit" tells the kernel that the first program to run after initializing is "preinit" found in the "/etc" directory located on the disk "/dev/hda" and partition "hda2".
The preinit script's primary purpose is initial checks and setups for the rest of the startup scripts. One primary job is to mount the /proc and /sys pseudo filesystems so access to status information and some control functions are made available. Another primary function is to prepare the /dev directory for access to things like console, tty, and media access devices. The final job of preinit is to start the init daemon process itself.
Init is considered the "Mother Of All Processes" since it controls things like starting daemons, changing runlevels, setting up the console/pseudo-consoles/tty access daemons, as well as some other housekeeping chores.
Once init is started, it reads the /etc/inittab configuration file to tell it what process to start, monitor for certain activities, and when an activity is triggered to call the relevant program.
The init program used by busybox is a minimalistic daemon. It does not have the knowledge of runlevels and such, so the config file is somewhat abbreviated from the normal init config file. If you are running a full linux desktop, you can "man inittab" and read about the normal init process and entries. Fields are separated by a colon and are defined as:
- [ID] : [Runlevel(s)] : [Action] : [Process to execute ]
For busybox init, the only fields needed are the "ID" (1st), "Action" (3rd) and "Process" (4th) entries. Busybox init has several caveats from a normal init: the ID field is used for controlling TTY/Console, and there are no defined runlevels. A minimalistic /etc/inittab would look like:
- ::sysinit:/etc/init.d/rcS S boot
- ::shutdown:/etc/init.d/rcS K stop
- tts/0::askfirst:/bin/ash –login
- ttyS0::askfirst:/bin/ash –login
- tty1::askfirst:/bin/ash –login
Lines 1 and 2 with a blank ID field indicate they are not specific to any terminal or console. The other lines are directed to specific terminals/consoles.
Notice that both the "sysinit" and "shutdown" actions are calling the same program (the "/etc/init.d/rcS" script). The only difference is the options that are passed to the rcS script. This will become clearer later on.
At this point, init has parsed the configuration file and is looking for what to do next. So, now we get to the "sysinit" entry: call /etc/init.d/rcS with the options "S" and "boot"
At this point, all basic setup has been done, all programs and system/configuration files are accessible, and we are now ready to start the rest of the processes.
The rcS script is pretty simplistic in it's function - it's sole purpose is to execute all of the scripts in the /etc/rc.d directory with the appropriate options. if you paid attention to the sysinit entry, the rcS script was called with the "S" and "boot" options. Since we called rcS with 2 options ("S" and "boot"), the rcS script will substitute $1 with "S" and $2 with "boot". The relevant lines in rcS are:
- for i in /etc/rc.d/$1* ; do 2. [ -x $i ] && $i $2 3. done
The basic breakdown is:
- Execute the following line once for every entry (file/link) in the /etc/rc.d directory that begins with "S"
- If the file is executable, execute the file with the option "boot"
- Repeat at step 1, replacing $i with the next filename until there are no more files to check
Unlike Microsoft programs, Linux uses file permissions rather than filename extensions to tell it if this entry is executable or not. For an explanation of file permissions, see "man chmod" on a Linux/Unix machine on explanations for permissions and executable files.
If you look at the /etc/rc.d directory, you may notice that some scripts have relevant links for startup, but no shutdown (i.e., /etc/init.d/httpd), while some others have no startup script, but do have a shutdown script (i.e., /etc/init.d/umount).
In the case of httpd (the webserver), it doesn't matter if it dies or not, there's nothing to clean up before quitting.
On the other hand, the umount script MUST be executed before shutdown to ensure that all data is flushed to the media before unmounting of any relevant storage media, otherwise data corruption could occur. There's no need to call unmount at startup, since storage media mounting is handled somewhere else (like /etc/preinit), so there's no startup script for this one.
After the last startup script is executed, you should have a fully operational OpenWrt system.
doc/techref/process.boot.txt · Last modified: 2012/03/18 09:31 by nfsd