Yocto System Startup (design, implementation & ...

=========================== Problems with yocto initscripts ===========================

1. Some initscrits does not regard the possibility of a read-only rootfs.
   Some boot scripts write to rootfs without checking whether it's writable or not. Besides, when using mount command, sometimes we should supply -n option to it if /etc/mtab is not writable. The rootfs may be read-only, or /etc/mtab is a symlink to /proc/mounts.

2. Concurrency problem: no method has been added to support concurrent execution of initscripts. See insserv for more information.
Initscripts in yocto has a very old version, it is written in 1999. The current version of initscripts has internal support for concurrency.

3. The root file system is mounted as rw by kernel by default. However, if a read-only rootfs is to be used. It should be mounted as read-only first.

4. There's '/dev/root' in fstab, however, /dev/root is not present in our system.
On my desktop, /dev/root is present.
chenqi@chenqi-laptop /lib/init $ ls -l /dev/root
lrwxrwxrwx 1 root root 4 12月 15 12:28 /dev/root -> sda8
Does it have any potential problems?

5. It does not regard the kernel command line parameters.

6. Every init script should have the correct head info. We may use insserv in the future, although it is not built by default for now.

7. Boot scripts in yocto don't take the consistent format. Some have do_start(), do_stop() in them, others don't. In particular, the 'rc' program invokes these boot scripts in different ways according to their suffixes. See the code snippet below.
startup() {
  # Handle verbosity                                         
  [ "$VERBOSE" = very ] && echo "INIT: Running $@..."

  case "$1" in
        *.sh)
                 # Source shell script for speed.                                                                             
                (
                        trap - INT QUIT TSTP
                        scriptname=$1
                        shift
                        . $scriptname
                )
                ;;
        *)
                "$@"
                ;;
  esac
  startup_progress
}
This is so inappropriate. In newer version of these sysvinit scripts, this problem has been fixed. So I think we should fix it too.
We may need a directory, e.g., /lib/init/ to keep all wrapper functions, hook functions and aux functions. We should not put these functions under /init.d because in essence, they are not init scripts or daemons, they only provide some functionalities that those initscripts may need.

For what's its worth, here's some guidelines about sysv style boot scritps stated in boot(7).
For each managed service (mail, nfs server, cron, etc.) there is a single startup script located in a specific directory (/etc/init.d in most versions of Linux). Each of these scripts accepts as a single argument the word "start" -- causing it to start the service, or the word "stop" -- causing it to stop the service. The script may optionally accept other "convenience" parameters (e.g: "restart", to stop and then start, "status" do display the service status). Running the script without parameters displays the possible arguments.

8. checkroot.sh in our system doesn't check root file system at all in any circumstances. This is because we don't have fsck.ext3. I think, as an alternative, we should use e2fsck instead.
However, it seems that yocto doesn't have e2fsck with it.
[fsck is a wrapper for the filesystem-specific fsck.* family of tools.]
[fsck is just the original name. When they came out with new file systems they would need a specific tool for each one, efsck for ext, e2fsck for ext2, dosfsck, fsckvfat. So they made fsck the front end that just calls whichever is the appropriate tool.]


Note: the above problems are discovered in comparison with the initscripts in Linux Mint.


============================= Background Knowledges ============================================
Q & A
------
1. kernel command line? /proc/cmd? What's that for?
https://www.kernel.org/doc/Documentation/kernel-parameters.txt
bootparam(7)
e.g.
initrd=        [BOOT] Specify the location of the initial ramdisk
ro        [KNL] Mount root device read-only on boot
root=        [KNL] Root filesystem
rootflags=    [KNL] Set root filesystem mount option string
rootfstype=    [KNL] Set root filesystem type
rw        [KNL] Mount root device read-write on boot
selinux=    [SELINUX] Disable or enable SELinux at boot time.

2. What's the usage of /etc/mtab and /etc/fstab, respectively?
http://www.brunolinux.com/02-The_Terminal/Fstab_and_Mtab.html
/etc/fstab: static information about file systems
/etc/mtab: information about the currently mounted filesystems, updated automatically by mount

3. What is 'selinux'?
SELinux, Security Enhanced Linux, is a Linux feature that provides the mechanism of supporting access control security policy. It is not a Linux distribution, but rather a set of kernel modications and user space tools that can be added to various Linux distributions.

4. Is /etc/hostname present in our system?
Yes. It is created by base-files recipe.

5. Which OS loader does yocto use? lilo or grub?

6. How to pass parameter to kernel to make it override the default root file system?

7. What is swapper (kswapd in linux kernel)?
It is the startup function for the kernel. It establishes memory management, detects the type of CPU, and then switches to non-architecture specific Linux kernel functionality via a call to start_kernel().

