Journal UEFI, à la découverte du nouveau BIOS…

Posté par Pinaraf le 25 octobre 2011 à 00:45. Licence CC By‑SA.

Étiquettes :

oct.

2011

Sommaire

Plongeons nous dans les entrailles de nos machines…
Naissance d'EFI
Voyons un peu comment est construit un EFI…
Concrêtement, comment identifier un EFI ?
Bootons en EFI
Le shell EFI
efilinux
Remerciements

Qu'il semble loin le temps, béni pour certains, maudits pour d'autres, où il était nécessaire de connaître les IRQs et DMAs de sa machine pour l'utiliser, où, loin du Plug'n'Pray, le matériel se contentait de laisser l'humain configurer…
Puis vint le Plug'n'Play, son compagnon l'ACPI permettant de lister le matériel et de le configurer magiquement…
Mais toujours, au sein de la machine, un petit logiciel, le BIOS.
Qui est-il, que fait-il, pourquoi disparaît-il ?

Plongeons nous dans les entrailles de nos machines…

Le BIOS est, de manière assez surprenante, l'élément probablement à l'origine du succès de l'IBM PC.
En effet, le BIOS, l'élément primitif indispensable au démarrage de la machine, a été mis non pas sur les disques de boot mais en ROM, sur la carte mère. Quelques années plus tard, après un peu de reverse engineering, des fabricants ont pu commencer à vendre des clones PC compatibles basés sur une ré-implémentation du BIOS.
Le BIOS est moche, clairement. Très basique, très crade… Mais il faisait son travail, il fournit une abstraction très primitive au matériel. On pouvait presque écrire un OS uniquement en faisant des appels au BIOS, comme DOS…

Les appels au BIOS sont très simples : il s'agit tout bêtement d'une série d'interruptions matérielles… À travers l'IRQ 0x10, on peut donner différentes instructions à la carte graphique, via le registre AH : scroll, changer le mode, les couleurs… L'IRQ 0x13 permet de contrôler les disques…

Naissance d'EFI

Mais avec l'évolution du matériel, les limites sont apparues : le BIOS utilise un mode 16 bits, ne lui permettant pas d'adresser toute la RAM, le boot par le réseau ou par CD est apparu, l'USB est arrivé…
Récemment toutefois, nous avons atteint une limite très difficile à surmonter : la table des partitions gérée par le BIOS ne permet pas d'exploiter des disques de plus de 2 To…
En parallèle, depuis la fin des années 90, Intel avait développé, en partenariat avec HP, l'architecture Itanium, pour laquelle l'utilisation du BIOS n'était pas envisageable. Ainsi Intel développa un outil moderne, puissant, flexible, simple et unanimement repris : l'EFI…
Bon, ok, en vrai c'est plus compliqué : en 1994, l'IEEE avait déjà standardisé Open Firmware, une solution multi plateforme et acceptée pour accomplir une tâche similaire au BIOS. Utilisé sur les machines Sun, Apple, IBM, c'est un outil qui a fait ses preuves et continue à les faire…
Mais pour Intel, Open Firmware n'est pas acceptable. Officiellement, c'est parce que l'Open Firmware duplique l'ACPI en fournissant son propre arbre de périphériques… Mais depuis, le projet OLPC a prouvé que en fait, c'est possible… Par contre dans EFI il y a un arbre de périphériques potentiellement différent de celui de l'ACPI… (Et vous êtes loin de la fin de ce journal hein)
EFI est décrit dans une spécification, contrairement au BIOS qui n'a jamais eu de telle documentation. 2210 pages, plus les 800 pages d'ACPI… Mangez la spécification, c'est du bon…
Bien sûr, EFI a évolué lui aussi : la norme EFI a cessé d'évoluer et l'UEFI fut créé à partir d'EFI 1.10. UEFI est une évolution d'EFI contrôlée par le «forum UEFI» et non plus par Intel…
En 2007, la version 2.1 d'UEFI a apporté la cryptographie, l'authentification réseau, la possibilité de construire une interface graphique… Ouais, on parle toujours de firmware…

