Vous n'êtes pas identifié(e).
Dernière modification par G_ (11-01-2019 14:56:38)
Hors ligne
Dernière modification par Lupa (06-01-2019 06:57:53)
Hors ligne
Hors ligne
une clé usb créée par: https://debian-facile.org/doc:install:usb-boot.
Avec quelle méthode ? Cette page en décrit plusieurs, aux résultats différents.
si je met en legacy, au démarrage sur la clé j'ai le message isolinux.bin is missing.
Donc la clé démarre bien en mode legacy mais apparemment l'amorce d'ISOLinux ne trouve pas la suite. La clé pourrait ne pas avoir été bien préparée. Ou bien le firmware du PC est buggé.
Si je met en UEFI avec secure boot activé ou désactivé, la cle usb n'est pas vue au démarrage
Il faut désactiver le secure boot. Cette image ISO est amorçable en UEFI 64 bits. Donc à moins que le firmware UEFI (et donc Windows) soit 32 bits, elle devrait être reconnue en mode EFI si elle a été préparée correctement.
Les disques durs des machines préinstallées, depuis Win8, sont systématiquement partitionnées GPT, ce qui active l'EFI du BIOS.
Non, GPT n'active pas systématiquement l'amorçage en mode EFI. De toute façon le format du disque interne n'a aucune influence sur l'amorçage d'un support amovible.
Par contre pour avoir le dual boot dans GRUB il faudra amorcer l'installateur dans le même mode que Windows, qui est lié au format de table de partition (mais seulement pour Windows) : EFI = GPT et BIOS = DOS/MBR. Sinon il faudra gérer le multi-boot via le firmware.
Je ne pense pas que GParted ait une fonction pour convertir un dd GPT en MBR.
En conservant les partitions ? gdisk peut le faire, s'il n'y a pas plus de 4 partitions à conserver. Mais ça n'a pas grand intérêt puisque Windows ne pourra plus démarrer.
Il vaut mieux montrer que raconter.
Hors ligne
Avec quelle méthode ? Cette page en décrit plusieurs, aux résultats différents.
avec cette commande: dd if=image.iso of=/dev/sdx bs=4M status=progress && sync, le résultat, la clé, aurait était différent avec une autre méthode?
Donc la clé démarre bien en mode legacy mais apparemment l'amorce d'ISOLinux ne trouve pas la suite. La clé pourrait ne pas avoir été bien préparée. Ou bien le firmware du PC est buggé.
Sur mon pc fixe, au démarrage, j'ai le choix entre usb legacy et usb uefi, usb uefi fonctionne bien. J'ai l'impression que l'image debian-live-9.6.0-amd64-xfce.iso ne peut pas être utilisée en legacy.
Il faut désactiver le secure boot. Cette image ISO est amorçable en UEFI 64 bits. Donc à moins que le firmware UEFI (et donc Windows) soit 32 bits, elle devrait être reconnue en mode EFI si elle a été préparée correctement.
En uefi et avec le secure boot désactivé, la clé n'est pas vue au démarrage. Le pc portable est neuf, donc 64 bits.
Hors ligne
La première commande devrait afficher
La seconde devrait afficher que la fin du fichier image a été atteinte, donc aucune différence trouvée avant.
Normalement les images -amd64 image sont bootables sur clé USB en mode legacy et EFI 64 bits. Elle a un format un peu particulier à la limite des standards pour booter sur un maximum de machines, ça ne plaît peut-être pas à certains firmwares.
Il ne faut pas confondre le matériel et le firmware. Une machine 64 bits peut avoir un firmware UEFI 32 bits (pour être compatible avec Windows 32 bits), je l'ai vu sur quelques netbooks et mini-PC tablettes.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Que se passe-t-il en mode legacy sur le PC fixe ?
Sur le pc fixe (un Dell) en legacy, c'est la même erreur, isolinux.bin is missing.
Hors ligne
Dernière modification par Beta-Pictoris (06-01-2019 16:03:15)
Hors ligne
Dernière modification par raleur (06-01-2019 16:19:06)
Il vaut mieux montrer que raconter.
Hors ligne
Eventuellement une autre image, comme l'image de CD d'installation par le réseau (netinst) qui n'est pas très grosse.
, j'écrivais le message au moment raleur postait).
J'ai rencontré un problème avec les images debian-live (autant jessie que buster): ils manquent le répertoire EFI donc il faut le créer pour que le firmware UEFI trouve l'exécutable *.efi.
Deux options:
A) On peut modifier l'image ISO, ajouter le répertoire EFI dans sa racine , le sous répertoire boot dans EFI, et sous /EFI/boot y placer le fichier bootx64.efi (j'ai utilisé celui-ci provenant d'une ISO netinst)
Ça peut être fait avec un logiciel graphique tel que ISOmaster, par exemple, ou bien en montant les images par lignes de commandes, le résultat c'est le même.
B) Ou bien formater la clé en fat32 par exemple, extraire le contenu de l'ISO live dedans, et comme fait dans le cas de l'image ISO, ajouter le répertoire EFI dans sa racine , le sous répertoire boot dans EFI, et sous /EFI/boot y placer le fichier bootx64.efi (j'ai utilisé celui-ci provenant d'une ISO netinst) Dans ce cas la clé ne pourra amorcer que en mode UEFI.
Salut
Dernière modification par empanada (06-01-2019 17:13:12)
"blues are the roots and the other musics are the fruits" . Willie Dixon
Hors ligne
Dernière modification par Beta-Pictoris (06-01-2019 17:31:13)
Hors ligne
Je viens de vérifier, le fichier "/efi/boot/bootx64.efi" existe bien dans la partition vfat de l'image Debian-live-9.6.0-amd64-xfce.
Merci. Quand même dans ces deux images que j'ai:
debian-live-9.5.0-amd64-lxde.iso
debian-live-buster-amd64-lxde.iso
elles n'ont pas le répertoire EFI ni efi. Peut-être un bug seulement des images lxde?
Dernière modification par empanada (06-01-2019 17:37:57)
"blues are the roots and the other musics are the fruits" . Willie Dixon
Hors ligne
J'ai rencontré un problème avec les images debian-live (autant jessie que buster): ils manquent le répertoire EFI
Les images live de Jessie n'étaient pas amorçables en EFI. Par contre les images live de Stretch le sont, et je ne vois pas pourquoi celles de Buster ne le seraient pas (si elles existent déjà). Au passage, le boot EFI n'a pas besoin d'un répertoire EFI dans le système de fichiers ISO 9660 mais dans une partition système EFI.
tu pourrais aller dans l'explorateur de partition esp du menu de boot
Je ne voudrais pas passer pour un rabat-joie, mais d'après mon expérience, l'existence de cette fonctionnalité est plus une exception que la règle. Je crois que je ne l'ai jamais vu que sur des machines HP.
Dernière modification par raleur (06-01-2019 17:39:45)
Il vaut mieux montrer que raconter.
Hors ligne
Au passage, le boot EFI n'a pas besoin d'un répertoire EFI dans le système de fichiers ISO 9660 mais dans une partition système EFI.
Je sais...mais dans certains cas (le dernier je l'ai à coté dans ce moment là(un Lenovo MIIX320)), le firmware UEFI a besoin de ce répertoire sur la racine de la clé USB : clé avec netinstall (qui a par défaut ce fichier efi/boot/bootx64.efi) amorce sans problème, les images citées plus haut, non...mais si on ajoute le fichier dans le même chemin que sur la netinstall...hop: elles démarrent parfaitement, donc,il parait une des ces conneries dans les firmwares UEFI, en dehors des spécifications , mais quand même elle doit être très courante pour que les développeurs ont mis ce fichier sur les images des installateurs debian stable.
Donc, dans ce phrase:
J'ai rencontré un problème avec les images debian-live (autant jessie que buster): ils manquent le répertoire EFI donc il faut le créer pour que le firmware UEFI trouve l'exécutable *.efi.
il serait plus correct ajouter "certains firmware et":
J'ai rencontré un problème avec certains firmware et les images debian-live (autant jessie que buster): ils manquent le répertoire EFI donc il faut le créer pour que le firmware UEFI trouve l'exécutable *.efi.
"blues are the roots and the other musics are the fruits" . Willie Dixon
Hors ligne
Hors ligne
le firmware UEFI a besoin de ce répertoire sur la racine de la clé USB
Une clé USB n'a pas de racine. Un système de fichiers a une racine. De quel système de fichiers parles-tu ? FAT de la partition EFI ou ISO 9660 ? Je doute fort qu'aucun firmware UEFI cherche à lire un système de fichiers ISO 9660 sur une clé USB.
Il vaut mieux montrer que raconter.
Hors ligne
Autre clé usb: même résultat.
iso netinst avec /efi/boot/bootx64.efi présent: même résultat.
Oui, mais crée avec dd aussi, non? J'ai oublié spécifier que dans l'ordinateur dont j'ai parlé plus haut, il n'amorce aucune clé avec format iso9660 , il faut formater la clé en fat32 et extraire le contenu des iso's dedans, et si elles n'ont pas le fichier bootx64.efi, le placer dans le chemin correct (efi/boot)
"blues are the roots and the other musics are the fruits" . Willie Dixon
Hors ligne
empanada a écrit :le firmware UEFI a besoin de ce répertoire sur la racine de la clé USB
Une clé USB n'a pas de racine. Un système de fichiers a une racine. De quel système de fichiers parles-tu ? FAT de la partition EFI ou ISO 9660 ? Je doute fort qu'aucun firmware UEFI cherche à lire un système de fichiers ISO 9660 sur une clé USB.
Oui, pas bien explicité:
le firmware UEFI a besoin de ce répertoire sur la racine du système de fichiers fat32 de la clé USB
"blues are the roots and the other musics are the fruits" . Willie Dixon
Hors ligne
Dernière modification par raleur (06-01-2019 18:42:00)
Il vaut mieux montrer que raconter.
Hors ligne
Forcément, si tu ne dis pas tout...
Question pour la peine : tu formates la clé entière sans table de partition, ou une partition ?
Une partition.
"blues are the roots and the other musics are the fruits" . Willie Dixon
Hors ligne
Oui, mais crée avec dd aussi, non?
oui avec dd, de quelle autre méthode parles-tu, cp?
Avec Jessie: même résultat.
Hors ligne
Je doute fort qu'aucun firmware UEFI cherche à lire un système de fichiers ISO 9660 sur une clé USB.
Je suppose que tu fais référence à que le firmware UEFI ne cherche pas des répertoires EFI sous des systèmes iso9660, non? Parce que la plupart des UEFI's sont capables d'amorcer les clés crées avec dd à partir des images iso9660 (ce n'est pas les cas de cet exemple Lenovo MIIX320)
Salut
"blues are the roots and the other musics are the fruits" . Willie Dixon
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne