Go: Inittab files running on embedded Linux startup

Embedded system Linux boot configuration file, different from the normal PC Linux boot configuration, start the relevant files and file content is much less. The Linux boot process under embedded systems is generally:1 in the bootloader to develop a variety of requirements to the Linux kernel parameters, the production of RAMDisk or Ramfs file system, and in the first mount after booting, the file system is mainly responsible for the boot run configuration file, embedded system is mainly/etc/ Inittab and/ETC/RC files;2 After the init process starts, the process first executes the/etc/inittab file, which is described below, and typically includes three items to start. One of the main content is: SYSINIT:/ETC/RC, the purpose is to establish the initialization of the script to execute the configuration file, in the/ETC/RC is mainly the configuration system, the other is:: Respawn:-/usr/sbin/xxx,xxx is generally the shell, The last important item is:: Shutdown:/bin/umount-a-RThe following sections are reproduced http://blog.csdn.net/kernel_32/archive/2009/02/03/3860756.aspx

First introduce the point background knowledge about Inittab:

The init process is the parent of all processes in the system, and the init process breeds the child processes required to complete the usual operations, including setting the machine name, inspecting and installing the disk and file system, starting the system log, configuring the network interface and starting the network and mail services, starting the print service, and so on. The primary task of the INIT process in Solaris is to create processes according to the information provided by the Inittab file, which is also known as the system initialization process because those processes that are initialized by the system are created by Init.
the format of the Inittab file is specified below.
Each record in the Inittab file begins with a new row, with a maximum of 512 characters per record entry, and the format of each entry is usually as follows: Id:rstate:action:process, as explained separately below.
a 1.id field is a string of up to 4 characters that is used to uniquely flag a table entry.
The 2.rstate (run State) field defines the RunLevel at which the record entry is invoked, Rstate can consist of one or more run levels, or it can be empty, and null represents the RunLevel 0~6. When the request init changes the runlevel, those processes that do not include the new runlevel in the Rstate field will receive a sigterm warning signal and be killed at the end; only commands that are started by a, B, C are not true RunLevel
The 3.action field tells Init what to do with the processes specified in the Process field, the values allowed for the action field, and the corresponding actions, respectively:
1) Respawn: If the process specified by the processes field does not exist, start the process, Init does not wait for processing to finish, but continue to scan the subsequent process in the Inittab file, and when such a process terminates, Init restarts it, if such a process already exists, Then do nothing.
2) Wait: Starts the process specified in the Processes field and waits until the processing is finished to process the next record entry in Inittab.
3) Once: Starts the process specified by the process field and processes the next record item without waiting for processing to finish. When such a process terminates, it is no longer restarted, and if such a process is still running when the new RunLevel is entered, Init does not restart it.
4) Boot: Only when the system starts, Init processes such record entries, initiates the process, and does not wait for the processing to finish to process the next record entry. When such a process terminates, the system does not restart it.
5) Bootwait: After the system starts, when the first time from single user mode into multi-user mode to process such a record entry, Init initiates such a process, and waits for its processing to end, and then the next record item processing, when such a process terminates, the system does not restart it.
6) Powerfail: Processes the specified process when Init receives a signal to power off (SIGPWR).
7) Powerwait: When Init receives a signal to power off (SIGPWR), processes the specified process and waits until the processing is over to check for other record entries.
8) off: If the specified process is running, Init sends it a SIGTERM warning signal, waits 5 seconds before signaling it sigkill forcing it to end, and ignores this if no such process exists.
9) OnDemand: Functional respawn, different from the specific run level, only for rstate fields are those record entries for a, B, C.
Sysinit: The specified process is executed before the access console, such that the record entry is only used for initialization of certain devices in order for Init to ask the user questions about the runlevel on such a device, and Init needs to wait until the process has finished running before continuing.
Initdefault: Specifies a default runlevel, which is scanned only when Init is first called, if the Rstate field specifies multiple RunLevel, where the largest number is the default run level, and if the Rstate field is empty, Init considers the field to be 0123456 and enters level 6 so that it falls into a loop, and if the Inittab file does not contain a record entry that contains Initdefault, ask the user to specify an initial runlevel for it when the system starts
a process in a 4.Process field can be any waiting process, executable script, or program.
also: At any time, you can add a new record entry in the file Inittab, the level q/q does not change the current runlevel, recheck the Inittab file, you can enable the Init process to reread and process the file immediately by command init Q or init q Inittab

These are the standard Linux System v standards introduced, so there are some things that are not useful for embedding! Here the introduction points for embedded, that is, for BusyBox init:

BusyBox's Init

In addition to the basic commands, BusyBox also supports the INIT function, like other init, the init of BusyBox is the initialization of the system, the work before shutdown, and so on, we know that after the Linux kernel is loaded, the machine transfers control to the kernel, After booting the Linux kernel, doing some work, then finding the init program inside the root filesystem and executing it, the BusyBox init process will do the following: (reference << build embedded Linux systems >> p201)