Voyons un peu comment est construit un EFI…

On a en fait trois couches dans EFI.
Au cœur se trouve le PEI, Pre-EFI Initialization. Responsable de l'initialisation très bas niveau comme le contrôleur mémoire (truc super tordu mine de rien, cf. les présentations des auteurs de coreboot), il gère à la fois le tout début de l'allumage de la machine mais aussi la sortie de veille… Une fois qu'il a fait son travail, il laisse la main à la deuxième couche et disparaît…
La deuxième couche se nomme DXE, Driver Execution Environment. C'est ce que l'on voit finalement du firmware. C'est un élément indépendant du matériel, capable de charger des pilotes et fournissant des interfaces génériques et normalisées aux applications souhaitant l'utiliser.
Enfin, la troisième couche, les applications EFI, en majeure partie les bootloaders donc…

Alors… Si vous trouvez que ça ressemble à BIOS + OS + applications… Difficile d'argumenter tellement ça semble exact…
Au passage, a priori, une application EFI dépend de l'architecture : elle sera x86, x86-64, ia64…

Concrêtement, comment identifier un EFI ?

Hum, c'est une bonne question.

Je dispose depuis quelques jours d'un ordinateur portable Asus utilisant un magnifique UEFI. Mais par défaut, une émulation du BIOS est présente, permettant de booter un grub sans soucis. Pire encore, par défaut, le boot EFI n'est même pas activé sur les clés USB par exemple…
J'avoue ne pas avoir trouvé de solution depuis Linux pour le savoir. À vrai dire, c'est le but de l'émulation du BIOS, non ? Et le Windows n'a pas vécu assez longtemps (0 secondes) pour vérifier…
Seul un passage par l'interface de configuration du firmware (ce que, par abus de langage, on appellait BIOS) prouve que l'on est face à une machine EFI. Heureusement, ici, pas d'interface graphique qui bouge dans tous les sens. Nous avons une interface sobre, classique, contrôlée au clavier… avec des options comme «UEFI Boot» pour nous mettre sur la voie.

Bootons en EFI

Dans mon ignorance, j'ai installé ma Debian classiquement, sans réfléchir : 256 Mo pour un /boot en ext3, le reste en PV LVM, un grub, et ça roule… Et je ne peux donc pas profiter d'un boot EFI : le bootloader pour EFI doit être stocké sur une partition pour laquelle un pilote est chargé. Ne pouvant ajouter de pilote ext3 dans mon firmware, je me vois contraint d'avoir une partition FAT pour le bootloader !
Mon premier objectif n'étant pas la destruction de mon amour propre et de ma distribution, j'opte donc pour une solution plus sage : booter en EFI sur une clé USB… Le boot EFI 100% natif top moumoute viendra plus tard.

Préparons donc une clé USB à booter en EFI… Mais que mettre dessus ? Mettre un grub classique pour un BIOS, je sais faire… Mais un EFI ne mange pas de ce pain…
Ma clé USB était une clé USB classique, partitionnée avec une table de partitions DOS et une seule partition FAT32, je décidais, pour l'expérience, de la maltraiter un peu. Mais normalement, vous n'avez pas à la maltraiter à ce point…
Donc maltraitons la : passons la en GPT, nouveau format de table de partitions, permettant de passer outre la limite des 2To (indispensable sur une clé de 8Go).
Pour ce faire, parted est notre ami avec la commande mklabel gpt
(Ce journal ne visant pas à faire de vous un expert de parted, je n'irai pas plus loin)
Il suffit donc d'avoir une table des partitions valide, comprise du BIOS, et d'y glisser subtilement une partition FAT…
Faisons donc…
Mais que mettre sur cette partition FAT, et où ?
C'est là où j'ai perdu le plus de temps finalement…
J'avais expliqué tantôt que l'EFI charge une application, la plupart du temps un bootloader. Mais je ne suis pas fou, je vais pas directement tenter grub… Tentons plus simple, plus utile aussi pour une clé USB : l'EFI shell… (Explications dans un paragraphe, j'ai pas trouvé mieux comme organisation)
Le projet tiano-core, une implémentation libre du cœur d'UEFI, nous fournit ce shell à l'adresse suivante :
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=UEFI_Shell

