Portable schneider SCL141CTP impossible de booter sur Debian 10

Support Debian
Tags: #<Tag:0x00007f46ad901870>
#29

Oui, j’avais désactivé le boot UEFI sur la machine.

Non, je n’ai pas cette possibilté sur la machine.

#30

Ta réponse n’est pas claire. Avec le boot UEFI désactivé, c’est ISOLinux qui se lance sur la clé USB d’installation ou c’est GRUB ?

#31

Avec l’UEFI désactivé je dirais que c’est Grub qui se lance puique j’ai la possibilité d’entrer en ligne de commande Grub en appuyant sur la touche C du clavier.

#32

Donc le boot UEFI n’est pas vraiment désactivé puisque GRUB ne se lance sur une clé d’installation qu’en mode EFI. Et si le firmware UEFI 32 bits ne peut pas booter en mode BIOS, ça explique pourquoi une image d’installation 64 bits ne boote pas.

#33

Je pense qu’il y a un problème avec l’UEFI de cette machine.

#34

Si seulement ce n’était qu’avec cette machine… je dis haut et fort qu’il y a un problème avec TOUTES les implémentations de l’UEFI.

Avec l’image d’installation multi-arch, si tu le souhaites tu devrais pouvoir installer un système 64 bits, qui supporte un firmware UEFI 32 bits (l’inverse n’est pas vrai).

La conclusion de nos échanges est donc que tu as installé un système 32 bits en mode EFI dont l’amorçage est géré par grub-efi-ia32 mais le firmware UEFI ne boote pas ce système. Il y a plusieurs raisons possibles à cela, notamment des bugs potentiels du firmware UEFI.

Si j’étais devant la machine, je ferais ceci :

  • démarrer avec la clé USB d’installation,
  • dans le menu de GRUB, sélectionner “advanced” > “rescue”
  • après avoir déroulé les étapes habituelles, sélectionner la partition contenant la racine du système installé
  • accepter la proposition de monter la partition d’amorçage EFI
  • exécuter un shell sur la racine du système installé.

Dans ce shell, je ferais quelques vérifications :

  • afficher la table de partition avec fdisk -l
  • afficher les montages avec df -h qui doit mentionner /boot/efi
  • afficher le contenu du répertoire /boot/efi avec find /boot/efi qui doit contenir un répertoire EFI/debian avec des fichiers *.efi
  • afficher les variables de boot EFI avec efibootmgr

En fonction des résultats, on avisera pour la suite à donner.

#35

Est-ce que je démarre avec UEFI disabled sur l’ordi ?
Est-ce que je lance l’install avec la clef en 32 bits ou bien avec la clef multi-arch ?
Parce qu’avec la multi-arch je n’ai toujours pas trouvé de .iso.
Voici ce que j’ai dans le répertoire multi-arch que j’ai extrait :

ls -lr linux-image-3.9-1-amd64_3.9.8-1_amd64
total 16
drwxr-xr-x 3 laguespa laguespa 4096 juin  30  2013 usr
drwxr-xr-x 3 laguespa laguespa 4096 juin  30  2013 lib
drwxr-xr-x 2 laguespa laguespa 4096 juin  30  2013 DEBIAN
drwxr-xr-x 2 laguespa laguespa 4096 juin  30  2013 boot
#36

D’après ce que tu as écrit précédemment, cela ne fait aucune différence puisque GRUB EFI se lance systématiquement quelle que soit la valeur de cette option. Pour lister les variables de boot EFI avec efibootmgr il faut démarrer en mode EFI (donc avec GRUB EFI).

Peu importe. Mais si tu utilises l’image multi-arch, il faut sélectionner le mode rescue 32 bits puisque tu as fait une installation 32 bits.

De quoi parles-tu ? D’où sors-tu ce fichier/répertoire linux-image-3.9-1-amd64_3.9.8-1_amd64 ? Il n’y a rien de tel à l’URL que j’ai indiqué.
Je répète : il s’agit du fichier debian-10.2.0-amd64-i386-netinst.iso qui se trouve dans https://cdimage.debian.org/debian-cd/current/multi-arch/iso-cd/
Lien direct : https://cdimage.debian.org/debian-cd/current/multi-arch/iso-cd/debian-10.2.0-amd64-i386-netinst.iso

#37

Ok, voici ce que ça retourne. J’ai booté sur la clef 32 bits avec laquelle j’ai fait la dernière install.

fdisk -l
/dev/mmcblkop1 2048 1050623 1048576 512M Système EFI
/dev/mmcblkop2 (je ne recopie pas les chiffres...) 26.4G Système de fichier Linux
/dev/mmcblkop3 (je ne recopie pas les chiffres...) 1.9G Partittion d'échange Linux
Type d'étiquette de disque : dos
df -h
/dev/mmcblkop2 Taille 26G 3.6G utilisé 21G dispo
devtmpfs (je passe les chiffres) /dev
/dev/mmcblkop1 Taille 511M Utilisé 4.2M Dispo 507M Utilisé 1% /boot/efi
find /boot/efi
/boot/efi/
/boot/efi/debian
/boot/efi/debian/grub.efi
/boot/efi/debian/shimia32.efi
/boot/efi/debian/grubia32.efi
/boot/efi/debian/mmia32.efi
/boot/efi/debian/BOOTIA32.CSV
/boot/efi/debian/grub.cfg
efibootmgr
Timeout: 1 seconds
BootOrder: 0000

Ps. : J’ai re-téléchargé l’image iso multi-arch avec ton lien et j’ai effectivement une image iso maintenant. Pas compris ce qui s’était passé avant. Désolé et merci de ta patience.