8. What's the difference between initrd style boot and initramfs style boot?


Basics
------
1. General description of boot sequence
boot(7)
http://en.wikipedia.org/wiki/Linux_startup_process
i) hardware boot
ii) OS loader
iii) kernel startup
iv) init and inittab
v) bootscripts

==> Power-on or hard reset
==> BIOS (stored on read-only memory)
    -- perform a basic self test
    -- read parameters on non-volatile memory (on PC, it's usually CMOS)
    -- determine boot device based on the parameters read
    -- access the boot device, load the OS loader, which usually locates at MBR
==> OS loader loads a secondary OS loader (lilo or grub for linux)
    -- the secondary OS loader locates the kernel on disk
    -- load kernel, pass optional parameter to it, and run it
==> Kernel startup
    -- initialize the devices
    -- starts the swapper (kswapd for modern linux kernel)
    -- mount root file system (/)
    -- create the first user land process, which executes /sbin/init
==> init reads /etc/inittab for further instructions
==> according to the runlevel, some particular boot scripts are executed

A description form wiki:
"
The startup function for the kernel (also called the swapper or process 0) establishes memory management (paging tables and memory paging), detects the type of CPU and any additional functionality such as floating point capabilities, and then switches to non-architecture specific Linux kernel functionality via a call to start_kernel().

start_kernel executes a wide range of initialization functions. It sets up interrupt handling (IRQs), further configures memory, starts the Init process (the first user-space process), and then starts the idle task via cpu_idle(). Notably, the kernel startup process also mounts the initial RAM disk ("initrd") that was loaded previously as the temporary root file system during the boot phase. This allows driver modules to be loaded without reliance upon other physical devices and drivers,[clarification needed] and keeps the kernel smaller. The root file system is later switched via a call to pivot_root() which unmounts the temporary root file system and replaces it with the use of the real one, once the latter is accessible. The memory used by the temporary root file system is then reclaimed.

Thus, the kernel initializes devices, mounts the root filesystem specified by the boot loader as read only, and runs Init (/sbin/init) which is designated as the first process run by the system (PID = 1).[2] A message is printed by the kernel upon mounting the file system, and by Init upon starting the Init process. It may also optionally run Initrd[clarification needed] to allow setup and device related matters (RAM disk or similar) to be handled before the root file system is mounted.[2]
"

"
"When the kernel is loaded, it immediately initializes and configures the computer's memory and configures the various hardware attached to the system, including all processors, I/O subsystems, and storage devices. It then looks for the compressed initrd image in a predetermined location in memory, decompresses it, mounts it, and loads all necessary drivers. Next, it initializes virtual devices related to the file system, such as LVM or software RAID before unmounting the initrd disk image and freeing up all the memory the disk image once occupied. The kernel then creates a root device,[clarification needed] mounts the root partition read-only, and frees any unused memory. At this point, the kernel is loaded into memory and operational. However, since there are no user applications that allow meaningful input to the system, not much can be done with it." An initramfs-style boot is similar, but not identical to the described initrd boot.
"

2. Introduction to boot time parameters of Linux Kernel
bootparam(7)
grub(1)
parameters:
-> picked up by kernel, e.g., root=xxx, init=xxx
-> interpreted as environment variable, e.g., TERM=vt100
-> passed onto process one, e.g., single to indicate booting into single user mode
The 'rw' option tells the kernel to mount the root file system read/write.  This is the default.

3. Unionfs
Unionfs is a filesystem service which implements a union mount for other filesystems.


============================= Ideas ===========================================================
1. Some variables in /etc/default/rcS have to be set some particular value if rootfs is read-only.
   For example, ENABLE_VOLATILE_CACHE should be set to 'no' in situation of a read-only rootfs.
   We can create a wrapper script (basic_var.sh) which wraps the '. /etc/default/rcS' command.
   Instead of using '. /etc/default/rcS' at the start of some init scripts, we can use '. /path/to/basic_var.sh'. This gives us a chance to change the default setting of basic variables, thus regarding the possibility of read-only rootfs.
   
2. When a flaw is found in initscripts, fix it. Improve it step by step. Don't mix things up.
   Git is a powerful version control tool, we can reorganize the commits later.
   
3. This is an idea borrowed from the newer version of initscripts. We may need a directory, e.g., /lib/init/ to keep all wrapper functions, hook functions and aux functions. We should not put these functions under /init.d because in essence, they are not init scripts or daemons, they only provide some functionalities that those initscripts may need.

=========================== Read-only rootfs support ====================================
1. The concept of live-cd and live-usb.
2. The concept of unionfs.