Les vieilles versions du noyau pouvaient booter sans bootloader, il y avait un utilitaire (rdev) qui permettait d'écrire dans l'image du noyau les paramètres de boot.
Posté par totof2000 .
Évalué à 5 (+3/-0).
Dernière modification le 09 juillet 2024 à 16:23.
Le bootloader (tel que grub) n'avait de raison d'être que sur des machines x86, en raison de la limitation du sercteur de boot à 512 octets, et surtout pour pouvoir installer plusieurs OS sur le même disque. ( je me rappelle encore du fameux LILO sur les premier Linux que j'avais intallé ). Si le BIOS avait permis d'aller chercher un programme de plus de 512 octets sur le disque dur des machines x86, nous n'aurions pas eu besoin de gestionnaire de démarrage ( il me semble que les machines sun, IBM/AIX - ou apple PowerPC - qui utilisent l'Open Firmware, n'ont pas besoin de cette étape intermédiaire : ils vont lire directement le noyau sur la partition si ma mémoire est bonne).
Aujourd'hui avec l'UEFI, même pour du multi-boot on peut se passer de Grub (ou tout autre logiciel équivalent). Et il me semble qu'il n'y a pas de grub sur les distributions Linux à base de CPU ARM (ex : Raspberry pi).
Tiens … d'ailleurs cette histoire de bootloader, et de secteur de démarrage de 512 octets me fait penser à une série de journaux que je dois écrire depuis maintenant bien longtemps ( idée que j'ai eue durant le premier confinement COVID, que je n'ai pas pu concrétiser à l'époque par manque de motivation, mais celle-ci m'est revenue ces derniers temps).
u-boot fait partie du firmware du raspberry pi : je le vois au même niveau que le BIOS ou l'UEFI. Si on veut parler de boot loader pour RPi, je verrais un truc du style Noobs/Pinn, ou Berryboot
Merci pour cette réponse. Pourtant U-Boot, c'est bien un bootloader. En ligne de commande, on peut choisir sur quelle partition démarrer. Fonctionnellement, il peut faire du dual boot comme indiqué dans le lien.
Effectivement, je mélange un peu tout … La page wikipedia sur uboot indique que celui-ci peut remplacer BIOS et UEFI, j'avais aussi par ailleurs lu des articles ou justement uboot joue le rôle de l'UEFI dans certaines cartes ARM (ça doit être ici d'ailleurs ). Enfin, après avoir lu ce document (en diagonale je l'avoue), j'ai confondu uboot et firmware pour le Raspberry pi. Or il semble qu'en fait le firmware de démarrage du RPi n'est pas uboot, mais que rien n'empêche de l'installer sur un raspberry pi (ce que je ne savais pas) ou il prendra le rôle de Grub (voir par exemple https://elinux.org/RPi_U-Boot).
Posté par Psychofox (Mastodon) .
Évalué à 4 (+1/-0).
Dernière modification le 09 juillet 2024 à 18:40.
Le titre du lien laisse à penser que la présentation porte sur le démarrage de linux sans bootloader. En l'occurence c'est en partie vrai, mais pas nouveau car UEFI a toujours permis de booter un noyau linux directement. Mais les distros ne mettent presque jamais ça en place, d'une part pour avoir une UX égale qu'on utilise un matériel avec ou sans UEFI, mais aussi pour les autres fonctionnalités: avoir un menu permettant d'éligir le noyau que l'on veut démarrer, booter un autre OS, accéder au firmware depuis le menu, etc. La partie intéressante de la présentation, c'est nmbl, qui permet d'utiliser linux comme bootloader afin de remplacer grub. Grosso merdo les ingés de redhat se sont rendu compte que:
grub doit implémenter plein de trucs déjà supporté par linux comme le support de divers systèmes de fichiers différents, tout ce code est un peu redondant.
grub a eu pas mal de failles de sécurité
du coups pourquoi ne pas faire grub avec linux. Ça fait moins de code à maintenir et corriger, une faille de sécurité de linux sera corrigée dans linux et dans le bootloader nmbl utilisant linux, etc.
Et c'est ce qu'on voit dans la démo à la fin, nmbl a deux mode: un où le noyau de la distro est booté automatiquement, mais sur lequel on peut changer des paramètres, un autre où on peut accéder à un menu interactif et choisir son noyau/OS.
Accessoirement les commentaires sur hacker news m'ont permis de découvrit que nmbl n'est pas le premier projet dans ce sens à utiliser linux comme bootloader puisqu'il existait déjà zfsbootmenu qui est un bootloader construit à base d'un noyau linux et du driver ZFS pour fournir les mêmes fonctionnalités que le booloader de FreeBSD et permettre de booter un système linux avec root sur ZFS en utilisant les dernières fonctionnalités proposées par openzfs, le support ZFS de Grub étant basé sur du vieux code ZFS hérité de la version d'Oracle. Il permet par exemple de booter sur différentes distros/kernels installés sur le même pool ZFS, de démarer depuis un snapshot en particulier, y compris si celui-ci est sur un dataset chiffré en proposant l'invite de passphrase directement au niveau du bootloader. Il est même possible depuis le bootloader ZFSmenu de faire un snapshot ou cloner un dataset avant de booter depuis-celui-ci.
Évidemment dans le cas de zfsbootmenu on peut se poser la même question que pour ubuntu sur la légalité vis à vis de l'incompatibilité GPL/CDDL pour livrer des binaires linux avec un support ZFS…
grub doit implémenter plein de trucs déjà supporté par linux comme le support de divers systèmes de fichiers différents, tout ce code est un peu redondant.
En plus d'être redondant, il manque parfois de fonctionnalité. Par exemple, j'ai pu voir il y a 15 ans que le support par Grub du fs de mon macbook était incomplet (donc j'ai eu la joie de faire un patch pour installer Fedora sur le dit portable tout neuf).
J'imagine que c'est pareil quand tu veux supporter des nouveaux systémes de fichiers, il faut attendre le support dans grub et refaire le travail de 0 (vu que grub est en GPL 3+, et le kernel en GPL 2 uniquement, et je pense que c'est pas automatiquement compatible). Et de toute façon, tu va devoir refaire le code car grub n'a pas besoin d'écrire, juste de lire, donc tu peux simplifier tout (ce qui est mieux d'un point de vue de l'optimisation, mais moins bien d'un point de vue de devoir refaire le code ).
Posté par raphj .
Évalué à 2 (+0/-0).
Dernière modification le 10 juillet 2024 à 13:19.
ce qui est mieux d'un point de vue de l'optimisation
Ce n'est même pas clair que ça fonctionne en pratique : j'imagine que les FS du noyaux sont optimisés à mort, alors qu'il n'y a peut-être pas autant de pression pour le faire dans Grub.
Sur un sujet connexe, j'ai un disque totalement chiffré avec Btrfs, avec Grub c'est un peu la misère, il prend autour d'une minute à déchiffrer et parfois l'OS demande le mot de passe une deuxième fois selon comment tu navigues dans les menus dans grub. Alors que systemd-boot est capable de déchiffrer immédiatement et c'est mieux intégré.
vu que grub est en GPL 3+, et le kernel en GPL 2 uniquement, et je pense que c'est pas automatiquement compatible
Ça peut fonctionner si le code du FS est sous licence permissive ou sous GPLv2+ (ce qui reste possible, mais je ne sais pas quelles sont les règles exactes).
Ce n'est même pas clair que ça fonctionne en pratique : j'imagine que les FS du noyaux sont optimisés à mort, alors qu'il n'y a peut-être pas autant de pression pour le faire dans Grub.
J'aurais du préciser, je pensais à la taille du code (et donc du binaire). Si tu as que besoin de lire, tu peux retirer pas mal de choses donc le binaire va être plus petit. Ce n'est sans doute plus pertinent avec avec GPT et l'UEFI, mais au bon vieux temps du MBR, l'important était autre.
Ça peut fonctionner si le code du FS est sous licence permissive ou sous GPLv2+ (ce qui reste possible, mais je ne sais pas quelles sont les règles exactes).
Ou si tu chopes du code venant d'un BSD par exemple. Maintenant, le souci de BSD, c'est que ça va pas pas supporter rapidement les nouveaux fs de Linux, donc ç'est pas non plus génial.
# Ça ne nous rajeunit pas
Posté par Barnabé . Évalué à 7 (+6/-0).
Les vieilles versions du noyau pouvaient booter sans bootloader, il y avait un utilitaire (rdev) qui permettait d'écrire dans l'image du noyau les paramètres de boot.
Par contre, fallait pas se planter……
[^] # Re: Ça ne nous rajeunit pas
Posté par totof2000 . Évalué à 5 (+3/-0). Dernière modification le 09 juillet 2024 à 16:23.
Le bootloader (tel que grub) n'avait de raison d'être que sur des machines x86, en raison de la limitation du sercteur de boot à 512 octets, et surtout pour pouvoir installer plusieurs OS sur le même disque. ( je me rappelle encore du fameux LILO sur les premier Linux que j'avais intallé ). Si le BIOS avait permis d'aller chercher un programme de plus de 512 octets sur le disque dur des machines x86, nous n'aurions pas eu besoin de gestionnaire de démarrage ( il me semble que les machines sun, IBM/AIX - ou apple PowerPC - qui utilisent l'Open Firmware, n'ont pas besoin de cette étape intermédiaire : ils vont lire directement le noyau sur la partition si ma mémoire est bonne).
Aujourd'hui avec l'UEFI, même pour du multi-boot on peut se passer de Grub (ou tout autre logiciel équivalent). Et il me semble qu'il n'y a pas de grub sur les distributions Linux à base de CPU ARM (ex : Raspberry pi).
Tiens … d'ailleurs cette histoire de bootloader, et de secteur de démarrage de 512 octets me fait penser à une série de journaux que je dois écrire depuis maintenant bien longtemps ( idée que j'ai eue durant le premier confinement COVID, que je n'ai pas pu concrétiser à l'époque par manque de motivation, mais celle-ci m'est revenue ces derniers temps).
[^] # Re: Ça ne nous rajeunit pas
Posté par nico4nicolas . Évalué à 2 (+0/-0).
Il doit y a avoir un petit u-boot sur les Raspberry pi non ?
[^] # Re: Ça ne nous rajeunit pas
Posté par totof2000 . Évalué à 2 (+0/-0).
u-boot fait partie du firmware du raspberry pi : je le vois au même niveau que le BIOS ou l'UEFI. Si on veut parler de boot loader pour RPi, je verrais un truc du style Noobs/Pinn, ou Berryboot
[^] # Re: Ça ne nous rajeunit pas
Posté par nico4nicolas . Évalué à 2 (+0/-0).
Merci pour cette réponse. Pourtant U-Boot, c'est bien un bootloader. En ligne de commande, on peut choisir sur quelle partition démarrer. Fonctionnellement, il peut faire du dual boot comme indiqué dans le lien.
[^] # Re: Ça ne nous rajeunit pas
Posté par totof2000 . Évalué à 2 (+1/-1).
Effectivement, je mélange un peu tout … La page wikipedia sur uboot indique que celui-ci peut remplacer BIOS et UEFI, j'avais aussi par ailleurs lu des articles ou justement uboot joue le rôle de l'UEFI dans certaines cartes ARM (ça doit être ici d'ailleurs ). Enfin, après avoir lu ce document (en diagonale je l'avoue), j'ai confondu uboot et firmware pour le Raspberry pi. Or il semble qu'en fait le firmware de démarrage du RPi n'est pas uboot, mais que rien n'empêche de l'installer sur un raspberry pi (ce que je ne savais pas) ou il prendra le rôle de Grub (voir par exemple https://elinux.org/RPi_U-Boot).
[^] # Re: Ça ne nous rajeunit pas
Posté par Pol' uX (site web personnel) . Évalué à 2 (+1/-1).
Étonnant d'ailleurs qu'il n'y ait pas un bootloader dans la galaxie systemd.
Adhérer à l'April, ça vous tente ?
[^] # Re: Ça ne nous rajeunit pas
Posté par Misc (site web personnel) . Évalué à 4 (+1/-0).
Il y a ça, qui s'appuie sur l'EFI:
https://systemd.io/BOOT/
[^] # Re: Ça ne nous rajeunit pas
Posté par patrick_g (site web personnel) . Évalué à 3 (+0/-0).
Je l'utilise et ça marche très bien. C'est beaucoup plus léger et minimaliste que cet énorme machin qu'est GRUB2.
[^] # Re: Ça ne nous rajeunit pas
Posté par Barnabé . Évalué à 1 (+0/-0).
Je parlais d'une époque à laquelle linux n'avait pas été porté sur d'autres architectures que le i386.
On pouvait démarrer em mettant le noyau sur disquette, et en lui indiquant avec rdev où il trouverait sa racine.
On avait en général une disquette de rescue, en cas de fausse manip avec LILO.
[^] # Re: Ça ne nous rajeunit pas
Posté par Luc-Skywalker . Évalué à 1 (+0/-0).
https://forum.armbian.com/tags/uefi-arm64/
désolé, c'est un peu court, mais je suis au boulot.
"Si tous les cons volaient, il ferait nuit" F. Dard
# sans bootloader -- ou plutôt linux comme bootloader.
Posté par Psychofox (Mastodon) . Évalué à 4 (+1/-0). Dernière modification le 09 juillet 2024 à 18:40.
Le titre du lien laisse à penser que la présentation porte sur le démarrage de linux sans bootloader. En l'occurence c'est en partie vrai, mais pas nouveau car UEFI a toujours permis de booter un noyau linux directement. Mais les distros ne mettent presque jamais ça en place, d'une part pour avoir une UX égale qu'on utilise un matériel avec ou sans UEFI, mais aussi pour les autres fonctionnalités: avoir un menu permettant d'éligir le noyau que l'on veut démarrer, booter un autre OS, accéder au firmware depuis le menu, etc. La partie intéressante de la présentation, c'est
nmbl, qui permet d'utiliser linux comme bootloader afin de remplacer grub. Grosso merdo les ingés de redhat se sont rendu compte que:grubavec linux. Ça fait moins de code à maintenir et corriger, une faille de sécurité de linux sera corrigée dans linux et dans le bootloader nmbl utilisant linux, etc.Et c'est ce qu'on voit dans la démo à la fin,
nmbla deux mode: un où le noyau de la distro est booté automatiquement, mais sur lequel on peut changer des paramètres, un autre où on peut accéder à un menu interactif et choisir son noyau/OS.Accessoirement les commentaires sur hacker news m'ont permis de découvrit que
nmbln'est pas le premier projet dans ce sens à utiliser linux comme bootloader puisqu'il existait déjà zfsbootmenu qui est un bootloader construit à base d'un noyau linux et du driver ZFS pour fournir les mêmes fonctionnalités que le booloader de FreeBSD et permettre de booter un système linux avec root sur ZFS en utilisant les dernières fonctionnalités proposées par openzfs, le support ZFS de Grub étant basé sur du vieux code ZFS hérité de la version d'Oracle. Il permet par exemple de booter sur différentes distros/kernels installés sur le même pool ZFS, de démarer depuis un snapshot en particulier, y compris si celui-ci est sur un dataset chiffré en proposant l'invite de passphrase directement au niveau du bootloader. Il est même possible depuis le bootloader ZFSmenu de faire un snapshot ou cloner un dataset avant de booter depuis-celui-ci.[^] # Re: sans bootloader -- ou plutôt linux comme bootloader.
Posté par Psychofox (Mastodon) . Évalué à 4 (+1/-0).
Évidemment dans le cas de
zfsbootmenuon peut se poser la même question que pour ubuntu sur la légalité vis à vis de l'incompatibilité GPL/CDDL pour livrer des binaires linux avec un support ZFS…[^] # Re: sans bootloader -- ou plutôt linux comme bootloader.
Posté par Misc (site web personnel) . Évalué à 5 (+2/-0).
En plus d'être redondant, il manque parfois de fonctionnalité. Par exemple, j'ai pu voir il y a 15 ans que le support par Grub du fs de mon macbook était incomplet (donc j'ai eu la joie de faire un patch pour installer Fedora sur le dit portable tout neuf).
J'imagine que c'est pareil quand tu veux supporter des nouveaux systémes de fichiers, il faut attendre le support dans grub et refaire le travail de 0 (vu que grub est en GPL 3+, et le kernel en GPL 2 uniquement, et je pense que c'est pas automatiquement compatible). Et de toute façon, tu va devoir refaire le code car grub n'a pas besoin d'écrire, juste de lire, donc tu peux simplifier tout (ce qui est mieux d'un point de vue de l'optimisation, mais moins bien d'un point de vue de devoir refaire le code ).
[^] # Re: sans bootloader -- ou plutôt linux comme bootloader.
Posté par raphj . Évalué à 2 (+0/-0). Dernière modification le 10 juillet 2024 à 13:19.
Ce n'est même pas clair que ça fonctionne en pratique : j'imagine que les FS du noyaux sont optimisés à mort, alors qu'il n'y a peut-être pas autant de pression pour le faire dans Grub.
Sur un sujet connexe, j'ai un disque totalement chiffré avec Btrfs, avec Grub c'est un peu la misère, il prend autour d'une minute à déchiffrer et parfois l'OS demande le mot de passe une deuxième fois selon comment tu navigues dans les menus dans grub. Alors que systemd-boot est capable de déchiffrer immédiatement et c'est mieux intégré.
Ça peut fonctionner si le code du FS est sous licence permissive ou sous GPLv2+ (ce qui reste possible, mais je ne sais pas quelles sont les règles exactes).
[^] # Re: sans bootloader -- ou plutôt linux comme bootloader.
Posté par Misc (site web personnel) . Évalué à 3 (+0/-0).
J'aurais du préciser, je pensais à la taille du code (et donc du binaire). Si tu as que besoin de lire, tu peux retirer pas mal de choses donc le binaire va être plus petit. Ce n'est sans doute plus pertinent avec avec GPT et l'UEFI, mais au bon vieux temps du MBR, l'important était autre.
Ou si tu chopes du code venant d'un BSD par exemple. Maintenant, le souci de BSD, c'est que ça va pas pas supporter rapidement les nouveaux fs de Linux, donc ç'est pas non plus génial.
# c'est à la mode
Posté par steph1978 . Évalué à 2 (+0/-0).
article : One File Linux
C'est bien l'EFI prend enfin ses marques par rapport au vénérable BIOS.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.