Une question : est-ce que je peux me connecter en ssh sur la machine que je viens de démarrer en mode récupération et comment sachant que j’ai trouvé son adresse ip avec nmap ?

#38

C’est le type d’étiquette du “disque” eMMC (sorte de SSD) interne /dev/mmcblk0 ou de la clé USB ? Normalement fdisk l’affiche avant la liste des partitions.

Si c’est celle du disque, alors c’est une cause possible supplémentaire de non-démarrage : certains firmwares UEFI, en contradiction avec la spécification UEFI, ne peuvent booter en mode EFI que sur un disque avec une étiquette GPT.

La partition EFI est bien présente et montée et contient ce qu’il faut. Par contre les variables de boot EFI ne contiennent pas d’entrée “debian” qui devrait avoir été créée lors de l’installation. C’est une raison suffisante pour que GRUB ne démarre pas sur le disque. Il n’y a pas eu d’erreur lors de l’installation de GRUB par l’installateur Debian ?

Tu peux essayer de réinstaller GRUB avec la commande suivante :

grub-install --force-extra-removable

et vérifier ensuite avec efibootmgr si une entrée “debian” a été créée. L’option --force-extra-removable installe une copie de GRUB dans le chemin de support amovible qui est un emplacement prédéfini qui n’a pas besoin d’entrée (comme sur une clé USB). Mais si c’est le type de table de partition (DOS au lieu de GPT) qui pose problème au firmware, ça ne changera rien.

En démarrant l’installateur en mode expert (donc expert rescue 32 bits), il me semble qu’on peut ensuite sélectionner un composant optionnel qui lance un serveur SSH. Mais je le l’ai jamais utilisé. Autrement, si tu as installé un serveur SSH lors de l’installation de Debian, tu peux essayer de le démarrer avec

service ssh start

ou

systemctl start ssh

ou

/etc/init.d/ssh start

mais là encore je ne garantis rien, je ne l’ai jamais fait.

#39

C’est celle de la clef. Le disque est bien en gpt.

Non aucune erreur lors de l’installation de GRUB.

Installation terminée, sans erreur.

efibootmgr
Timeout: 1 seconds
BootOrder: 0000
BootOOOO* debian
#40

L’entrée “debian” a bien été créée.
Et au démarrage, ça change quelque chose ?

#41

Ça boote enfin sur Debian mais d’une part pour aller plus vite à l’install je n’avais installé d’environnement de bureau et d’autre part je n’ai pas le microcode pour le dongle usb que j’utilise pour la connexion internet. Je précise qu’il n’y a pas de port rj45 sur cet ordi…
Même si j’ouvre un tty et que je lance apt install mate-core il est impossible de récupérer les paquets.
Bizarre parce qu’à l’installation le dongle était pris en charge out of the box.

#42

Si tu as un smartphone qui est connecté au web, tu pourrais, une fois ta machine démarrée
y connecter ton smartphone par USB et partager la connexion au web.
J’ai fait pas mal d’installation comme ça, ça fonctionne très bien.

#43

Non, je n’ai pas de smartphone…

#44

Ah, bien. Pour savoir si c’est la création de la variable de boot “debian” ou la copie dans le chemin de support amovible qui a été efficace (cela pourra être utile pour une prochaine installation [*] ), tu peux regarder la valeur de BootCurrent affichée par efibootmgr pour voir si elle correspond au numéro de la ligne “debian”. Ou bien au menu de GRUB, tu peux appuyer sur “c” pour lancer le shell et taper la commande set pour afficher la valeur de la variable cmdpath.

|*] En cas de réinstallation, à ta place je réduirais la taille de la partition EFI qui est surdimensionnée. 20 Mo suffisent largement vu son occupation, et récupérer presque 500 Mo pour la racine sur une capacité de 32 Go, je ne cracherais pas dessus.

Tu pourras le faire avec tasksel lorsque tu auras du réseau.

Dongle wifi ou ethernet ?
Que disent lsusb et ip addr ?
Que contient le fichier /etc/network/interfaces ?

#45 
efibootmgr
BootCurrent: 0000
Boot0000* debian
Boot0001* UEFI OS

Je n’ai pas tout mis pour la sortie de efibootmgr

je n’avais installé d’environnement de bureau

Ok.

C’est un adaptateur wifi.

lsusb : je ne note que la ligne concernant l’adaptateur.

lsusb
Bus 001 Device 003: ID 0846:4260 Netgear, Inc. WG111V3 54 Mbps Wireless [realtek RTL81818
#46 
ip addr
1: lo
2: wlx0026f2aec2b7: <broadcast, multicast> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:26:f2:ae:c2:b7 brd ff:ff:ff:ff:ff:ff
nano /etc/network/interfaces
auto lo
iface lo inet loopback
#47

Donc c’est l’entrée “debian” qui est utilisée. L’autre entrée “UEFI OS” doit correspondre à la copie de secours de GRUB dans le chemin de support amovible.

A priori ça utilise le pilote rtl8187 et n’a pas besoin de firmware.
Vérifie si le module rtl8187 est chargé et s’il y a une interface wifi présente avec

lsmod | grep rtl
ip addr

L’interface n’est peut être pas configurée ni activée.

EDIT : nos derniers messages se sont croisés. L’interface wlmachin existe bien mais n’est pas configurée dans /etc/network/interfaces. Et là, désolé mais j’avoue que je ne suis pas très fort pour configurer une interface wifi en WPA dans /etc/network/interfaces.

#48

Ouaip, c’est ce dont je me suis rendu compte en éditant le fichier.
Le réseau wifi sur lequel je suis est en WEP et n’a pas besoin de mot de passe. C’est peut-être plus simple à configurer non ?

Le module rt18187 est chargé.