NetInstall Jessie : problème avec UEFI

Support Debian
#1

Depuis 10 ans que j’installe des Debian un peu partout, c’est la première fois que je n’arrive pas à me dépanner seul :013
Situation :
Ordibureau machine fonctionnelle - Sid seule sur SSD + DDsata3 avec “Squeeze” (pas très fonctionnelle) et “Kubuntu” (sur laquelle je suis actuellement).
Samedi, je télécharge et je grave sur CD une image NetInstall de Jessie pour remplacer une vieille “stable” sur mon portable (Dell Studio 6 ans) et la Squeeze, qui pose problèmes, citée plus haut.

Installation sur portable effectuée correctement : Jessie fonctionnelle.

Hier, je décide de remplacer la Squeeze sur mon ordibureau avec le même CD (TC et gravé sur cet ordibureau).
Le début se passe normalement (install manuelle, comme d’habitude) : MDP root et ricardo ; partitionnement classique avec demande de formatage des partitions de la Squeeze à remplacer … fin du partitionnement … envoyez !

Alerte : (de mémoire) “aucune partition EFI trouvée” ; “L’installateur est … en UEFI…” ; “Toutes les partitions ne sont pas avec système UEFI, vous ne devriez pas forcer car vous risquez de ne plus pouvoir charger les autres distribs…”

Je laisse donc le “non”, l’install se lance, la barre montre 33% dès le départ et ça bloque ainsi : plantage irrémédiable après attente 20 mn.
de plus, plus d’accès à ma Sid sur le SSD :013

Plusieurs essais en enlevant le SDD et ne laissant que le DDsata appelé à recevoir cette Jessie. Tous se soldent par le même plantage au même endroit.

Je ne me souviens plus parfaitement mais il semblerait que le grub (V 2.00-22)fonctionnel soit sur de DDsata car le SSD retiré, j’ai quand même accès à la Squezze et à la présente Kubuntu.

J’ai essayé un peu tous les règlages du “Bios ?” UEFI mais sans plus de succès.

Parted -l montre bien les SSD et DDsata avec toutes leurs partitions. Idem avec Gparted.

Avant d’employer les grands moyens, j’aimerais l’avis des autres, surtout ceux qui maitrisent bien cette machine infernale d’UEFI.

Merci de votre aide.

EDIT :
J’ai oublié de dire que ce matin, pour un dernier essais, j’ai tenté en “forçant” l’install UEFI, malgré l’alerte, mais toujours le même plantage.

#2

J’ai un peu d’expérience avec l’UEFI, notamment son interaction avec GRUB.

Un PC est susceptible de démarrer en deux modes distincts :

  • le mode traditionnel BIOS/legacy pour les PC ayant un BIOS ou firmware UEFI avec CSM ;
  • le mode UEFI (natif) pour les PC ayant un firmware UEFI. Il existe des variantes 32 bits (essentiellement d’anciens Mac Intel 32 bits) et 64 bits (la majorité des PC UEFI).

En mode BIOS, le BIOS charge et exécute le programme d’amorce en mode réel 16 bits contenu dans le MBR du disque de boot. Typiquement, celui-ci contient l’amorce (boot image) installée par le paquet grub-pc qui est la variante de GRUB pour le mode BIOS et qui va charger le noyau de GRUB (core image).

En mode UEFI, le firmware charge et exécute un programme exécutable .efi qui se trouve dans un répertoire d’une partition système EFI présente sur un des disques. Par exemple /EFI/debian/grubx64.efi qui est le noyau (core image) de GRUB installé par le paquet grub-efi-amd64 qui est la variante de GRUB pour le mode UEFI 64 bits. Le programme d’amorce en mode réel 16 bits du MBR n’est plus utilisé, la notion de disque de boot non plus. Les différents chargeurs sont enregistrées dans la mémoire non volatile du firmware.

La plupart des firmwares UEFI avec CSM que j’ai vus amorcent en priorité en UEFI.

Depuis au moins Wheezy, les images hybrides d’installation de Debian (pas les image live) pour x86 sont amorçables en mode BIOS et UEFI. Si l’installateur est amorcé en mode UEFI, il voudra installer la variante UEFI de GRUB au lieu de grub-pc. Mais pour cela, il a besoin qu’une partition système EFI soit présente sur un des disques. Si on choisit le partitionnement automatique, il crée cette partition automatiquement. Dans le cas contraire, il faut la créer manuellement, c’est possible dans l’outil de partitionnement en mode UEFI. Pour Debian, elle n’a pas besoin d’être grande, 1 Mo suffit largement. En fait c’est une partition formatée en FAT avec un indicateur de type particulier pour l’identifier comme partition système EFI. On peut la créer aussi bien sur un disque au format GPT qu’au format MBR/MSDOS (par contre je ne sais pas si elle peut être une partition logique, je n’ai jamais essayé).