Mettons ce shell sur la clé USB. Pour cela, je crée un dossier EFI, et je mets dedans le fichier shell.efi…
Mais ça ne marche pas (n'essayez pas).
En effet, il faut mettre un bon nom au fichier. Le fichier de boot, dans le cas d'une clé USB en x86-64, doit être à l'emplacement suivant :
\EFI\boot\bootx64.efi
(Notez l'utilisation de la notation x64 pour parler d'x86-64, que l'on nomme amd64… x64 est la notation de Sun et Microsoft… Et l'anti-slash est de mise en EFI)

Une fois le fichier mis sur la clé, et la machine bootée, on se retrouve dans le grandiose EFI shell !

Le shell EFI

Un conseil : ajoutez immédiatement ce logiciel dans votre trousse à outils pour dépanner des machines. Je ne plaisante pas : il me semble être tout simplement indispensable, pour les futurs EFI buggés, de disposer de cet outil et des quelques utilitaires qu'il propose…

Vous voici maintenant devant un shell à l'invite fort engageante, couleur jaune sur un fond noir :
Shell>

Le premier qui dit que ça ressemble à DOS gagne un cadeau bonux…
Notons tout d'abord la liste des périphériques blocs détectés, affichée en haut de l'écran au lancement du shell. Sur mon PC portable, j'en ai 8 :
- fs0 alias hd22b0d0b (après plusieurs reboot : cet identifiant est dynamique) alias blk0
Chemin complet :
Acpi(PNP0A03,0)/Pci(1D|0)/Usb(1,0)/Usb(3,0)/HD(Part1,Sig64ED66EC-D248-412A-AEEB-B0ECA830E264)
- blk1
Chemin complet :
Acpi(PNP0A03,0)/Pci(1F|2)/Sata(0,0)/HD(Part1,Sig0003AC8C)
- blk2
Chemin complet :
Acpi(PNP0A03,0)/Pci(1F|2)/Sata(0,0)/HD(Part2,Sig0003AC8C)
- blk3
Chemin complet :
Acpi(PNP0A03,0)/Pci(1F|2)/Sata(0,0)
- blk4
Chemin complet :
Acpi(PNP0A03,0)/Pci(1F|2)/Sata(2,0)
- blk5
Chemin complet :
Acpi(PNP0A03,0)/Pci(1D|0)/Usb(1,0)/Usb(3,0)

Ok, facile de deviner : fs0 est la partition 1 de clé USB.
Mais que faire d'autre maintenant…

Je ne m'amuserai plus à recopier tout le résultat des commandes, voici les commandes qui m'ont semblé intéressantes :

help : l'indispensable
drivers : liste l'ensemble des pilotes chargés dans l'UEFI. Comme ça, quand votre clé USB 4 ne fonctionnera pas, vous pourrez charger un pilote USE 4 depuis votre clé USB 3…
devices : liste les périphériques connus, mais c'est moins joli que devtree

Mouais… Pas super fun. Au passage, vous verrez des commandes pour le support de DHCP, d'IPv4... Rien pour IPv6 par contre. Ça c'est l'avenir.

Explorons donc plutôt le système de fichiers.
Vous vous souvenez bien de DOS ? Si oui, c'est facile :
fs0:

Et voilà, vous êtes dans le disque fs0…
Puis vous pouvez utiliser les bonnes vieilles commandes dos type cd, dir (ou ls, ouf !), type (et pas cat)…

Mais passons à plus rigolo : bootons un linux depuis EFI !

efilinux

efilinux est une solution très récente et très simple pour booter un linux depuis EFI.
C'est le lilo d'EFI, en quelque sorte… Il est disponible en paquet debian, et contient principalement le fichier suivant : /usr/lib/efilinux/efilinux.efi

On va donc mettre efilinux.efi sur la clé USB et l'accompagner d'un vmlinuz et de l'initrd correspondant.

On se retrouve donc avec dans fs0:/EFI les fichiers suivants :

boot\bootx64.efi : le shell
vmlinuz-3.1.0-rc7-amd64
initrd-3.1.0-rc7-amd64
efilinux.efi

La méthode de boot est très très simple :

fs0:
cd EFI
efilinux.efi -f 0:\EFI\vmlinuz-3.1.0-rc7-amd64 root=/dev/mapper/asus--laptop-root ro initrd=0:\EFI\initrd-3.1.0-rc7-amd64

Et voilà !
Vous avez booté votre premier noyau avec un système EFI «pur».
Et vous verrez la différence :
dmesg | grep -c -i efi

=> 308
Contre 0 ou 1 auparavant…

Devant la longueur de ce journal, il est urgent d'attendre avant de continuer…

Prochain épisode : je remplace grub par un bootloader UEFI… Puis je code une appli UEFI...

Remerciements

Merci à Asus de rembourser windows sans me priver de ma machine...
Merci à Matthew Garrett pour son magnifique blog et ses grandes explications sur EFI...
Et merci à Debian pour exister...

P.S: je ne peux garantir que tout ceci fonctionne sur une machine Apple, tout simplement parce qu'elles utilisent une solution bâtarde entre EFI et UEFI, avec un comportement souvent différent de ce que l'on voit sur les machines des autres constructeurs.

# Petits oublis

Posté par Pinaraf le 25 octobre 2011 à 01:22. Évalué à 10.

J'ai oublié deux points :

1) pourquoi je voulais faire ça
C'est simple : c'est un exercice intéressant pour découvrir les technologies qui nous sont imposées aujourd'hui, et je souhaitais voir si la couche d'émulation BIOS était à l'origine des problèmes de compatibilité de ma machine (pas d'ASPM, S3 qui plante…)
Malheureusement, c'est pas le cas.

