processo de inicialização

Este guia o ajudará a entender, por exemplo

• Quando é hora de kexec e quando para extroot_configuration (veja particularmente extroot.theory)?
• Como é que OpenWrt FailSafe trabalha?
• O flash.layout e a combinação de Utilização de sistemas de arquivos no OpenWrt
• Quando os tmpfs são montados e /tmp Quando os tmpfs são montados e /var vinculado a /tmp?
• Montagem de pré-inicialização Scripts de pré-inicialização, montagem raiz e primeira inicialização
• Scripts de inicialização Referência de Implementação do Script Inicial
• Montagem em bloco Montagem de dispositivo de bloco

A máquina é ligada e algumas coisas de hardware de nível muito baixo são muito básicas. Você pode se conectar a ele através da porta JTAG e emitir comandos.

1. o bootloader no flash é executado
2. o carregador de inicialização executa o POST, que é uma inicialização de hardware de baixo nível
3. o carregador de inicialização descompacta a imagem do Kernel de seu local (conhecido!) no armazenamento flash na memória principal (= RAM)
4. o gerenciador de inicialização executa o Kernel com init=... opção (o padrão é /etc/preinit)

1. o Kernel se auto inicia (sic!)
2. emite o comando/código operacional start_kernel
3. O kernel verifica a partição mtd rootfs em busca de um superbloco válido e monta a partição SquashFS (que contém /etc) uma vez encontrada.(More info at technical_details)
4. /etc/preinit faz configurações de pré-inicialização (criar diretórios, montar fs, /proc, /sys, ... )
5. o Kernel monta qualquer outra partição (e.g. jffs2 partition) sob rootfs (sistema de arquivos raiz). Veja flash.layout, pré-inicialização e montagem raiz, e também udev certificar-se de que existe
6. se “INITRAMFS” não está definido, chama /sbin/init (a mãe de todos os processos)
7. finalmente algumas threads do kernel torna-se o processo de espaço do usuário init

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.

1. init reads /etc/inittab for the “sysinit” entry (default is “::sysinit:/etc/init.d/rcS S boot”)
2. init calls /etc/init.d/rcS S boot
3. rcS executes the symlinks to the actual startup scripts located in /etc/rc.d/S##xxxxxx with option “start”:
4. after rcS finishes, system should be up and running

NOTE: Packages you install with opkg will likely add additional scripts!

The init daemon will run all the time. On a shutdown command, init

1. reads /etc/inittab for shutdown (default is “::shutdodwn:/etc/init.d/rcS K stop”)
2. init calls /etc/init.d/rcS K stop
3. rcS executes the shutdown scripts located in /etc/rc.d/K##xxxxxx with option “stop”
4. system halts/reboots

• boot process example for blackfin devices

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:

1. root: root device/partition where the rest of the OpenWrt system is located
2. rootfstype: Format for the root partition - ext2 in this example
3. init: The first program to call after the kernel is loaded and initialized
4. 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
5. 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
6. 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:

1. ::sysinit:/etc/init.d/rcS S boot
2. ::shutdown:/etc/init.d/rcS K stop
3. tts/0::askfirst:/bin/ash --login
4. ttyS0::askfirst:/bin/ash --login
5. 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:

1. Execute the following line once for every entry (file/link) in the /etc/rc.d directory that begins with “S”
2. If the file is executable, execute the file with the option “boot”
3. 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.

• See also Booting on the boot process in general.
• log.essentials busybox-klogd and busybox-syslogd
• watchdog: http://www.google.com/search?sclient=psy&hl=en&source=hp&q=openwrt+watchdog&btnG=Search
• pppd is configured only in network, need this for you internet.connection
• see init, init manpage, http://linux.die.net/sag/init-intro.html