Autre point important que tu as partiellement évoqué : si GRUB est amorcé en UEFI (grub-efi-amd64 ou grub-efi-ia32) , il ne pourra pas détecter ni chaîner un autre chargeur amorçable en mode BIOS (chargeur de Windows ou GRUB de grub-pc). Par contre il peut amorcer le noyau Linux d’autres distributions s’il les a détectés et inclus dans son menu de démarrage. Et vice versa : si GRUB est amorcé en mode BIOS (grub-pc), il ne pourra pas détecter ni chaîner un autre chargeur amorçable en mode UEFI.

Si tu veux que l’amorçage de GRUB se fasse en mode legacy, tu as deux moyens :

  • forcer le firmware à démarrer l’installateur en mode BIOS/legacy ;
  • ne pas installer de chargeur et installer grub-pc manuellement plus tard.

Pour forcer le firmware UEFI à démarrer l’installateur en mode BIOS/legacy depuis un CD compatible UEFI, il faut 1) activer le démarrage en mode CSM/legacy et 2) désactiver l’amorçage en mode UEFI natif ou sélectionner l’amorçage sur le CD en mode legacy depuis le menu de démarrage du firmware.

Pour forcer le firmware UEFI à démarrer l’installateur en mode BIOS/legacy depuis une clé USB compatible UEFI, c’est un peu plus facile : il faut 1) activer le démarrage en mode CSM/legacy et 2) supprimer le chargeur UEFI qui se trouve sur la partition système EFI, voire la partition système EFI entière.

Lorsque l’installation s’est bloquée, c’était lors de quelle opération ? Tu as regardé les logs d’installation dans la console 4 ou depuis le shell de la console 2 ou 3 ?

#3

https://wiki.archlinux.fr/GRUB#Syst.C3.A8mes_UEFI

PS: On dirait que le secure boot est maintenant géré par linux (lien en anglais):
https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface

#4

Merci pour toutes tes explications, Pascal, mais c’est un peu trop complexe pour mon cerveau qui est loin de fonctionner comme à 20 ans.
Je vais procéder par étapes en te posant des questions. Ne m’en veux pas si tu y a déjà répondu mais je patauge complètement.

1/ Mon soucis premier est d’essayer de récupérer au moins ma Sid sur le SSD. Celle-ci y a été installée en premier et elle est seule sur ce SSD (3 partitions : / ; /home ; swap).
Le DDsata se connecte et se retire facilement de la machine donc je peux l’enlever et ne laisser que le SSD.
Cette Sid a été installée (je crois) en UEFI.
Pourrais-tu me détailler les étapes les plus simples pour ce faire ?

2/ Comment connaitre les bon réglages dans ce UEFI ?

3/ Qu’est-ce qui est le mieux (avantages/inconvénients) : UEFI ou Bios Legacy ?

Blocage au départ du partitionnement effectif.
Je n’ai plus d’accès aux logs.

Merci de l’aide.

EDIT :
@ Cedric : Merci aussi pour le lien.

#5

Pour récupérer ta sid:
Je tenterai de booter sur supergrubdisk2, pour déja tenter redémarrer la sid.
http://www.supergrubdisk.org/

Si tu arrive à redémarrer ta sid tente ensuite un:

Sinon:

#6
  1. Une indication pour savoir si le chargeur de la Sid démarre en UEFI, c’est
  • la présence d’une partition système EFI sur au moins un des disques
  • montée sur /boot/efi dans le fstab de la Sid
  • contenant un fichier /EFI/debian/grubx64.efi ou grubia32.efi
  • le paquet grub-efi-amd64 ou grub-efi-ia32 est installé sur la Sid au lieu de grub-pc
  • le paquet efibootmgr est aussi installé
  • le menu de démarrage UEFI du firmware devrait contenir une entrée nommée “debian” (mais elle n’appartient pas forcément à la Sid) ; ces entrées sont aussi visibles avec efibootmgr à condition d’avoir pu démarrer en mode UEFI.

Mais tout cela ne compte que si c’est le chargeur de la Sid qui démarre. Comment était géré l’amorçage entre les différents distributions installées sur la machine ?

