This is a good summary, but it seems like there's a lot going on behind the scenes in all of these process, especially systemD. Would be nice to cover that in a future video :)
systemD is a disgrace and as UNIX-like as it gets. Its functioning should never be covered nor should its name even be uttered more than strictly necessary
Yeah, pretty much "what does Kernel at boot" and "what does process with pid=1 at boot before enters configured runlevel" should have been content of the video, not detecting devices, running EFI, and rest of irrelevant shit.
People clicking on a sub 5 minute video and expecting an intricate explanation of all functions of the boot loader. This was a great high level overview..
All I know about ACPI is that it got FUBARd in my laptop and now the lspci doesn't even show my wireless lan card. Don't know what started it, but I guess it was some power cycling malfunction because it started after I woke the PC up from sleep. I've done fresh linux install and it doesn't work. So most likely will need to flash BIOS :(
As has already been said, there is a lot going on in each of these steps. My major criticism is that step 5 simplifies away the usual mechanism of running some code from an initial ramdisk: this is done so that the kernel does not have to contain all the device drivers needed to load whatever modules it needs before the final root partition becomes readable. That also means that an earlier step needed to load the initial ram disk into memory and tell the kernel where to find it. Grub (or some other boot program like Lilo) will have done this already, so the Grub step should mention that it loads a filesystem containing drivers as well as libraries into ram before passing control to the kernel. And then, in my opinion, you need an extra step between 4 and 5 for the initial ram stage, that is used to get the system able to actually read the code it needs off the disks. While it does that the kernel only needs to know how to read the initial ramdisk. More detail follows... There are two exceptions to what i just said 1. If you compile your own kernel you can arrange that the kernel has all the drivers it needs built in (Gentoo users might do this, knowing in advance exactly what filesystem and hardware will hold the operating system) 2. Puppy (and most Live Disk systems) boot into the ramdisk and never leave it. For different reasons, both these exceptions slow down system loading (because either the kernel or the ramdisk is huge) but often speeds up running once the boot is complete because the kernel has what it needs in memory at all times, one way or another.
There's a bit of a misconception about BIOS. MBR is limited to 2TB, but a BIOS doesn't need to be restricted to MBR, it could've moved to a different (likely proprietary) format... it's just that GPT and EFI were more flexible and the groundwork was already completed
it can use any partition format not just MBR. But the boot code need to reside in first 2TB because it will use BIOS provided disk services to access which only support 32bit LBA addressing. To be able to access disk beyond 2TB, the boot code need to probe and load appropriate disk drivers to be able to access disk controller directly so it can use 48bit LBA, for example GRUB that when in stage 2 it can communicate directly with ATA controllers to boot kernel beyond 2TB (if you know how to).
When Linux chooses to support initramfs boot, and selects the rootfs path to be packaged in the initramfs source file, it will try to boot in initramfs mode. In this way, the rootfs will be compressed and packaged in the same image file as the Linux kernel. Then uboot will load the whole image file into memory when the system is loaded. In this way, the rootfs cannot be modified in flash, and will be lost when the power is lost.
I was expecting that you would really be talking about the kernal boot process and not everything around. But in the end, I never saw an exhaustive explanation about the boot process in the first place so I am that to know that I did not miss out anything.
I think no matter the type of bios, the bios is written in the EEPROM located in the motherboard. It is not attached to any disk. So even if the boot failure or no OS is installed you can still access bios.
It is possible to use gpt partitions without needing UEFI. Even old motherboards with intel 775 socket will boot using gpt partitions without UEFI: "Yes, it is possible to use GPT (GUID Partition Table) partitions without UEFI (Unified Extensible Firmware Interface). GPT is a partitioning scheme for formatting and partitioning hard drives, and it's independent of the firmware interface being used (UEFI or BIOS). However, the ability to boot from a GPT-partitioned disk depends on the firmware of your system. Most modern systems use UEFI firmware to boot, and UEFI is compatible with both GPT and the older MBR (Master Boot Record) partitioning scheme. If your system uses the older BIOS (Basic Input/Output System) firmware instead of UEFI, it may have limitations when it comes to booting from GPT disks. Some BIOS systems can boot from GPT disks using a compatibility support module (CSM), while others may not support GPT booting at all. So, in summary, while you can use GPT partitions without UEFI, the ability to boot from a GPT disk depends on the firmware capabilities of your system."
Nice and simple ! But you're missing the loading of initrd. I admit I can't remember from the top of my head when exactly it occurs. Would be a nice addition to your explanation.
In the classic Grub or Lilo bootloader, the initrd or initram (NB they are different!) is loaded after the kernel but before control is passed. There are also the kernel parameters (append details in some boot loaders) that the boot loader has to make available to the kernel. These can be flags or switches to the kernel, to systemd, or to other programs run later on.
Excellent overhead view of the boot process. Of course most of us will have criticisms of what is presented here but if one is trying to keep it simple of course it will be grossly oversimplified.
I sept yesterday learning all this by myself and today, youtube recommended me this. If I had found this video, maybe I would have learned all that in 5 minutes.
Very nicely explained and beautifully visualized presentation. I have to ask tho, would you like to make that same presentation again but for a Secured and TPM measured bootgraph ? If so, please do it, people and especially the linux community would need this in order to understand why the TPM makes booting so much more secure. I would even offer my help understanding a measured boot process (which I am pretty sure you would have no trouble understanding on your own).
very very nice. excellent animation. forcing us to view compulsorily immediately though we have plenty of pending works. it is like movie attracts us. go ahead.
Great job! It looks clean, straightforward, and easy to understand. Could you tell me what software you used to create this video? I'm interested in making my own technical videos in the same manner.
Same, i wonder what the name of the first process that runs within the kernel is. Is there some sort of entry point within the kernel like a main function or something that eventually calls systemd?
Hi, thanks for video, good visualization. It will be interesting to see video about network adapter driver work in details, with interruptions and memory usage, kernel and so on.
In the early days of Linux, IDE hard drive support had to be manually compiled into the kernel. Kernel modules are loaded from a drive, but without drive support, the kernel could not load modules from a device it could not read. So, IDE support had to be compiled into the kernel, then once the kernel could use the drive, it could load other modules. This was a huge big deal, because compiling a kernel with a 386SX processor and 4 mb of ram would take days.
Although a thing to point out is that you don't need a boot loader now, you can just expose the kernel to UEFI and write flags directly into boot record.
Can you please post a link to a "how to" on skipping the "grub" phase of booting? And if you do that do you have to avoid using an initial ramdisk in the usual Linux way? I can't see how the boot flags alone can properly load the ramdisk (which might of course be my ignorance, hence my question)
initrd used to be a ext2/ext3 partition that can be mounted as loop device, now it's just a compressed a cpio archive, usually distro kernel is light and doesn't have network/disk/fs drivers so when the kernel is pushed to memory by grub it can't recognize hw and even mount fs. All needed drivers are stored in initrd image. More over linux thin clients mount root via nfs or nbd and again drivers and glue shell code is stored in initrd. And so called second stage is a chain load when a real hd init process is started and a root pivot is happening.
Today I read chapter 5 on How Linux Works by press starch. You took about 30 pages and summarized them in 4:43 minutes, except the book of course went in more detail at each step. Plus it had all the different boot loaders listed, even ones that are dead and gone. Do you have a System D VS Wayland video yet?
Systemd and wayland do different things. Systemd is simply the first program that the Linux kernel executes. When it starts, it reads a bunch of configuration files to figure out which other programs need to be run for the system to function, such as a network firewall or database like Mysql/Postgres. It also boots a program responsible for showing you the login screen. It's this login program (formally, a display manager) that figures out how to boot your desktop environment, which may use the Wayland protocol (it is not a program) or X11 protocol to communicate with the Wayland server or the X11 server, respectively. The Wayland and X11 servers are also simply programs that do the job of interfacing with the linux kernel (and by extension the hardware) to allow clients (i.e., your window manager like Gnome or your browser like Firefox) to be able to draw to the screen in a hardware-independent way (i.e., not worrying about whether you're running AMD/Nvidia/Intel graphics). All that's necessary to run a graphical program is for it to speak the Wayland protocol to a running Wayland server process. It just so happens that Systemd is responsible for starting the X11 and Wayland servers, because the init system is the most natural way to manage long-running processes upon which many other processes depend.
Not all, I do not use one for instance. But by default it is indeed used widely. Neither is boot loader mandatory, UEFI can load properly configured kernel directly (if you do not need all the extra flexibility of boot loader)
Gracias , no entiendo mucho de computación , pero me pareció genial , la explicación animada, entiendo que debe ser un experto en ciencias de la computacion
This seems more like a brief description of how *any* OS boots on a PC, just using the linux names for the later steps where it'll differ. Up to the boot loader step, there's not even an OS involved. And Windows uses a boot loader as well, it's just not called that and tends to be hidden from view for most people. Still, the same process. Code the hardwired system can find that loads the actual operating system. And whatever OS it is, the first step will usually be getting the kernel of the system going, drivers, etc. Same basic flow for any OS. Aside from the names used in those last steps, nothing here specific to linux. An actual OS specific discussion of the boot process would start with the kernel loading. It's from that point that OS's diverge. The boot loader itself can be setup to point to different kernels and/or different OSs itself, which is how a dual boot works.
Thank you for the information, as a follow-up will be great to take a step back and have instructions on how to identify if our system (desktop, laptop, mini PC, or server) supports UEFI for a faster boot, better functionality, and security. Thank you again!
Prior to boot loader what is the software that controls all these? Also how does a boot loader identify all the available kernals? like how does it know? is there already a software that reads this?
This is a good summary, but it seems like there's a lot going on behind the scenes in all of these process, especially systemD. Would be nice to cover that in a future video :)
That would require a 1000 page book,...may be 10000 pages!
systemD is a disgrace and as UNIX-like as it gets.
Its functioning should never be covered nor should its name even be uttered more than strictly necessary
@@nid274hey bro in which domain you are studying right now?
@@nid274try reading Abraham Silberschatz OS concepts book
Yeah, pretty much "what does Kernel at boot" and "what does process with pid=1 at boot before enters configured runlevel" should have been content of the video, not detecting devices, running EFI, and rest of irrelevant shit.
People clicking on a sub 5 minute video and expecting an intricate explanation of all functions of the boot loader. This was a great high level overview..
💯
still looking i guess XD
Wrong. The first two minutes had nothing to do with linux. It's even worse than expected.
Very common with Linux users. “I know this 1% about the os, and it wasn’t covered in video, so video not good.”
@@benbosco7904 nonsense. Video doesn't deliver what it promises, regardless of length. It is a clickbait title.
Good overview, but missing a discussion of ACPI, initramfs/initrd.
agreed, initramfs is a crucial part to be included in a boot process video IMHO
@@thecataclysmexactly, especially that the title mentions Linux specifically
All I know about ACPI is that it got FUBARd in my laptop and now the lspci doesn't even show my wireless lan card. Don't know what started it, but I guess it was some power cycling malfunction because it started after I woke the PC up from sleep. I've done fresh linux install and it doesn't work. So most likely will need to flash BIOS :(
As has already been said, there is a lot going on in each of these steps.
My major criticism is that step 5 simplifies away the usual mechanism of running some code from an initial ramdisk: this is done so that the kernel does not have to contain all the device drivers needed to load whatever modules it needs before the final root partition becomes readable.
That also means that an earlier step needed to load the initial ram disk into memory and tell the kernel where to find it. Grub (or some other boot program like Lilo) will have done this already, so the Grub step should mention that it loads a filesystem containing drivers as well as libraries into ram before passing control to the kernel.
And then, in my opinion, you need an extra step between 4 and 5 for the initial ram stage, that is used to get the system able to actually read the code it needs off the disks. While it does that the kernel only needs to know how to read the initial ramdisk.
More detail follows...
There are two exceptions to what i just said
1. If you compile your own kernel you can arrange that the kernel has all the drivers it needs built in (Gentoo users might do this, knowing in advance exactly what filesystem and hardware will hold the operating system)
2. Puppy (and most Live Disk systems) boot into the ramdisk and never leave it.
For different reasons, both these exceptions slow down system loading (because either the kernel or the ramdisk is huge) but often speeds up running once the boot is complete because the kernel has what it needs in memory at all times, one way or another.
Bravo si multumesc.E simplu,frumos pe intelesul tuturor...fara explicatii savante.CHIAR UN TUTORIAL...GENIAL DE SIMPLU!!!La mai multe inainte !!!
There's a bit of a misconception about BIOS. MBR is limited to 2TB, but a BIOS doesn't need to be restricted to MBR, it could've moved to a different (likely proprietary) format... it's just that GPT and EFI were more flexible and the groundwork was already completed
it can use any partition format not just MBR. But the boot code need to reside in first 2TB because it will use BIOS provided disk services to access which only support 32bit LBA addressing.
To be able to access disk beyond 2TB, the boot code need to probe and load appropriate disk drivers to be able to access disk controller directly so it can use 48bit LBA, for example GRUB that when in stage 2 it can communicate directly with ATA controllers to boot kernel beyond 2TB (if you know how to).
When Linux chooses to support initramfs boot, and selects the rootfs path to be packaged in the initramfs source file, it will try to boot in initramfs mode. In this way, the rootfs will be compressed and packaged in the same image file as the Linux kernel. Then uboot will load the whole image file into memory when the system is loaded. In this way, the rootfs cannot be modified in flash, and will be lost when the power is lost.
Thanks this is really informative
@@jali-cj5zq
Thanks for reading my comments!! I hope everyone’s got vim on their resolutions for 2024
One of the best boot process summary's on UA-cam. Thanks for all the work and graphics.
I was expecting that you would really be talking about the kernal boot process and not everything around. But in the end, I never saw an exhaustive explanation about the boot process in the first place so I am that to know that I did not miss out anything.
Great visualization of the entire boot process, Thank you.
Wow… such an awesome video for some one who is aware about the boot process but just wants to brush up on their memory… lovely thanks ☺️
I think no matter the type of bios, the bios is written in the EEPROM located in the motherboard. It is not attached to any disk. So even if the boot failure or no OS is installed you can still access bios.
KUDOS! I've never seen such nicer explanation for this.
This is incredibly well explained and illustrated! Thank you so much!
This was exactly the kind of explanation I was looking for! Wonderfull job, man. Subscribed
Best Summary of the Boot process
short and sweet. little bit of history of why but not too much is perfect.
Great content, always helpful and always impressive. Thank you very much for taking the time to make these.
That’s beautiful and enormous work! Great thanks.
Have never such a visually stunning explanation of a boot process. Amazing video
Thankyou so so much for sharing. Piece of art with tons of knowledge
Great summary and visualization of the entire boot process. Very well done mate!!!!
One of the best channels in last few years
Wow, I just loved it - I am recomending to my felow IT guys who ignore those initial steps.
Regards from Brazil and keep posting!
It is possible to use gpt partitions without needing UEFI. Even old motherboards with intel 775 socket will boot using gpt partitions without UEFI:
"Yes, it is possible to use GPT (GUID Partition Table) partitions without UEFI (Unified Extensible Firmware Interface). GPT is a partitioning scheme for formatting and partitioning hard drives, and it's independent of the firmware interface being used (UEFI or BIOS).
However, the ability to boot from a GPT-partitioned disk depends on the firmware of your system. Most modern systems use UEFI firmware to boot, and UEFI is compatible with both GPT and the older MBR (Master Boot Record) partitioning scheme.
If your system uses the older BIOS (Basic Input/Output System) firmware instead of UEFI, it may have limitations when it comes to booting from GPT disks. Some BIOS systems can boot from GPT disks using a compatibility support module (CSM), while others may not support GPT booting at all.
So, in summary, while you can use GPT partitions without UEFI, the ability to boot from a GPT disk depends on the firmware capabilities of your system."
I was looking for something like this. This is great thank you!
Missing initrd or initramfs part?
Right, this part is missing
also it is possible to use GPT without using UEFI boot ... so this is kind of useless, at least for me.
Nice and simple !
But you're missing the loading of initrd. I admit I can't remember from the top of my head when exactly it occurs. Would be a nice addition to your explanation.
In the classic Grub or Lilo bootloader, the initrd or initram (NB they are different!) is loaded after the kernel but before control is passed.
There are also the kernel parameters (append details in some boot loaders) that the boot loader has to make available to the kernel. These can be flags or switches to the kernel, to systemd, or to other programs run later on.
More detail please.
A series would be good describing each and every nook and cranny.
Excellent overhead view of the boot process. Of course most of us will have criticisms of what is presented here but if one is trying to keep it simple of course it will be grossly oversimplified.
I sept yesterday learning all this by myself and today, youtube recommended me this. If I had found this video, maybe I would have learned all that in 5 minutes.
This is my favourite new channel.
This channel is absolutely brilliant. I am blown away! 0__0 wow
The information density here is very high
Very nicely explained and beautifully visualized presentation. I have to ask tho, would you like to make that same presentation again but for a Secured and TPM measured bootgraph ? If so, please do it, people and especially the linux community would need this in order to understand why the TPM makes booting so much more secure. I would even offer my help understanding a measured boot process (which I am pretty sure you would have no trouble understanding on your own).
Thank you for that explanation! May you please explain a bit more on GRBU2, and the and the menu you have shown at 2.15 min, in this video?
Your explanation is amazing, sir!
I was like he is going to miss systemd 😂, nope nailed it. This is well covered, love the illustration.
Nicely done! Good visual aids too
Very lovely & professional made
Great video.. I could not have done this better like you
Though I am a Linux user for the last 15 years..
Thank you
systemd-boot is great. No fuss just straight to the point !
This video really simplified things!
very very nice. excellent animation. forcing us to view compulsorily immediately though we have plenty of pending works. it is like movie attracts us. go ahead.
Great job! It looks clean, straightforward, and easy to understand. Could you tell me what software you used to create this video? I'm interested in making my own technical videos in the same manner.
I would have appreciated more time being given to the transition between the boot loader and systemd (the kernel initialization).
Same, i wonder what the name of the first process that runs within the kernel is. Is there some sort of entry point within the kernel like a main function or something that eventually calls systemd?
I was looking something like this and kind of explanation thanks man😊
Hi, thanks for video, good visualization. It will be interesting to see video about network adapter driver work in details, with interruptions and memory usage, kernel and so on.
Learning that "Post" is an anagram and not just a term used for "successful boot up" blew my mind a bit.
Great video, well reformulated .
can you also please make a video about LVM
In the early days of Linux, IDE hard drive support had to be manually compiled into the kernel. Kernel modules are loaded from a drive, but without drive support, the kernel could not load modules from a device it could not read. So, IDE support had to be compiled into the kernel, then once the kernel could use the drive, it could load other modules.
This was a huge big deal, because compiling a kernel with a 386SX processor and 4 mb of ram would take days.
Although a thing to point out is that you don't need a boot loader now, you can just expose the kernel to UEFI and write flags directly into boot record.
Can you please post a link to a "how to" on skipping the "grub" phase of booting?
And if you do that do you have to avoid using an initial ramdisk in the usual Linux way? I can't see how the boot flags alone can properly load the ramdisk (which might of course be my ignorance, hence my question)
@@trueriver1950 Search for 'EFI stub kernel' if the link below does not work
Thank you!
Great animation!
Great overview. I think is good background info for any OS.
Great descriptions... 😊
What about the SPI flash? Coreboot/DepthCharge or uBoot and TowBoot?
What about the details of gdm3 and starting the graphical shell?
Absolutely amazing explanation. Thank you.
Well done!
Wonder why there is a stage 1 (initrd) and stage 2 in the Linux boot process
initrd used to be a ext2/ext3 partition that can be mounted as loop device, now it's just a compressed a cpio archive, usually distro kernel is light and doesn't have network/disk/fs drivers so when the kernel is pushed to memory by grub it can't recognize hw and even mount fs. All needed drivers are stored in initrd image. More over linux thin clients mount root via nfs or nbd and again drivers and glue shell code is stored in initrd. And so called second stage is a chain load when a real hd init process is started and a root pivot is happening.
Great video. Thank you.
Sir, thank you for such creative tutorials please make one on Spark
Today I read chapter 5 on How Linux Works by press starch. You took about 30 pages and summarized them in 4:43 minutes, except the book of course went in more detail at each step. Plus it had all the different boot loaders listed, even ones that are dead and gone. Do you have a System D VS Wayland video yet?
Systemd and wayland do different things. Systemd is simply the first program that the Linux kernel executes. When it starts, it reads a bunch of configuration files to figure out which other programs need to be run for the system to function, such as a network firewall or database like Mysql/Postgres. It also boots a program responsible for showing you the login screen. It's this login program (formally, a display manager) that figures out how to boot your desktop environment, which may use the Wayland protocol (it is not a program) or X11 protocol to communicate with the Wayland server or the X11 server, respectively.
The Wayland and X11 servers are also simply programs that do the job of interfacing with the linux kernel (and by extension the hardware) to allow clients (i.e., your window manager like Gnome or your browser like Firefox) to be able to draw to the screen in a hardware-independent way (i.e., not worrying about whether you're running AMD/Nvidia/Intel graphics). All that's necessary to run a graphical program is for it to speak the Wayland protocol to a running Wayland server process.
It just so happens that Systemd is responsible for starting the X11 and Wayland servers, because the init system is the most natural way to manage long-running processes upon which many other processes depend.
It's a great broadcast. I wonder what programme you use to make such videos, the animations are very nice.
Doesn't grub also load an initrd image as well as the kernel? Where does squashfs fit in?
This was excellent, well done.
this is awesome, the same core idea when develop embedded firmware as well
how do do you do these animations? its nice and clean!
Excellent presentation. Thank you for posting it.
I love your presentations! Which tool do you use to create or generate them with such a beautiful animation?
No way. I just guessed it right. I told exact same on my interview 😂.
Excellent demo
thank you, like it and share it with my students.
Excellent presentation and narration; whats' used for your animations?
Awsome, great job. thanks a lot for your time. excellent explanation!
Where is initrd or initramfs? It is present in most if not all Linux system? Seems like you missed something.
Not all, I do not use one for instance. But by default it is indeed used widely. Neither is boot loader mandatory, UEFI can load properly configured kernel directly (if you do not need all the extra flexibility of boot loader)
I bought your books 📚, but haven't had time to read, by I hope I will do soon.
Gracias , no entiendo mucho de computación , pero me pareció genial , la explicación animada, entiendo que debe ser un experto en ciencias de la computacion
awww I thought you're gonna go into more detail about primary and secondary boot loader
Thank you very much for this video. Got stuck for 2 days because of GPT's false information
this was great, thanks
This seems more like a brief description of how *any* OS boots on a PC, just using the linux names for the later steps where it'll differ. Up to the boot loader step, there's not even an OS involved. And Windows uses a boot loader as well, it's just not called that and tends to be hidden from view for most people. Still, the same process. Code the hardwired system can find that loads the actual operating system. And whatever OS it is, the first step will usually be getting the kernel of the system going, drivers, etc. Same basic flow for any OS. Aside from the names used in those last steps, nothing here specific to linux.
An actual OS specific discussion of the boot process would start with the kernel loading. It's from that point that OS's diverge. The boot loader itself can be setup to point to different kernels and/or different OSs itself, which is how a dual boot works.
Very nice as always
Hey, can you do the same for Windows?
wonderful video, thanks
Nice video good explanation and presentation 👍
Thanks, it's a very good summary video with a good global presentation
thanks for the explanation! this helps!
Thank you sir.
Nice diagrams too.
Great presentation! Thanks!
Nice explanation and great graphics.
I think this video could have extended itself to include the graphical boot process. The display manager which boots up the desktop environment.
Right. I use LightDM, which handles the graphical login, let's me select which Desktop Environment I want to use, & starts the DE
Thank you for the information, as a follow-up will be great to take a step back and have instructions on how to identify if our system (desktop, laptop, mini PC, or server) supports UEFI for a faster boot, better functionality, and security. Thank you again!
That should be something you can look up based on your OS version and your motherboard model.
How to run two kernel at the same time. Can you ever switch processor type. Two clocks.
Thanks! Loud and clear
Really good video, thank you sir
nice explanation best so far :)
Thanks, well done. A lot of whinging in the comments, "but this, but that". What do they expect in under 5 mins?
thank your for this helpful explanation!
Prior to boot loader what is the software that controls all these? Also how does a boot loader identify all the available kernals? like how does it know? is there already a software that reads this?
0:24 where is multicontroler?
great explanation .