2) microsoft et intel, je ne vous aime pas. Vous forcez la diffusion des technologies buggées, inutilement compliquées…
- [^] # Re: Petits oublis
  
  Posté par Grunt le 25 octobre 2011 à 01:36. Évalué à 4.
  
  Question: est-ce qu'on pourrait espérer au moins un UEFI libre? AMD parlait de proposer des plateformes avec Coreboot, c'en est où?
  
  Vu que l'UEFI devient un truc "gros", c'est un peu comme les firmwares des SSD: le besoin d'en avoir une version libre et librement bidouillable se fait fortement ressentir.
  
  THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
  - [^] # Re: Petits oublis
    
    Posté par Pinaraf le 25 octobre 2011 à 01:39. Évalué à 6.
    
    Coreboot peut utiliser tiano core… Un ensemble core boot + tiano core fait un firmware UEFI.
    
    Quant au support de coreboot par AMD, on manque de nouvelles…
    - [^] # Re: Petits oublis
      
      Posté par Phlogistique le 26 octobre 2011 à 00:55. Évalué à 2.
      
      C'est déjà effectif; et des gens d'AMD poussent fréquemment leurs changements upstream.
# Dépêche !

Posté par Arthur Accroc le 25 octobre 2011 à 07:20. Évalué à 10.

Journal très intéressant. Il ferait une bonne dépêche.

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
- [^] # Re: Dépêche !
  
  Posté par NeoX le 25 octobre 2011 à 07:27. Évalué à 2.
  
  j'allais dire pareil
- [^] # Re: Dépêche !
  
  Posté par barmic le 25 octobre 2011 à 08:41. Évalué à 3.
  
  Tout à fait, je crois que la nouvelle version possède un mécanisme pour passer un journal en dépêche. C'est exactement pour ce genre de journal.
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Interruption logicielle

Posté par Michaël (site web personnel) le 25 octobre 2011 à 08:36. Évalué à 10.