La SID pouvait-elle démarrer avec le SSD seul ? Si oui, cela signifie que le SSD contient un chargeur.

  1. Le nom et la position des réglages dans le firmware varie.
  • s’il est ancien, il peut avoir une option pour activer ou désactiver le boot en mode UEFI natif (ou UEFI ou EFI tout court), le boot en mode legacy/BIOS étant toujours activé
  • s’il est récent, il aura plutôt une option pour activer ou désactiver le boot en mode legacy/CSM, le boot en mode UEFI natif étant toujours activé
  • il peut aussi y avoir une option de boot “UEFI hybride” permettant le boot dans les deux modes UEFI natif et CSM.

Les valeurs à mettre dépendent de ce que tu veux faire.

Désolé de ne pas pouvoir donner de procédure simple à suivre, mais cela dépend trop de la façon dont tout a été installé, et l’arbre a trop de branches.

  1. Avantage de l’UEFI :
  • prise en charge par le firmware des disques de plus de 2 Tio (avec le format de partition GPT)
  • permet d’installer plusieurs chargeurs d’amorçage les uns à côté des autres (Windows, Debian, openSUSE…). Il n’y a plus de guerre pour le MBR. Cependant, il faut préciser que l’installation du chargeur GRUB EFI d’une Debian remplace le chargeur GRUB EFI d’une autre Debian précédemment installé.
  • permet d’inclure Windows préinstallé en UEFI dans le menu de GRUB

Inconvénients :

  • complexe
  • les firmwares UEFI sont buggés
  • les chargeurs d’amorçage doivent être enregistrées dans la mémoire non volatile du firmware ; si cette mémoire est effacée ou si on change de carte mère ou si on met le disque dans une autre machine, seul le chargeur par défaut (/EFI/boot/bootx64.efi ou bootia32.efi) sera amorçable.

Le blocage au partitionnement ne me semble pas lié à l’UEFI. Par contre je viens d’observer cela avec ma première installation de Jessie : il était causé par mkfs.ext4 appelé pour formater la partition racine, qui, ayant vu qu’elle avait été montée récemment sur /root ou /target, demandait s’il fallait poursuivre. L’installateur ne semblait pas avoir prévu ce cas de fonctionnement interactif. De fait la partition avait servi précédemment de racine pour une openSUSE.

#7

Bon, j’en déduis qu’à mon niveau de compétences, il est préférable que :

  • j’abandonne UEFI pour ne mettre que Grub legacy ‘only’ comme choix dans le Bios
  • je sauvegarde un maximum de données de ma /home sur clefs USB (j’ai déjà des clones sur DDexts)
  • je sorte le DDsata de sa niche pour ne conserver que le SSD
  • j’essaie une installation neuve d’une Jessie sur ce SSD
    ---------------- soit en tentant de conserver la /home
    ---------------- soit, s’il ne veut pas, avec une /home neuve que je nourrirai ensuite
  • je reste avec une “stable” définitivement, qui en fait me suffira bien pour mes occupations très basiques.
#8

Il a bien voulu accepter de conserver la /home.
Ça mouline pour l’installation des logiciels.
Résultat ce soir … tard

#9

Pour ma part, j’ai profité d’avoir un PC UEFI sous la main pour me familiariser avec ce nouveau monde, comme j’avais profité d’avoir IPv6 sur ma connexion ADSL. L’UEFI se généralise peu à peu, il va bien falloir y passer tôt ou tard. On trouve déjà des machines sans compatibilité BIOS.

#10

Je comprends parfaitement ton point de vue qui est, en principe, le mien (j’étais sous Sid, preuve que je ne crache pas sur la difficulté) mais l’âge venant, j’ai de plus en plus de mal “à suivre”.

Pour en revenir à cette install de Jessie, la fin s’est bien passée et je retrouve une grande partie de mes habitudes, sans avoir à les recharger.
Bien sûr, j’aurai quand même à faire mais c’est un moindre mal.
Le chargement sur le SSD de fait à une vitesse grand V :023

Je ne suis pas encore passé à la phase de reconnexion du DDsata mais je vais patienter un peu car je n’en ai pas un besoin urgent (que des sauvegardes dessus + Kubuntu et j’ai un autre DDext où sont aussi ces sauvegardes).

Il faudra se souvenir de ce fil, ne serait-ce que pour ton explication concernant UEFI vs Grub.

Merci encore.

Je clos ce fil et j’en ouvrirai un autre si le besoin s’en fait sentir quand je passerai au branchement du DDsata interne.