Forum Linux.général liveusb : EFI/ESP

Posté par  (Mastodon) . Licence CC By‑SA.
Étiquettes :
0
22
août
2020

bonsoir Audience,

j'ai formaté la clé en GPT
j'ai crée deux partitions une fat32 que j'ai mis sous label esp-boot, avec les fichiers efi de l'iso nux
une autre partition vide
j'ai fait un dd d'une iso mint vers la paritition numéro 2
il me crée la liveusb
je prends la clé, en boot efi sur pc hp : ca démarre nickel
je fais pareil sur un netbook samsung en démarrage usb : il plante au moment de détecter la clé (écran noir)
je fais pareil sur pc portable lenovo haut de gamme : il voit pas la clé dans les périfs bootables, sauf dans l'interface efi

question : y a t-il, en plus de la partition fat32 à labelliser esp, avec les fichiers efi, mettre l'image sur la partoche n2, un truc à faire que j'ai oublié?

l'idée c'est de faire la meme chose que rufus sous windows, qui utilise ISO au lieu de DD, en activant un ESP complémentaire pour rendre compatible EFI classe 3 (pur) mais en passant sous linux par dd donc sans rufus. Cependant, je tiens à souligner que l'utilitaire unetbootin ne voit aucune de mes clés usb, et ne propose pas d'option esp/efi.
Je ne souhaite pas utiliser le CSM/legacy abandonné ya des années.

