issue202:c_c
Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente | ||
issue202:c_c [2024/02/27 06:56] – d52fr | issue202:c_c [2024/02/28 11:53] (Version actuelle) – andre_domenech | ||
---|---|---|---|
Ligne 4: | Ligne 4: | ||
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. ** | 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. ** | ||
+ | |||
+ | Pour faire suite à une question que j'ai reçue, j' | ||
+ | |||
+ | Que se passe-t-il lorsque j' | ||
+ | |||
+ | En général, c'est là que votre BIOS ou UEFI entre en action et prépare les choses pour vous. Il s'agit d'un code ou d'un logiciel qui prépare des éléments tels que le clavier, l' | ||
+ | |||
**So what does a bootloader do?: | **So what does a bootloader do?: | ||
Ligne 10: | Ligne 17: | ||
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! ** | 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! ** | ||
+ | |||
+ | Que fait donc un chargeur de démarrage ? | ||
+ | ••Tout d' | ||
+ | ••Deuxièmement, | ||
+ | |||
+ | Le chargeur d' | ||
+ | |||
**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. ** | **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. ** | ||
+ | |||
+ | Voyons cela sous l' | ||
**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. | **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. | ||
Ligne 17: | Ligne 33: | ||
That is more-or-less the overview of the way your Ubuntu machine boots. | 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. ** | + | 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, | + | 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, |
Please send any comments or concerns to misc@fullcirclemagazine.org** | Please send any comments or concerns to misc@fullcirclemagazine.org** | ||
+ | |||
+ | Systemd utilise les fichiers de configuration cibles pour choisir le mode dans lequel il va démarrer. Comme, par exemple, le mode utilisateur graphique auquel nous sommes habitués. Considérez-les comme les anciens scripts init ou runlevels, si vous avez une certaine expérience des anciennes distributions (j' | ||
+ | |||
+ | C'est plus ou moins l' | ||
+ | |||
+ | Parmi les outils utiles, il y a dmesg - sur Ubuntu, vous devez taper : sudo dmesg pour voir la sortie. N' | ||
+ | |||
+ | Dans dmesg, vous pouvez voir ce qui s'est passé, à quel moment du processus de démarrage. Les choses se sont-elles bien passées, ont-elles mal tourné ? Les distributions modernes ont un code couleur pour dmesg, mais beaucoup n'en ont pas, et vous devrez prêter une attention particulière à la sortie dans ce cas. J' | ||
+ | |||
+ | N' | ||
issue202/c_c.1709013415.txt.gz · Dernière modification : 2024/02/27 06:56 de d52fr