6 Stages of Linux Boot Process (Startup Sequence)

http://www.thegeekstuff.com/2011/02/linux-boot-process/

 

Press the power button on your system, and after few moments you see the Linux login prompt.

Have you ever wondered what happens behind the scenes from the time you press the power button until the Linux login prompt appears?

The following are the 6 high level stages of a typical Linux boot process.

1. BIOS

  • BIOS stands for Basic Input/Output System
  • Performs some system integrity checks
  • Searches, loads, and executes the boot loader program.
  • It looks for boot loader in floppy, cd-rom, or hard drive. You can press a key (typically F12 of F2, but it depends on your system) during the BIOS startup to change the boot sequence.
  • Once the boot loader program is detected and loaded into the memory, BIOS gives the control to it.
  • So, in simple terms BIOS loads and executes the MBR boot loader.

2. MBR

  • MBR stands for Master Boot Record.
  • It is located in the 1st sector of the bootable disk. Typically /dev/hda, or /dev/sda
  • MBR is less than 512 bytes in size. This has three components 1) primary boot loader info in 1st 446 bytes 2) partition table info in next 64 bytes 3) mbr validation check in last 2 bytes.
  • It contains information about GRUB (or LILO in old systems).
  • So, in simple terms MBR loads and executes the GRUB boot loader.

3. GRUB

  • GRUB stands for Grand Unified Bootloader.
  • If you have multiple kernel images installed on your system, you can choose which one to be executed.
  • GRUB displays a splash screen, waits for few seconds, if you don’t enter anything, it loads the default kernel image as specified in the grub configuration file.
  • GRUB has the knowledge of the filesystem (the older Linux loader LILO didn’t understand filesystem).
  • Grub configuration file is /boot/grub/grub.conf (/etc/grub.conf is a link to this). The following is sample grub.conf of CentOS.
    #boot=/dev/sda
    default=0
    timeout=5
    splashimage=(hd0,0)/boot/grub/splash.xpm.gz
    hiddenmenu
    title CentOS (2.6.18-194.el5PAE)
              root (hd0,0)
              kernel /boot/vmlinuz-2.6.18-194.el5PAE ro root=LABEL=/
              initrd /boot/initrd-2.6.18-194.el5PAE.img
  • As you notice from the above info, it contains kernel and initrd image.
  • So, in simple terms GRUB just loads and executes Kernel and initrd images.

4. Kernel

  • Mounts the root file system as specified in the “root=” in grub.conf
  • Kernel executes the /sbin/init program
  • Since init was the 1st program to be executed by Linux Kernel, it has the process id (PID) of 1. Do a ‘ps -ef | grep init’ and check the pid.
  • initrd stands for Initial RAM Disk.
  • initrd is used by kernel as temporary root file system until kernel is booted and the real root file system is mounted. It also contains necessary drivers compiled inside, which helps it to access the hard drive partitions, and other hardware.

5. Init

  • Looks at the /etc/inittab file to decide the Linux run level.
  • Following are the available run levels
    • 0 – halt
    • 1 – Single user mode
    • 2 – Multiuser, without NFS
    • 3 – Full multiuser mode
    • 4 – unused
    • 5 – X11
    • 6 – reboot
  • Init identifies the default initlevel from /etc/inittab and uses that to load all appropriate program.
  • Execute ‘grep initdefault /etc/inittab’ on your system to identify the default run level
  • If you want to get into trouble, you can set the default run level to 0 or 6. Since you know what 0 and 6 means, probably you might not do that.
  • Typically you would set the default run level to either 3 or 5.

6. Runlevel programs

  • When the Linux system is booting up, you might see various services getting started. For example, it might say “starting sendmail …. OK”. Those are the runlevel programs, executed from the run level directory as defined by your run level.
  • Depending on your default init level setting, the system will execute the programs from one of the following directories.
    • Run level 0 – /etc/rc.d/rc0.d/
    • Run level 1 – /etc/rc.d/rc1.d/
    • Run level 2 – /etc/rc.d/rc2.d/
    • Run level 3 – /etc/rc.d/rc3.d/
    • Run level 4 – /etc/rc.d/rc4.d/
    • Run level 5 – /etc/rc.d/rc5.d/
    • Run level 6 – /etc/rc.d/rc6.d/
  • Please note that there are also symbolic links available for these directory under /etc directly. So, /etc/rc0.d is linked to /etc/rc.d/rc0.d.
  • Under the /etc/rc.d/rc*.d/ direcotiries, you would see programs that start with S and K.
  • Programs starts with S are used during startup. S for startup.
  • Programs starts with K are used during shutdown. K for kill.
  • There are numbers right next to S and K in the program names. Those are the sequence number in which the programs should be started or killed.
  • For example, S12syslog is to start the syslog deamon, which has the sequence number of 12. S80sendmail is to start the sendmail daemon, which has the sequence number of 80. So, syslog program will be started before sendmail.

There you have it. That is what happens during the Linux boot process.

### Amlogic ENV Configuration and Usage In embedded systems utilizing the Amlogic platform, particularly focusing on environments like Android or custom-built images using frameworks such as Yocto/OpenEmbedded, configuring and managing environment variables (ENV) plays a crucial role in system customization and functionality tuning[^1]. For platforms based on Amlogic chips, including models like G12A U202 V1, specific configurations are required to properly set up these environment variables within different layers of software stack. #### Understanding Environment Variables in Boot Process Environment variables control various aspects during booting processes from bootloader stages through kernel initialization into user space operations. In case of devices powered by Amlogic SoCs, modifications can be made at multiple points: - **U-Boot Stage**: This is where initial settings reside before handing over execution flow to Linux Kernel. Files under `uboot-repo` directory contain definitions related specifically to hardware variants supported by respective chipsets [^2]. ```c // Example snippet showing how some parameters might look inside uboot configuration file. #define CONFIG_ENV_SIZE 0x2000 /* Size of environment */ #define CONFIG_SYS_MONITOR_LEN (512 << 10) ``` #### Configuring Environment Variables via U-boot To modify existing entries or add new ones relevant for particular use cases, developers typically edit corresponding header files found within Uboot source tree structure. Changes here affect low-level behaviors impacting performance characteristics among other things depending upon what exactly gets altered. For instance, altering memory layout options could influence speed; changing network interface properties would impact connectivity features etcetera. After editing necessary sections according to project requirements, rebuilding U-Boot with updated sources ensures that changes take effect post-deployment. #### Utilizing Environment Variables Within Android System Layers Once past early boot phases controlled primarily outside OS boundaries, subsequent access patterns shift towards higher abstraction levels provided internally once fully operational state reached. Applications running atop may query current values stored persistently across reboots without needing direct interaction with firmware components directly involved earlier steps mentioned above. Within an Android context built around Amlogic Socs, obtaining all available environment variables involves querying mechanisms exposed either programmatically through APIs offered natively or indirectly leveraging shell commands executed against runtime environment established after full startup sequence completes successfully. ```bash # Command line approach to list env vars accessible within adb shell session adb shell 'set | grep -v "^$"' # Alternatively, Java code sample demonstrating retrieval method within app scope Process process = Runtime.getRuntime().exec("getprop"); BufferedReader reader = new BufferedReader(new InputStreamReader(process.getInputStream())); String line; while ((line = reader.readLine()) != null) { Log.d("SystemProperty", line); } ``` --related questions-- 1. How does modifying U-Boot environment variables impact device behavior? 2. What tools are recommended for debugging issues arising from incorrect ENV setups? 3. Can environment variable adjustments improve power efficiency in Amlogic-based devices? 4. Are there security implications associated with exposing certain types of ENV data?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值