1. Set the signal processing process for Init

2. Initializing the console

3. Profiling/etc/inittab Files

4. Execute the System initialization command line, using/etc/init.d/rcs by default

5. Perform all inittab commands that cause init to pause (action type: Wait)

6. Perform all Inittab only once (action type: once)

Once the above work is done, the init process loops through the following processes:

1. Perform all Inittab commands that must be restarted upon termination (action type: once)

2. Inittab command (action type: Askfirst) that must be restarted at all termination, but before starting.

After initializing the console, BusyBox checks to see if the/etc/inittab file exists, and if the file does not exist, BusyBox uses the default Inittab configuration, which is primarily for system reboots, system hangs, and init restart settings for default actions. It also sets the action to start the shell for four virtual consoles (tty1 to Tty4). If these device files are not established, BusyBox will error.

The format of each line in the Inittab file is as follows: (BusyBox The example folder under the root directory has an exhaustive example of inittab files)

Id:runlevel:action:process

Although this format is similar to the traditional sytem V init, the ID has a different meaning in BusyBox's init. For BusyBox, the ID is used to specify the control TTY for the startup process. If the process being started is not an interactive shell, such as BusyBox sh (ASH), there should be a control TTY, and if the control TTY does not exist, the BusyBox SH will error. BusyBox will completely ignore the RunLevel field, so it's OK to empty it, and you might ask that since it's useless to keep it, I think it's probably for the same format as the traditional sytem V init. The process field is used to specify the path to the executing program, including command-line options. The action field is used to specify one of the 8 actions that can be applied to a process in the following table.

Action
Results
 
Sysinit
provide init command-line path for initialization
 
respawn
Restarts whenever the corresponding process terminates execution
 
Askfirst
similar to respawn, but its main purpose is to reduce the number of terminal applications executed on the system. It will cause Init to display the message "Press Enter to active this console" on the console and wait for the user to press the ENTER key before restarting
 
wait
tells Init to wait until the corresponding process is complete before continuing execution
 
once
executes the corresponding process only once, and does not wait for it to complete
 
Ctratldel
when the Ctrl+alt+delete key combination is pressed, the corresponding process is executed
 
shutdown
When the system shuts down, the corresponding process is executed
 
Restart
when Init restarts, the corresponding process is executed, usually the process executed here is the init itself
 

Here is the Inittab file for my usblinux

:: Sysinit:/etc/init.d/rcs

:: Respawn:/sbin/getty 115200 tty1

Tty2::askfirst:-/bin/sh

Tty3::askfirst:-/bin/sh

:: Restart:/sbin/init

:: Ctrlaltdel:/bin/umount-a-R

This inittab performs the following actions

1. Set the/ETC/INIT.D/RCS as the initialization file for the system

2. Start a login session on 115200 bps virtual Terminal tty1 (note the usage of Getty)

3. Start the Askfirst action shell on the virtual terminal tty2 and Tty3

4. If init restarts, set/sbin/init to the program it will execute

5. Tell Init to execute the umount command when the system shuts down to unmount all file systems, and flush the new installation with read-only mode to protect the file system if the uninstallation fails.

1, BusyBox Inittab and PC use of Inittab different, the first ID is not the name of the word, which should be the/dev/directory with the corresponding file corresponding

corresponding error

Can ' t open/dev/0: No such file or directory

Process '-/bin/sh ' (PID 789) exited. Scheduling for restart.

Can ' t open/dev/0: No such file or directory

Process '-/bin/sh ' (PID 793) exited. Scheduling for restart.

2. The following error occurred:

Process '-/bin/sh ' (PID 789) exited. Scheduling for restart.

Process '-/bin/sh ' (PID 794) exited. Scheduling for restart.

Process '-/bin/sh ' (PID 796) exited. Scheduling for restart.

Process '-/bin/sh ' (PID 798) exited. Scheduling for restart.

The corresponding Inittab file has the

Ttys0::askfirst:-/bin/sh

Although there are ttyS0 devices in the/dev/directory, this device is obviously not available, so the above error will occur

3, when the inittab in the same definition of two in the same serial terminal login statement

:: askfirst:-/bin/sh

S3c2410_serial0:23456:respawn:/sbin/getty-l s3c2410_serial0 115200 vt100

What happens is to be preempted and not be able to receive any serial input

4, Bad Inittab entry

Most of the time due to illegal characters.

5. Field Runleve in BusyBox also has no concept of run-time RunLevel

6, analysis of the START process

1. Set the signal processing process for Init

2. Initializing the console

3. Profiling/etc/inittab Files

4. Execute the System initialization command line, using/etc/init.d/rcs by default

5. Perform all inittab commands that cause init to pause (action type: Wait)

6. Perform all Inittab only once (action type: once)

Once the above work is done, the init process loops through the following processes:

1. Perform all Inittab commands that must be restarted upon termination (action type: once)

