Ecran noir lors de l'installation clé USB Debian 9

clé-usb
stretch
installation
Tags: #<Tag:0x00007f0944d360e0> #<Tag:0x00007f0944d35e10> #<Tag:0x00007f0944d35a28>

#21

Le problème n’est pas l’amorçage de l’installateur, mais ce qui se passe après le chargement du noyau.
D’autre part, comment lancerais-tu DOS sur une machine UEFI ?


#22

j’ai toujours utilisé DOS depuis Windows


#23

Il n’y a plus de DOS dans Windows dans la famille NT (incluant 2000, XP et toutes les versions ultérieures).
On confond souvent l’interpréteur de commande cmd.exe de Windows avec l’interpréteur de commande command.com de DOS, et cet interpréteur avec DOS lui-même alors qu’il n’en est qu’un des composants. Mais à part une partie des commandes communes, ils n’ont pas grand-chose à voir.

Le manuel d’installation précise bien que loadlin doit être lancé depuis DOS, pas depuis Windows. Windows tourne en mode protégé et ne laissera pas loadlin charger un noyau Linux. Quant à win32-loader.exe, si je ne m’abuse il ne fait que préparer le système pour amorcer l’installateur Debian au redémarrage, ce qui n’avancerait à rien. D’autre part la dernière fois que j’ai regardé il ne fonctionnait pas avec l’amorçage EFI.


#24

J’ai essayé d’installer debian avec debian-installer-launcher depuis une clé live cinnamon.
debian-installer-launcher n’étant pas sur la clé, je l’ai installé avec synaptic en mode live (donc je ne sais pas où il l’installe et je dois refaire la manip à chaque fois puisque ce n’est pas conservé).

Après l’avoir lancé en root j’ai le message suivant :

no suitable d-i initrd image found, aborting.
umount: /lib/live/installer: not found

Je ne sais absolument pas quels paramètres je dois rajouter. Une idée ?

Merci d’avance.


#25

Une image ISO étant en lecture seule, les modifications dans un système live sont en mémoire volatile et ne sont donc pas conservées, sauf si le système live utilise une forme de persistance.

Je n’avais jamais utilisé d’image Debian live ni debian-installer-launcher. Apparemment l’erreur est due à un changement dans l’arborescence de l’image live qui n’a pas été répercuté dans debian-installer-launcher. J’ai testé avec l’image live 9.6 qui est la version stable actuellement disponible, mais je suppose que c’est pareil avec avec la version 9.5.

debian-installer-launcher recherche un initrd de l’installateur dans /install alors qu’elles sont dans /d-i dans l’image live. Il faut donc éditer le fichier /usr/share/debian-installer-launcher/plugins/live (en root via sudo) et remplacer les deux occurrence de “install” dans la ligne 60 par “d-i” :

for IMAGE in /lib/live/mount/medium/install/gtk/initrd.gz /lib/live/mount/medium/install/initrd.gz; do

doit être modifiée en

for IMAGE in /lib/live/mount/medium/d-i/gtk/initrd.gz /lib/live/mount/medium/d-i/initrd.gz; do

Ensuite debian-installer-launcher se lance bien, j’ai pu aller jusqu’à l’étape de partitionnement, puis j’ai annulé.


#26

Je viens d’essayer d’installer debian avec debian-live-9.6.0-amd64-cinnamon.iso.

J’ai réinstallé debian-installer-launcher et modifié le fichier live comme indiqué.

J’ai maintenant le message suivant :

root@debian:/usr/share/debian-installer-launcher/plugins# debian-installer-launcher 
Loading debian-installer...
Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling StartServiceByName for org.gnome.Terminal: Timeout was reached

Que faire ?


#27

J’ai finalement pu lancer debian-installer-launcher avec sudo. Je vous tiens au courant dès que l’installation sera faite.


#28

J’ai pu réaliser l’installation avec debian-installer-launcher. J’ai eu un message concernant des firmware manquants mais cela n’a pas bloqué la procédure d’installation. Mais lorsque j’ai voulu rebooter après avoir réactivé le secure boot et renseigné le fichier EFI à utiliser (grubx64.efi de debian), j’ai une erreur :