Les interruptions que tu cites sont logicielles (0x10 et 0x13), des interruptions matérielles sont par exemple 0x01 -- 0x07 (CPU generated) puis 0x08 (timer), etc.

Le BIOS est moche, clairement. Très basique, très crade… Mais il faisait son travail, il fournit une abstraction très primitive au matériel. On pouvait presque écrire un OS uniquement en faisant des appels au BIOS, comme DOS…

Je ne vois pas très bien ce qu'il y a de moche et crade dans le BIOS… son travail est de tester l'intégrité de la machine au démarrage, puis de charger le secteur d'amorçage et de lui passer la main… il n'a pas vocation à être aussi sophistiqué ou performant qu'un véritable OS.

À partir de l'éopque du 386, beaucoup de programmes utilisent un DOS-Extender, et à la rigueur, on pourrait presque considérer que le DOS-Extender est le véritable OS sous lequel tourne le programme!

Mais avec l'évolution du matériel, les limites sont apparues : le BIOS utilise un mode 16 bits ne lui permettant pas d'adresser toute la RAM, le boot par le réseau ou par CD est apparu, l'USB est arrivé…

Mon BIOS sait booter sur le réseau, sur un CD, sur une clef USB, et gère les périphériques USB (enfin, le clavier et la souris)… Pour la RAM, la limitation à 20 bits de l'adressage mémoire n'est pas un problème, le but du BIOS est de charger un démarreur d'OS.

Une autre limitation du BIOS est la taille rikiki du secteur d'amorçage: moins de 512 octets pour écrire un véritable boot-loader… c'est peu!

La plupart des boot-loaders sont donc fragmentés, le secteur d'amorçage charge le véritable boot-loader, qu'il s'agise de GRUB, du boot-loader de FreeBSD (un client BTX, BTX est une sorte de mini-noyau à écrire des boot-loader) ou celui de Windows.

Mais de tous ces petits problèmes, il est possible de s'accomoder: ce n'est pas très élégant mais marche et préserve la compatibilité avec le vieux matériel.

Les limitations induites par la table de partition sont véritablement celles qui vont déclencher le changement de norme.

Le premier qui dit que ça ressemble à DOS gagne un cadeau bonux…