2. Inittab command (action type: Askfirst) that must be restarted at all termination, but before starting.

After initializing the console, BusyBox checks to see if the/etc/inittab file exists, and if the file does not exist, BusyBox uses the default Inittab configuration, which is primarily for system reboots, system hangs, and init restart settings for default actions. It also sets the action to start the shell for four virtual consoles (tty1 to Tty4). If these device files are not established, BusyBox will error.

7, online people asked the role of "-"

I was wondering:
:: respawn:-/bin/sh
This-is what, why sometimes there are sometimes not???
Also, I see a routine from the internet, such as the following excerpt:
:: respawn:-/bin/sh
Tty2::askfirst:-/bin/sh
I can't figure out the difference between the two, so that the console is started, is the first sentence to start or the second sentence, then my kernel boot parameters inside the CONSOLE=TTYS0 will automatically find this console???

Originally Posted by wavezone on 2008-8-22 16:34
I was wondering:
:: respawn:-/bin/sh
This-is what, why sometimes there are sometimes not???
Also, I see a routine from the internet, such as the following excerpt:
:: respawn:-/bin/sh
Tty2::askfirst:-/bin/sh
I can't figure out the difference between the two.

The test is this, and the "-" statement will be called after the landing Terminal/etc/directory of the profile file, without adding "-" will not execute the script.

In fact, landing terminal commands There are several convenient, but the standard or use Getty to log in, but the direct use of the above statement is also possible, and compatibility is strong, because it does not need to specify the corresponding serial device.

:: askfirst:-/bin/sh

S3c2410_serial0::askfirst:-/bin/sh

:: askfirst:-/bin/sh

S3c2410_serial0:23456:respawn:/sbin/getty-l s3c2410_serial0 115200 vt100

are available.

8./bin/sh:xxx not found
arm-linux-readelf-d xxx
See which libraries your program relies on
Generally because of the lack of libc.so.6 caused by the actual or root file system problems, do not copy the common library files to the/lib directory
Common libraries:

[Email protected] lib]cp/usr/local/arm/3.4.1/arm-linux/lib/ld*.

[Email protected] lib]cp/usr/local/arm/3.4.1/arm-linux/lib/libc-2.3.2.so.

[Email protected] lib]cp/usr/local/arm/3.4.1/arm-linux/lib/libc.so.6.

[Email protected] LIB]CP/USR/LOCAL/ARM/3.4.1/ARM-LINUX/LIB/LIBM *.

[Email protected] lib]cp/usr/local/arm/3.4.1/arm-linux/lib/libcrypt*.

9. Error Insmod:chdir (2.6.26.6): No such file or directory

Someone on the internet has proposed this workaround:

It is important to note that module load commands such as insmod need to be from lib/modules/2.6.26.6

Directory, you must first establish this directory and then place the module under this directory, otherwise the following two scenarios will occur:

One is not established lib/modules/2.6.26.6 directory, depending on the kernel version number, will appear Insmod:chdir (2.6.26.6): No such file or directory error

The second is to simply place the module in the root directory or other folder, do not copy it to the specified lib/modules/2.6.26.6 directory, will appear

Insmod:module ' gpio_driver ' not found error

But it didn't work out that way.

The root cause is the insmod problem, refer to the following option when compiling BusyBox, do not use

Linux Module Utilities--->

[] Simplified Modutils

This option does not select

[*] Support version 2.6.x Linux kernels

This option is selected on the

Refer to the following:

10. Cannot execute "-H" command

There is no response when executing xxx–h. Is missing common library files in the Lib directory

Refer to the following:

[[email protected] rootfs]# ls lib/

ld-2.3.6.so libc-2.3.6.so libgcc_s.so libnsl.so.1 libnss_files.so.2 Libnss_nis. So.2 librt-2.3.6.so libthread_db.so.1

Ld-linux.so.2 libcrypt-2.3.6.so libgcc_s.so.1 libnss_compat-2.3.6.so libnss_hesiod-2.3.6.so libpcprofil e.so librt.so.1 libutil-2.3.6.so

libanl-2.3.6.so libcrypt.so.1 libm-2.3.6.so libnss_compat.so.2 libnss_hesiod.so.2 libpthread- 0.10.so libsegfault.so libutil.so.1

Libanl.so.1 libc.so.6 libmemusage.so libnss_dns-2.3.6.so libnss_nis-2.3.6.so libpthread. so.0 libtermcap.so.2 Modules

libbrokenlocale-2.3.6.so libdl-2.3.6.so libm.so.6 libnss_dns.so.2 libnss_nisplus-2.3.6.so libresolv-2.3.6.s o libtermcap.so.2.0.8

Libbrokenlocale.so.1 libdl.so.2 libnsl-2.3.6.so libnss_files-2.3.6.so libnss_nisplus.so.2 Libresolv.s O.2 libthread_db-1.0.so

Go: Inittab files running on embedded Linux startup