• # √áa ne nous rajeunit pas

    Post√©¬†par¬† . √Č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¬† . √Č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¬† . √Čvalu√©¬†√†¬†2 (+0/-0).

        Et il me semble qu'il n'y a pas de grub sur les distributions Linux à base de CPU ARM (ex : Raspberry pi)

        Il doit y a avoir un petit u-boot sur les Raspberry pi non ?

        • [^] # Re: √áa ne nous rajeunit pas

          Post√©¬†par¬† . √Č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¬† . √Č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¬† . √Č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¬† (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¬† . √Č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¬† . √Čvalu√©¬†√†¬†1 (+0/-0).

        il me semble qu'il n'y a pas de grub sur les distributions Linux à base de CPU ARM

        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¬† (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.

    • [^] # Re: sans bootloader -- ou plut√īt linux comme bootloader.

      Post√©¬†par¬† (Mastodon) . √Čvalu√©¬†√†¬†4 (+1/-0).

      √Č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‚Ķ

    • [^] # Re: sans bootloader -- ou plut√īt linux comme bootloader.

      Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†5 (+2/-0).

      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 ).

      • [^] # Re: sans bootloader -- ou plut√īt linux comme bootloader.

        Post√©¬†par¬† . √Č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).

        • [^] # Re: sans bootloader -- ou plut√īt linux comme bootloader.

          Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†3 (+0/-0).

          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.

  • # c'est √† la mode

    Post√©¬†par¬† . √Č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.