Ça ressemble à DOS! :-)
- [^] # Re: Interruption logicielle
  
  Posté par reno le 25 octobre 2011 à 10:34. Évalué à -1.
  
  Je ne vois pas très bien ce qu'il y a de moche et crade dans le BIOS…
  
  Et bien pendant longtemps le BIOS n'était programmable qu'en assembleur, je crois que les développeurs de coreboot ont trouvé une bidouille pour pouvoir le programmer en C.
  - [^] # Re: Interruption logicielle
    
    Posté par Michaël (site web personnel) le 25 octobre 2011 à 10:46. Évalué à 2.
    
    pendant longtemps le BIOS n'était programmable qu'en assembleur
    
    Qu'est-ce que tu veux dire? Qu'il fallait utiliser de l'assembleur pour programmer un BIOS ou pour programmer un client du BIOS? Les deux sont faux, même si dans chaque cas une petite partie du code doit être écrite en langage machine.
    
    Et puis même s'il fallait programmer en assembleur, je ne vois pas trop ce qu'il y a de crade: vu la tâche du BIOS, la portabilité ne fait pas vraiment partie du cahier des charges, et, portabilité mise à part, je ne vois pas vraiment de grosses différences entre le C et le langage machine.
    - [^] # Re: Interruption logicielle
      
      Posté par reno le 25 octobre 2011 à 13:35. Évalué à 2.
      
      portabilité mise à part, je ne vois pas vraiment de grosses différences entre le C et le langage machine.
      
      Tu ne vois vraiment pas? Ou tu fais juste semblant?
      Si tu ne vois vraiment pas, rends toi service et lis No Silver Bullet (ou The Mythical Man-Month) un classique.
      D'après Brooks, le passage du langage machine aux langages de "haut niveau" (Fortran, C) est la seule évolution technique qui a fait gagner un ordre de grandeur au niveau productivité, les autres améliorations étant bien plus marginales.
      - [^] # Re: Interruption logicielle
        
        Posté par Lucky Seven le 25 octobre 2011 à 17:26. Évalué à 3.
        
        Seulement, dans le cadre d'un bootloader il ne s'agit pas de gagner en productivité.
        Et la partie du bootloader qui est écrite sur le secteur d'amorçage est obligatoirement écrite en assembleur, du moins c'est préférable ...
        
        [^] # Re: Interruption logicielle
        
        Posté par barmic le 13 novembre 2011 à 00:13. Évalué à 1.
        
        Seulement, dans le cadre d'un bootloader il ne s'agit pas de gagner en productivité.
        
        Vraiment ? Tu pense que chaque constructeur ne propose qu'une seule carte mère et qu'il ne fait aucun support après vente de leur carte mère (même pour gagner 3 points sur le dernier benchmark à la mode parce que le concurent en a 1 de plus) ? Il n'y a jamais de bug dans un bios ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Interruption logicielle
        
        Posté par Lucky Seven le 15 novembre 2011 à 14:02. Évalué à 0.
        
        Ce n'est pas le constructeur qui fourni le bootloader.
        
        Le bootloader n'a rien avoir avec les perfs, une fois qu'il a lancé l'OS il n'a plus aucun rôle...
        
        Le bootloader ce n'est pas le bios. Je parle bien de bootloader, pas de bios !
  - [^] # Re: Interruption logicielle
    
    Posté par Phlogistique le 26 octobre 2011 à 01:04. Évalué à 10.
    
    Pour être exact:
    
    Tant que la RAM n'est pas initialisée, on ne peut pas stocker de stack, donc on ne peut pas appeller de fonctions! Le code produit par GCC ne peut donc pas être utilisé.
    
    Pour règler ce problème, deux solutions sont en places:
    - Les développeurs de Coreboot ont développé un compilateur C qui inline absolument tout, de façon à pouvoir être utilisé sans mémoire. Ça s'appelle ROMCC, c'est relativement bugué mais ça a le mérite d'exister. Cette solution est sur la voix de l'abandon en faveur de la seconde solution.
    - Les processeurs modernes permettent d'utiliser du "Cache-As-RAM" (CAR), c'est à dire d'utiliser le cache du processeur comme mémoire en attendant d'avoir initialisé la RAM. Il n'y a donc que le code pré-CAR et l'initialisation du CAR qui doivent être codés en assembleur; une fois que l'on peut utiliser le CAR, on peut avoir une stack et donc faire tourner du code généré par GCC.
- [^] # Re: Interruption logicielle
  
  Posté par Pinaraf le 25 octobre 2011 à 11:41. Évalué à 6.
  
  Merci pour la correction sur les interruptions.
  La "laideur" du bios, c'est le fait qu'il n'ait jamais ete documente/normalise et donc que personne ne soit sur a 100% qu'une appli soit un bios fonctionnel ou non.
  Apres, les solutions pour le boot sur cd notamment sont rarement elegantes... PAr exemple il y a peu, je suis tombe sur un bios buggue utilisant par erreur l'emulation d'un lecteur de disquette pour la cle usb, rendant le boot impossible... Il a fallu triturer le bios pour le forcer a emuler un disque dur a la place...
  
  P.S : desole pour les accents, le clavier qwerty du N950 ne les permet pas...
  - [^] # Re: Interruption logicielle
    
    Posté par dr_home le 25 octobre 2011 à 13:03. Évalué à 1.
    
    C'était pas un BIOS Phoenix, par hasard ? j'ai eu le même soucis sur une machine headless. La solution a été de bidouiller la clé en formatant directement le périphérique maître (sans partitionner, donc).
  - [^] # Re: Interruption logicielle
    
    Posté par Michaël (site web personnel) le 12 novembre 2011 à 20:51. Évalué à 2.
    
    P.S : desole pour les accents, le clavier qwerty du N950 ne les permet pas...
    
    J'utilise aussi un clavier qwerty… on n'est pas sous windows et tu peux configurer une touche compose pour saisir les accents. Tu peux faire ce réglage dans le fichier xorg.conf mais certains desktop (notamment KDE) te permettent de le configurer depuis leur outil de configuration. Tu trouveras facilement plus de détails à ce sujet sur le net.