edit: j'ai également tenté avec Etcher, meme constat : pas de création ESP ajoutée lors de la création du liveusb.

  • # Sans partition

    Posté par  (site web personnel) . Évalué à 3.

    Pourquoi tu ne fais pas directement un DD de l'iso vers la clé USB, sans partitionner? Du genre:

    dd if="mint.iso" of="/dev/sdc"
    

    Tu ne pourras alors rien mettre d'autre sur ta clé, mais ça devrait marcher.

    Un LUG en Lorraine : https://enunclic-cappel.fr

    • [^] # Re: Sans partition

      Posté par  (Mastodon) . Évalué à -1.

      j'ai déjà utilisé dd
      sauf que dd applique bêtement le contenu de l'iso vers la clé sur une seule partition
      Or, un efi, pour démarrer en mode efi, exige une partition fat32 appelée ESP, sur laquelle sont entreposée les fichiers .efi
      Or, dd n'intègre à priori pas de fonctionnalité pour gérer la création d'un esp sur clé usb à destination d'ordinateurs efi classe 3 (càd pur efi, sans csm/legacy, comme les nouveaux intel), de même que etcher ou unetbootin qui ne le prennent pas en compte.
      Cependant rufus sous windows le fait facilement.
      je cherchais un utilitaire, une procédure simple, pour que l'esp soit crée par un utilitaire dans les règles de l'art. Et j'en vois pas. Surprenant pour linux en 2020, mais peut être que quelqu'un a une réponse.

      • [^] # C’est déjà dans le pot (normalement)

        Posté par  . Évalué à 5.

        sauf que dd applique bêtement le contenu de l'iso vers la clé sur une seule partition
        Or, un efi, pour démarrer en mode efi, exige une partition fat32 appelée ESP, sur laquelle sont entreposée les fichiers .efi

        Oui, mais de nos jours, les distributions grand public en ont généralement déjà mis une dans l’ISO, en prévision d’une utilisation sur clé USB.

        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

        • [^] # Re: C’est déjà dans le pot (normalement)

          Posté par  (Mastodon) . Évalué à 0.

          les dossiers sont dans l'iso oui
          sur clé usb, meme en créant à la main une partition fat32 avec esp-boot sur gparted, mon lenovo ni mon samsung ne parviennent à démarrer dessus.
          pourtant avec rufus ca passe. et je voulais m'affranchir de retourner sous windows pour créer ce genre de manipulation

  • # URL

    Posté par  (Mastodon) . Évalué à 3.

    Tu peux envoyer l'URL de l'ISO que tu essaies de flasher ?

    Ce sera plus facile pour te dire quoi faire.

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: URL

      Posté par  (Mastodon) . Évalué à 1.

      mint 18 cinammon 64
      très étonnant pour uen distro récente
      mais je n'arrive pas à comprendre en quoi dd parvient à écrire un ESP..

      • [^] # Re: URL

        Posté par  (Mastodon) . Évalué à 9. Dernière modification le 23 août 2020 à 15:53.

        très étonnant pour uen distro récente

        Bon, elle date tout de même de 2016, mais elle est basée sur Ubuntu 16.04 qui gérait déjà l'UEFI donc ça va.

        mais je n'arrive pas à comprendre en quoi dd parvient à écrire un ESP

        Je viens de le faire et spoiler : ça marche très bien, mon UEFI peut booter la clé USB en mode UEFI ou en mode legacy (les 2 marchent).

        J'ai bien eu ma partition EFI. Si je fais un fdisk /dev/sdb :

        Périphérique Amorçage Début     Fin Secteurs Taille Id Type
        /dev/sdb1    *            0 3316223  3316224   1,6G  0 Vide
        /dev/sdb2             87152   91887     4736   2,3M ef EFI (FAT-12/16/32)
        

        (alors bon c'est un peu chelou puisque les partitions se chevauchent, mais je soupçonne une astuce pour que ça marche à la fois sur disque et sur CDROM)

        Je vais t'expliquer comment marche dd, c'est très con, mais alors là très con, et tu réfléchis bcp trop en fait :)

        Il faut bien comprendre que la clé USB contient des octets, et c'est tout. Il n'y a rien d'autre que une suite de 4 milliards d'octets (pour ma clé de 4Go). Dans ces octets (au début en fait), il y a une table de partition, c'est à dire la description du partitionnement. Par exemple on voit sur la sortie de fdisk l'information "du secteur 87152 au secteur 91887 c'est une partition de type EFI" (un secteur étant un bloc de 512 octets, il suffit de multiplier par 512 pour avoir une adresse en octet).

        Mais il faut bien comprendre que ces informations sont dans les 4Go, au même titre que les partitions elle-même et les fichiers qui y seront.

        Arrive dd : lui, il ne s'occupe que d'octets. Il va du premier au dernier, et c'est tout. Il n'interprète rien, il ne sait même pas si il copie un fichier, une partition entière ou une table de partitions. Il copie, c'est tout. Du premier au dernier octet, comme un gros bourrin.

        Chez moi la clé USB est en sdb, du coup j'ai tapé : dd if=linuxmint.iso of=/dev/sdb bs=1M (le bs=1M est juste là pour accélérer un peu les choses, il copie méga par méga au lieu de octet par octet mais ça ne change rien à l'histoire). ATTENTION, c'est bien /dev/sdb (qui est le bloc, c'est à dire ma clé USB depuis le début, depuis le tout premier octet) et pas /dev/sdb1 par exemple (qui est la première partition, c'est à dire à partir du Nième octet, selon ce qui est décrit dans la table de partitions). Donc en faisant ça, si mon fichier source contient lui-même une table de partitions, je vais copier la table de partition ainsi que les partitions elle-même, bref tout le contenu du disque.

        Et ô magie, si je regarde mon fichier ISO avec fdisk, je trouve la même chose :

        Périphérique                     Amorçage Début     Fin Secteurs Taille Id Type
        linuxmint-18-cinnamon-64bit.iso1 *            0 3316223  3316224   1,6G  0 Vide
        linuxmint-18-cinnamon-64bit.iso2          87152   91887     4736   2,3M ef EFI (FAT-12/16/32)
        

        On a donc bien affaire à une image ISO qui est destinée à être copié en intégralité, octet par octet, sur un disque (clé USB ou disque dur peu importe) et qui contient un partitionnement complet, dont une partition EFI.

        CQFD :)

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: URL

          Posté par  (Mastodon) . Évalué à 3. Dernière modification le 24 août 2020 à 22:23.

          Tu n'as pas répondu, tu y es arrivé finalement ?

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # Ventoy

    Posté par  . Évalué à 6.

    J'ai découvert Ventoy sur le tard. Qu'est-ce que je ratais !

    Le principe : tu installes Ventoy sur ta clé, tu copies toutes les ISOs que tu veux dessus, et au boot sur la clé, Ventoy te présente un menu dans lequel tu retrouves ces ISOs, et yapuka !

    C'est la version 100% soft et plus souple de ce que proposent certains boîtiers de disque externe Zalman comme le ZM-VE350.

    • [^] # Re: Ventoy

      Posté par  . Évalué à 2.

      Il existe l'utilitaire Multisystem depuis longtemps. C'est moins versatile mais plus mature et suffisant pour les distros Linux les plus communes.

      • [^] # Re: Ventoy

        Posté par  (site web personnel) . Évalué à 3.

        J'utilise aussi Multisystem, mais ce que je n'aime pas c'est qu'il modifie le menu de démarrage des iso. Par exemple pour Mint/Ubuntu, on n'a plus le choix du langage au démarrage, ou les options "rescue", etc.

        Je ne sais pas si c'est lié, mais j'ai également des soucis pour les iso qui ne sont pas live (Debian netInstall, ou les iso Debian classiques). Ça déconne à un moment quand apt cherche à récupérer plus de paquets depuis le disque de démarrage.

        Un LUG en Lorraine : https://enunclic-cappel.fr

        • [^] # Re: Ventoy

          Posté par  . Évalué à 2.

          Je l'utilise uniquement pour du liveUSB de secours et des utilitaires admin/réparation, j'utilise plutôt unetbootin ou etcher pour les installeurs ou màj firmware.

  • # Boot uefi

    Posté par  . Évalué à 3.

    Pour ma part quand je prépare un boot défi, je fait un dd if=gptmbr.bin of=sda, gptmbr.bin est fournit par syslinux.
    Ensuite, je fais les partitions et je modifie l UUID pour rendre boobtable, il faut un UUID spécifique (trouvable par example sur le wiki archlinux).
    Je ne mets pas les liens, étant sur tablette…

    Le wiki archlinux pour syslinux détaille bien ce qu' il faut faire, y compris dans le cas où les manipulations ne sont pas faites à partir d un boot sous uefi.

Suivre le flux des commentaires

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