error: Secure Boot forbids loading module from (hd0, gpt2)/boot/grub/x86_64-efi/normal.mod
…
Entering rescue mode...

J’ai trouvé un post concernant un grub bloqué mais ne sais pas comment appliquer les conseils.

La commande set me donne le résultat suivant :

cmdpath=(hd0,gpt1)/EFI/debian
prefix=(hd0,gpt2)/boot/grub
root=hd0,gpt2

Pour info, lorsque j’ai choisi le fichier EFI au redémarrage, j’ai trouvé plusieurs fichiers EFI répartis dans les sous-répertoires ubuntu, boot et debian.

Quelle commande dois-je lancer ?

Merci d’avance pour votre aide.


#29

Pourquoi avoir réactivé le secure boot ? Debian Stretch ne le supporte pas.
Même si tu déclares grubx64.efi dans le firmware UEFI, les modules de GRUB ne sont pas signés et GRUB EFI refuse de les charger s’il détecte que le secure boot est activé.


#30

En fait, au départ je n’avais pas réactivé le mode Secure Boot. Lorsque j’ai rebooté j’ai eu un écran noir avec le message “No Bootable Device”.
J’ai donc réactivé le mode Secure Boot et indiqué le fichier EFI à utiliser.

Suite à votre mail, j’ai essayé de redémarrer après restauré les paramètres d’usine par défaut puis désactivé le mode Secure Boot : j’ai toujours le même message “No Bootable Device”.


#31

Quand je dis et redis que l’UEFI, c’est merdique…
Il n’y a même pas le GRUB d’Ubuntu qui démarre ?

Il faudrait démarrer avec Ubuntu (s’il démarre, avec ou sans secure boot), un système Debian Live ou l’installateur Debian en mode rescue en demandant de lancer un shell sur la racine du système Debian installé (/dev/sda2), et exécuter la commande suivante en root pour afficher les entrées d’amorçage EFI :

efibootmgr -v

Normalement, après l’installation, il devrait y avoir une entrée “debian”.
Tu peux essayer ceci qui ne nécessite pas d’entrée d’amorçage EFI :

  • monter la partition EFI (/dev/sda1) sur /mnt si elle n’est pas déjà montée

  • copier le fichier /mnt/EFI/debian/grubx64.efi en /mnt/EFI/boot/bootx64.efi (remplacer /mnt par le point de montage réel si elle est déjà montée)

Oublié dé réagir à ça :

Quel post ?

PS : Il y a peut-être moyen d’empêcher GRUB de tenir compte du secure boot, mais je ne sais pas comment faire. Je n’ai pas d’expérience avec le secure boot. Si quelqu’un sait…


#32

J’ai redémarré avec ma clé live Debian et fait les manips indiquées. Le résultat de la commande efibootmgr -v est joint. efibootmgr_result.txt (1,0 Ko)

Aucun changement avec le boot secured désactivé. J’ai toujours le message No Bootable Device…


#33

Tu aurais pu coller la sortie directement dans le forum comme je le fais, c’est plus accessible :

BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 2001,2002,2003
Boot0000* Unknown Device: 	HD(1,GPT,09eb2286-3bcf-486a-a844-b6a65311a5ab,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)RC
Boot0001* USB HDD: USB DISK 2.0	PciRoot(0x0)/Pci(0x14,0x0)/USB(11,0)/HD(1,MBR,0x6,0x588,0x340)RC
Boot0002* Unknown Device: 	HD(1,GPT,09e7fa83-9240-4c6a-896d-415c74008021,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)RC
Boot0003* Unknown Device: 	HD(1,GPT,09e7fa83-9240-4c6a-896d-415c74008021,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)RC
Boot0004* debian	HD(1,GPT,09eb2286-3bcf-486a-a844-b6a65311a5ab,0x800,0x100000)/File(\EFI\debian\grubx64.efi)
Boot0005* ubuntu	HD(1,GPT,09eb2286-3bcf-486a-a844-b6a65311a5ab,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0006* ubuntu	HD(1,GPT,09eb2286-3bcf-486a-a844-b6a65311a5ab,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0007* ubuntu	HD(1,GPT,09eb2286-3bcf-486a-a844-b6a65311a5ab,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot2001* EFI USB Device	RC
Boot2002* EFI DVD/CDROM	RC
Boot2003* EFI Network	RC

Une entrée “debian” est bien présente (0004), mais elle ne figure pas dans l’ordre de boot (BootOrder).
Avec le secure boot désactivé, tu peux essayer de l’y ajouter :

efibootmgr -o 0004,2001,2002,2003

Sinon, tu as essayé la copie de fichier .efi suggérée dans mon message précédent ?

PS : Ubuntu est encore installé ou tu l’as écrasé avec Debian ?


#34

Avec le boot secure désactivé et ma clé live, j’ai modifié le BootOrder en mettant debian en premier. J’ai rebooté et eu le même message No Bootable Device.

En rebootant avec ma clé live, j’ai vérifié l’ordre des boot avec efibootmgr et me suis rendue compte que le 0004 ne figurait toujours pas dans l’ordre de boot. Est-ce normal ?

Sinon, j’avais bien copié le fichier .efi dans boot. Fallait-il bien le copier en bootx64.txt ? En effet, il existait déjà un fichier BOOTX64.EFI (en majuscules). Après nouveau contrôle, je viens de m’apercevoir qu’il n’y a pas de fichier bootx64.efi dans /dev/sda1.

Pourquoi les modifications faites sur le disque dur ne sont-elles pas conservées ? j

Par ailleurs, j’ai écrasé Ubuntu avec Debian.

Enfin, il s’agissait bien du post https://www.debian-fr.org/t/bloque-sur-grub-rescue-resolu/73584/4


#35

Salut

https://wiki.debian.org/UEFI

donne beaucoup d’explications ( en anglais )

Et ici aussi pour réparer
https://wiki.debian.org/GrubEFIReinstall


#36

Bonjour @Eugenie

Je trouve seulement un Acer Aspire V17 Nitro Black Edition VN7-792G avec un moteur de recherche.

Sur https://www.acer.com/ac/fr/FR/content/drivers et en tapant VN7 ;
Il y a les 3 modèles suivants dans la liste déroulante et qui sont en appellation « Aspire V 17 Nitro » :

Aspire V 17 Nitro > Aspire VN7-791G
Aspire V 17 Nitro > Aspire VN7-792G
Aspire V 17 Nitro > Aspire VN7-793G

Je cherche à lire le manuel du modèle dont tu disposes (serait-ce effectivement le VN7-792G ?)
Pour trouver le chapitre sur le micro-logiciel et voir ces fameuses options Secure Boot, legacy/BIOS/CSM/…

Je trouve effectivement un Manuel d’utilisation W10 (Black Edition) pour le modèle VN7-792G.

Le UM_asVN7-792G_Black Edition_FR_v1.pdf n’apporte rien sur les écrans et options du micrologiciel…

Il reste le pauvre https://community.acer.com/en/discussion/391339/linux-on-vn7-792g

Et https://wiki.debian.org/InstallingDebianOn/Acer sans “792” :frowning:

Voilà ce que je trouve de mieux documenté, au final, et que je pense adaptable pour Debian :

J’espère que ça va marcher !

Acer VN7-792G Linux (Fedora) Install.txt (3,9 Ko)


#37

Apparemment établir un mot de passe au supervisor / administrateur du BIOS donne la possibilité
de placer le boot type à la valeur ‘Legacy’

N’hésite pas à demander de l’aide si besoin pour donner ces paramètres à l’amorçage USB du noyau d’installation :

Type the following to add them to the kernel boot options:

nouveau.runpm=0 nouveau.modeset=0


#38

Il y a hélas des firmwares UEFI qui font un peu n’importe quoi avec les entrées d’amorçage EFI, comme les supprimer intempestivement ou ne pas en tenir compte. Te souviens-tu si le contenu de BootOrder était bien conforme à la modification demandée ?

Non, bootx64.efi.

Peu importent les majuscules, FAT n’est pas sensible à la casse. Il fallait écraser ce fichier.

Comment ça ? Qu’est-ce que sda1 ? La partition EFI ? Si possible montre au lieu de seulement décrire.


#39

le mode legacy peut aussi avoir pour nom CSM.
as tu une option du bios qui parle de CSM?


#40

1. Résultat de fdisk -l du disque dur

Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 58344A86-0826-4F71-A139-EE5EA97D90CA

Device          Start        End    Sectors   Size Type
/dev/sda1        2048    1050623    1048576   512M EFI System
/dev/sda2     1050624 1936979967 1935929344 923.1G Linux filesystem
/dev/sda3  1936979968 1953523711   16543744   7.9G Linux swap

2. Résultat de efibootmgr -v lancé sur la racine de /dev/sda2 monté au démarrage via la clé live debian

BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 2001,2002,2003
Boot0000* Unknown Device: 	HD(1,GPT,09eb2286-3bcf-486a-a844-b6a65311a5ab,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)RC
Boot0001* USB HDD: USB DISK 2.0	PciRoot(0x0)/Pci(0x14,0x0)/USB(11,0)/HD(1,MBR,0x6,0x588,0x340)RC
Boot0002* Unknown Device: 	HD(1,GPT,09e7fa83-9240-4c6a-896d-415c74008021,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)RC
Boot0003* Unknown Device: 	HD(1,GPT,09e7fa83-9240-4c6a-896d-415c74008021,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)RC
Boot0004* debian	HD(1,GPT,09eb2286-3bcf-486a-a844-b6a65311a5ab,0x800,0x100000)/File(\EFI\debian\grubx64.efi)
Boot0005* ubuntu	HD(1,GPT,09eb2286-3bcf-486a-a844-b6a65311a5ab,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0006* ubuntu	HD(1,GPT,09eb2286-3bcf-486a-a844-b6a65311a5ab,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0007* ubuntu	HD(1,GPT,09eb2286-3bcf-486a-a844-b6a65311a5ab,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot2001* EFI USB Device	RC
Boot2002* EFI DVD/CDROM	RC
Boot2003* EFI Network	RC

3. Résultat de efibootmgr -v après modification de l’ordre

BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0004,2001,2002,2003
Boot0000* Unknown Device: 	HD(1,GPT,09eb2286-3bcf-486a-a844-b6a65311a5ab,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)RC
Boot0001* USB HDD: USB DISK 2.0	PciRoot(0x0)/Pci(0x14,0x0)/USB(11,0)/HD(1,MBR,0x6,0x588,0x340)RC
Boot0002* Unknown Device: 	HD(1,GPT,09e7fa83-9240-4c6a-896d-415c74008021,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)RC
Boot0003* Unknown Device: 	HD(1,GPT,09e7fa83-9240-4c6a-896d-415c74008021,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)RC
Boot0004* debian	HD(1,GPT,09eb2286-3bcf-486a-a844-b6a65311a5ab,0x800,0x100000)/File(\EFI\debian\grubx64.efi)
Boot0005* ubuntu	HD(1,GPT,09eb2286-3bcf-486a-a844-b6a65311a5ab,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0006* ubuntu	HD(1,GPT,09eb2286-3bcf-486a-a844-b6a65311a5ab,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0007* ubuntu	HD(1,GPT,09eb2286-3bcf-486a-a844-b6a65311a5ab,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot2001* EFI USB Device	RC
Boot2002* EFI DVD/CDROM	RC
Boot2003* EFI Network	RC

4. Copie du fichier .efi de debian dans la partition EFI (/dev/sda1 monté sur /mnt du disque dur

Je confirme que chaque fois que je reboote (à partir de la clé live bien entendu), je perds les modifications du BootOrder.
Par ailleurs, j’ai supprimé dans la partition EFI le fichier BOOTX64.EFI et ai copié dans le répertoire BOOT le fichier grubx64.efi de debian en le renommant bootx64.efi. J’ai toujours le message No Bootable Device.
debian est correctement installé : je peux créer des fichiers dans l’arborescence home et je les conserve au reboot. Pourquoi les modifications de la partition EFI ne sont-elles pas conservées ?