- [^] # Re: Interruption logicielle
  
  Posté par téthis le 25 octobre 2011 à 12:59. Évalué à 1.
  
  Une autre limitation du BIOS est la taille rikiki du secteur d'amorçage: moins de 512 octets pour écrire un véritable boot-loader… c'est peu!
  
  Limitation détournée depuis longtemps puisque le secteur 0 sert principalement à charger en mémoire le vrai bootloader qui est situé ailleurs sur un nombre plus important de secteurs. C'est un peu crade mais l'étape de démarrage d'un OS n'a jamais été très propre, même avec 510 octets (2 octets pour la signature du boot sector).
  
  The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
  - [^] # Re: Interruption logicielle
    
    Posté par oinkoink_daotter le 25 octobre 2011 à 13:23. Évalué à 3.
    
    440, même, si l'on exclut la table de partition et deux trois autres trucs ...
  - [^] # Re: Interruption logicielle
    
    Posté par Michaël (site web personnel) le 25 octobre 2011 à 19:01. Évalué à 3.
    
    > Une autre limitation du BIOS est la taille rikiki du secteur d'amorçage: moins de 512 octets pour écrire un véritable boot-loader… c'est peu!
    
    Limitation détournée depuis longtemps puisque le secteur 0 sert principalement à charger en mémoire le vrai bootloader qui est situé ailleurs sur un nombre plus important de secteurs.
    
    C'est ce que j'ai écrit une ligne plus bas (!):
    
    > La plupart des boot-loaders sont donc fragmentés, le secteur d'amorçage charge le véritable boot-loader, qu'il s'agise de GRUB, du boot-loader de FreeBSD (un client BTX, BTX est une sorte de mini-noyau à écrire des boot-loader) ou celui de Windows.
    
    > Mais de tous ces petits problèmes, il est possible de s'accomoder: ce n'est pas très élégant mais marche et préserve la compatibilité avec le vieux matériel.
# GNU GRUB, installation, choix de démarrage

Posté par 🚲 Tanguy Ortolo (site web personnel) le 25 octobre 2011 à 08:49. Évalué à 4.
Pour le démarrage, UEFI fournit surtout un gestionnaire de démarrage, qui permet de choisir quoi démarrer : le système qui est sur la clef USB, Debian GNU/Linux sur le premier disque dur, ou Windows 7 sur ce même disque dur ?

Contrairement au BIOS, ce gestionnaire de démarrage est configurable depuis le système d'exploitation lui-même. Il est par ailleurs capable de démarrer un fichier arbitraire sur une « partition UEFI », c'est à dire une partition portant un type spécifique et utilisant un système de fichiers qu'il sait lire, le plus souvent une FAT.

GNU GRUB prend en charge le démarrage UEFI, et est conçu pour utiliser le schéma suivant :
- la partition UEFI doit être montée sur /boot/efi ;
- GNU GRUB est installé dans /boot/grub ;
- l'image générée par GRUB, qui, comme sur BIOS, contient seulement de quoi lire /boot/grub pour y charger modules et configuration, est placée dans /boot/efi/efi/DISTRO/grubARCH.efi, ce qui donne chez moi /boot/efi/efi/debian/grubx64.efi ;
- le gestionnaire de démarrage est configuré pour avoir une entrée DISTRO correspondant à ce fichier de GRUB.
Tout cela est pris en charge par l'installateur Debian, par exemple, à condition de l'avoir lui-même démarré en EFI évidemment.
- [^] # Re: GNU GRUB, installation, choix de démarrage
  
  Posté par Pinaraf le 25 octobre 2011 à 09:22. Évalué à 10.
  
  Hey, spoiler alert, comment je fais mon prochain journal maintenant ?
