| Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente |
| issue202:c_c [2024/02/27 18:47] – auntiee | issue202:c_c [2024/02/28 11:53] (Version actuelle) – andre_domenech |
|---|
| Que se passe-t-il lorsque j'appuie sur le bouton d'alimentation ? | Que se passe-t-il lorsque j'appuie sur le bouton d'alimentation ? |
| |
| 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'écran et le stockage. On l'appelait auparavant POST (Power On Self Test). POST interroge votre matériel et s'assure qu'il répond, avant de l'allumer. (Ce n'est pas tout à fait exact, mais cela vous permet de le comprendre facilement et de l'imaginer par vous-même, car il s'agit d'une vue d'ensemble de haut niveau). En cas d'erreur, vous obtiendrez généralement un message d'erreur à l'écran ou un bip sonore du BIOS (vous pouvez consulter la signification de ces bips pour votre BIOS spécifique sur l'Internet). Si tout est en ordre, le BIOS/UEFI va chercher votre espace de stockage et le chargeur de démarrage (nous y reviendrons plus tard). Vous pouvez contrôler l'endroit où il cherche et l'ordre dans lequel il cherche dans les paramètres du BIOS/UEFI (généralement quelque chose appelé « ordre de démarrage »). C'est ici que le BIOS et l'UEFI ne sont pas identiques. Le BIOS recherche le Master boot record (MBR - secteur d'amorçage maître) et l'UEFI recherche une partition UEFI. C'est le fichier .efi du chargeur de démarrage (bootloader) dont les gens parlent si vous vous intéressez au processus de démarrage de l'UEFI. | 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'écran et le stockage. On l'appelait auparavant POST (Power On Self Test). POST interroge votre matériel et s'assure qu'il répond, avant de l'allumer. (Ce n'est pas tout à fait exact, mais cela vous permet de le comprendre facilement et de l'imaginer par vous-même, car il s'agit d'une vue d'ensemble de haut niveau). En cas d'erreur, vous obtiendrez généralement un message d'erreur à l'écran ou un bip sonore du BIOS (vous pouvez consulter la signification de ces bips pour votre BIOS spécifique sur l'Internet). Si tout est en ordre, le BIOS/UEFI va chercher votre espace de stockage et le chargeur de démarrage (nous y reviendrons plus tard). Vous pouvez contrôler l'endroit où il cherche et l'ordre dans lequel il cherche dans les paramètres du BIOS/UEFI (généralement quelque chose appelée « ordre de démarrage »). C'est ici que le BIOS et l'UEFI ne sont pas identiques. Le BIOS recherche le Master boot record (MBR - secteur d'amorçage maître) et l'UEFI recherche une partition UEFI. C'est le fichier .efi du chargeur de démarrage (bootloader) dont les gens parlent si vous vous intéressez au processus de démarrage de l'UEFI. |
| |
| |
| **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'angle de Linux. Une fois que Grub2 (votre chargeur de démarrage) a fini de trouver et de charger votre noyau dans la mémoire, il passe le contrôle à ce noyau. Le noyau prend alors en charge le processus de démarrage, et commence à faire le démarrage que vous verrez sur votre écran, si vous n'avez pas quelque chose comme Plymouth d'installé. Avec le matériel moderne, cette liste défilante défile généralement trop vite pour être lue de toute façon ! Ce qui se passe ici, c'est que le noyau lance tous les services et processus nécessaires. Le processus est le suivant : le noyau décompresse (nous avons publié un article à ce sujet il y a quelque temps à propos de l'algorithme de compression), ou se déploie dans la mémoire. Le noyau inclut un bout de code de décompression qui gère le déballage du noyau lui-même une fois qu'il est chargé, et il inclut un support complet de décompression pour initramfs. Le noyau vérifie alors le matériel disponible et charge les pilotes de périphériques pour ce matériel ainsi que d'autres modules nécessaires au noyau. Le processus initial qui démarre est le processus init (vous voyez ?). En tant qu'utilisateurs d'Ubuntu, nous le connaissons tous sous le nom de Systemd. Dans les distributions plus anciennes, il s'agissait de SysV ou Upstart, et il en existe d'autres. Comme c'est le premier processus qui s'exécute, c'est le processus parent de tous les autres processus qui s'exécutent sur votre ordinateur. Qu'on l'aime ou qu'on le déteste, Systemd est ce que vous avez dans votre système d'exploitation Ubuntu. Systemd va maintenant prendre le relais et rendre votre système prêt à l'emploi. Lorsque vous lancez quelque chose comme systemd-analyze blame, il vous montrera tous les services qu'il a exécutés et le temps qu'il a mis pour le faire. Systemd peut également trouver et exécuter des pilotes supplémentaires qui ne sont pas exécutés par le noyau pour tout matériel supplémentaire. | Voyons cela sous l'angle de Linux. Une fois que Grub2 (votre chargeur de démarrage) a fini de trouver et de charger votre noyau dans la mémoire, il passe le contrôle à ce noyau. Le noyau prend alors en charge le processus de démarrage, et commence à faire le démarrage que vous verrez sur votre écran, si vous n'avez pas quelque chose d'installé comme Plymouth. Avec le matériel moderne, cette liste défilante défile généralement trop vite pour être lue de toute façon ! Ce qui se passe ici, c'est que le noyau lance tous les services et processus nécessaires. Le processus est le suivant : le noyau décompresse (nous avons publié un article à ce sujet il y a quelque temps à propos de l'algorithme de compression), ou se déploie dans la mémoire. Le noyau inclut un bout de code de décompression qui gère le déballage du noyau lui-même une fois qu'il est chargé, et il inclut un support complet de décompression pour initramfs. Le noyau vérifie alors le matériel disponible et charge les pilotes de périphériques pour ce matériel ainsi que d'autres modules nécessaires au noyau. Le processus initial qui démarre est le processus init (vous voyez ?). En tant qu'utilisateurs d'Ubuntu, nous le connaissons tous sous le nom de Systemd. Dans les distributions plus anciennes, il s'agissait de SysV ou Upstart et il en existe d'autres. Comme c'est le premier processus qui s'exécute, c'est le processus parent de tous les autres processus qui s'exécutent sur votre ordinateur. Qu'on l'aime ou qu'on le déteste, Systemd est ce que vous avez dans votre système d'exploitation Ubuntu. Systemd va maintenant prendre le relais et rendre votre système prêt à l'emploi. Lorsque vous lancez quelque chose comme systemd-analyze blame, il vous montrera tous les services qu'il a exécutés et le temps qu'il a mis pour le faire. Systemd peut également trouver et exécuter des pilotes supplémentaires qui ne sont pas exécutés par le noyau pour tout matériel supplémentaire. |
| |
| **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. |
| 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 des 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'étais payé pour me rendre chez un client et taper init 6 sur la ligne de commande...). XD). Systemd s'occupe maintenant de tous les processus d'arrière-plan pour vous, en faisant abstraction de beaucoup de choses pour l'utilisateur. | 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'étais payé pour me rendre chez un client et taper init 6 sur la ligne de commande... XD). Systemd s'occupe maintenant de tous les processus d'arrière-plan pour vous, en gérant beaucoup de choses pour l'utilisateur. |
| |
| C'est plus ou moins l'aperçu de la façon dont votre machine Ubuntu démarre. | C'est plus ou moins l'aperçu de la façon dont votre machine Ubuntu démarre. |
| Parmi les outils utiles, il y a dmesg - sur Ubuntu, vous devez taper : sudo dmesg pour voir la sortie. N'oubliez pas de l'acheminer vers un pager comme less. | Parmi les outils utiles, il y a dmesg - sur Ubuntu, vous devez taper : sudo dmesg pour voir la sortie. N'oubliez pas de l'acheminer vers un pager comme less. |
| |
| 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 de ces codes. J'espère que cela aidera les débutants qui souhaitent se faire une idée du processus de démarrage. | 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'espère que cela aidera les débutants qui souhaitent se faire une idée du processus de démarrage. |
| |
| N'hésitez pas à envoyer vos commentaires ou vos inquiétudes à misc@fullcirclemagazine.org | N'hésitez pas à envoyer vos commentaires ou vos inquiétudes à misc@fullcirclemagazine.org |
| |
