分类: 嵌入式
2014-10-11 17:54:21
Please also see This guide it not up-zo-date! It does not mention |
This guide shall help you understand, e.g.
The Machine gets powered on and some very very basic very low level hardware stuff gets done. You could connect to it over the port and issue commands.
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.
NOTE: you install with will likely add additional scripts!
S05defconfig | create config files with default values for platform (if config file is not exist), really does this on first start after OpenWRT installed (copy unexisted files from /etc/defconfig/$board/ to /etc/config/) |
S10boot | starts hotplug-script, mounts filesystesm, starts .., starts syslogd, … |
S39usb | mount -t usbfs none /proc/bus/usb |
S40network | start a network subsystem (run /sbin/netifd, up interfaces and wifi |
S45firewall | create and implement firewall rules from /etc/config/firewall |
S50cron | starts crond, see → for configuration |
S50dropbear | starts dropbear, see → for configuration |
S50telnet | checks for root password, if non is set, /usr/sbin/telnetd gets started |
S60dnsmasq | starts dnsmasq, see → for configuration |
S95done | executes |
S96led | load a LED configuration from /etc/config/system and set up LEDs (write values to /sys/class/leds/*/*) |
S97watchdog | start the watchdog daemon (/sbin/watchdog) |
S99sysctl | interprets |
The init daemon will run all the time. On a shutdown command, init
K50dropbear | kill all instances of dropbear |
K90network | down all interfaces and stop netifd |
K98boot | stop logger daemons: /sbin/syslogd and /sbin/klogd |
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:
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:
The options are:
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:
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:
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:
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: 2013/11/29 05:12 by digitsm