Posté par gUI (Mastodon) .
En réponse au message liveusb : EFI/ESP.
É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 gUI (Mastodon) . En réponse au message liveusb : EFI/ESP. Évalué à 9. Dernière modification le 23 août 2020 à 15:53.
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.
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:(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/sdb1par 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 :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.