- [^] # Re: GNU GRUB, installation, choix de démarrage
  
  Posté par 🚲 Tanguy Ortolo (site web personnel) le 25 octobre 2011 à 09:53. Évalué à 5.
  
  Moinssez-moi s'il vous plaît, il paraît que je viens en fait de dévoiler le prochain épisode.
- [^] # Re: GNU GRUB, installation, choix de démarrage
  
  Posté par Elfir3 le 25 octobre 2011 à 10:08. Évalué à 2.
  
  En tout cas, merci. J'ai été obligé de lire le journal entre les lignes (fatigue, toussa) et tu as réussi à m'éclairer sur un point. A quoi sert un (U)EFI.
  - [^] # Re: GNU GRUB, installation, choix de démarrage
    
    Posté par 🚲 Tanguy Ortolo (site web personnel) le 25 octobre 2011 à 10:10. Évalué à 3.
    
    Non, le processus de démarrage c'est seulement la partie la plus visible. Le reste, c'est toute l'ABI d'appels que le chargeur de démarrage utilise pour communiquer avec le matériel, par l'intermédiaire de pilotes UEFI d'ailleurs. Les systèmes d'exploitation aussi peuvent faire des appels UEFI, mais généralement il n'utilisent pas cette possibilité pour des raisons de portabilité.
# Apple EFI

Posté par madhatter (site web personnel) le 25 octobre 2011 à 09:19. Évalué à 4.

je ne peux garantir que tout ceci fonctionne sur une machine Apple, tout simplement parce qu'elles utilisent une solution bâtarde entre EFI et UEFI, avec un comportement souvent différent de ce que l'on voit sur les machines des autres constructeurs.

Effectivement. C'est merdique.

J'ai trituré le truc dans tous les sens cet été, sans succès probant.
Au départ j'avais MacOS + Linux et le boot était géré par rEFIt, derrière lequel GRUB en mode PC BIOS était lancé.
Ne l'utilisant pas, l'objectif était de virer MacOS et d'en profité pour supprimer rEFIt, pour ne laisser que GRUB.
J'ai réussi à mettre GRUB en mode EFI, mais j'avais un soucis de driver graphique sous Nux (mappage des couleurs incorrect).
Au final, je suis revenu à une solution un poil batarde mais qui fonctionne : j'ai mis le EFI du Mac en mode legacy (émulation de BIOS) et j'ai installé Grub en mode PC dans le MBR du disque (ou de la partition BIOS, je ne sais plus). Le disque est en GPT, puisque ça ne pose aucun problème à Linux ou à GRUB, et contient une partition "bios" de 100Mo au début du disque, le reste en LVM.

D'ailleurs à ce propos, sache que GRUB 2 gère très bien le boot sur du LVM, donc plus besoin de sortir le /boot du LVM ;).
Bon par contre aux dernières nouvelles, l'installeur Debian a un peu de mal à l'installer dans cette configuration (tout dans un VG LVM) donc il faut choper un terminal lors de l'installation, chrooter le target et faire l'installation à la mano - mais c'est juste un grub-install et un update-grub, donc c'est pas non plus infaisable. :)

There is no spoon...
# secure boot ?

Posté par jinbeman le 25 octobre 2011 à 20:32. Évalué à 1.

Vu que je ne connais rien à ce sujet ma question est certainement très naïve mais je tente :
Est-ce que le shell EFI peut permettre de désactiver un secure boot, notamment dans le cas où le constructeur ne prévoit pas cette possibilité dans son interface type "émulation du bios" ?

Au cas où certaines personnes n'auraient pas suivi l'histoire (en anglais) :
http://mjg59.dreamwidth.org/5552.html
http://mjg59.dreamwidth.org/5848.html
- [^] # Re: secure boot ?
  
  Posté par Pinaraf le 26 octobre 2011 à 01:01. Évalué à 5.
  
  Non, vu qu'avec Secure boot, tu pourrais même pas lancer le shell EFI, à moins d'avoir un shell EFI signé avec une clé présente dans ton EFI…

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.