Ceci est une ancienne révision du document !
As a follow up to a question I had, I’d like to take this opportunity to explain the Linux boot process for n00bs, as the comments that flew around were highly inaccurate. What happens when I press the power button? Usually this is where your BIOS or UEFI will spring into action and get things ready for you. This is just code / software that gets things like your keyboard and screen and storage ready for action. It used to be called POST (Power On Self Test). POST polls your hardware and makes sure they respond, before basically turning them on. (This is not 100% accurate, but it allows you to grasp it easily and imagine it for yourself as this is a high-level overview.) If there is an error, you will usually get an error on the screen or a BIOS beep code (you can look these up online for your specific BIOS). If everything checks out, the BIOS/UEFI will go and find your storage and look for the bootloader software (more on this later). You can control where it looks and the order thereof in your BIOS/UEFI settings (usually something named “boot order”). Now here is where BIOS and UEFI are not alike. BIOS will look for a Master boot record (MBR), and UEFI will look for a UEFI partition. This is the .efi bootloader file – that you will see people talk about if you dig into the UEFI boot process.
So what does a bootloader do?: • Firstly, it will look for your kernel. Once it finds your kernel, it will load it into memory. • Secondly, it will execute the kernel code. That is, it will start running your kernel. Grub bootloader is what we all know and love, but you may find Lilo bootloader on older or more esoteric distributions. Grub is actually amazing, allowing you to boot multiple operating systems and sporting a large array of features that most users do not even use. You will know you are a Linux power user if you use the Grub2 advanced features!
Let’s look at it in a Linux light. Once Grub2 (your bootloader) finishes finding and loading your kernel into memory, it hands over control to said kernel. The kernel now takes over the start-up process, and starts doing the booting you will see on your screen, if you do not have something like Plymouth installed. With modern hardware, that scrolling list is usually scrolling by too fast to read anyway! What is happening here, is the kernel is initiating all the services and processes needed. The process is as follows: the kernel decompresses (we had a news article about this some time ago about the compression algorithm), or expands itself into memory. The kernel includes a decompressor stub that handles unpacking the kernel itself once it is loaded, and it includes full decompression support for initramfs. The kernel now checks the available hardware and loads device drivers for said hardware as well as other necessary kernel modules. The initial process that starts, is the init process (get it?). As Ubuntu users, we all know it as Systemd. In older distributions it was SysV or Upstart, and there are others out there too. Since this is the first process that runs, it is the parent process of all other processes that run in your computer. Love it or hate it, Systemd is what you have in your Ubuntu OS. Systemd will now take over and get your system ready to use. When you run something like systemd-analyze blame, it will show you all the services it ran and the time it took to do so. Systemd can also find and run additional drivers not run by the kernel for any additional hardware.
Systemd uses target configuration files to choose the mode that it will be booting into. Like, for instance, the graphical user mode we are used to. Think of these as the old init scripts or runlevels, if you have had any experience with older distributions (I used to get paid to go out to a client and type init 6 on the command line… XD). Systemd now handles all the background processes for you, abstracting a lot away from the user. That is more-or-less the overview of the way your Ubuntu machine boots. Helpful tools include dmesg – on Ubuntu you need to type: sudo dmesg to see the output. Remember to pipe it to a pager like less.
In dmesg, you can see what happened, at what time during the boot process. Did things go right, did things go wrong? Modern distributions will have dmesg color-coded, but many do not, and you will need to pay close attention to the output of those. Hope this helps any n00bs who wish to picture the boot process for themselves. Please send any comments or concerns to misc@fullcirclemagazine.org