Ubuntu 17.10 retiré de la circulation à cause d’un problème d’UEFI

Ubuntu 17.10 retiré de la circulation à cause d’un problème d’UEFI

Canonical vient de faire disparaître les liens vers la version 17.10 d’Ubuntu sur son site en raison de remontées alarmantes concernant une corruption des UEFI de certains portables de Lenovo, Acer, Dell ou Toshiba.
Il semblerait que le système parviennent à corrompre l’UEFI de ces machines et à empêcher le démarrage de celles-ci sur des périphériques USB.


L’UEFI[sup]1[/sup] est une mise à jour des fonctions et usages du BIOS. Le nouveau système permet beaucoup de choses supplémentaires notamment en matière de sécurité ou en usage réseau. Des outils puissants mais pas forcément simples à maîtriser. On a ainsi connu par le passé des bugs d’UEFI avec des noyaux Linux qui zombifiaient totalement des machines de Samsung.
Aujourd’hui, il semblerait qu’Ubuntu 17.10 pose problème à plusieurs marques et modèles de portables avec une assez grave corruption de leurs systèmes UEFI sur des portables exécutant la distribution. Assez pour que Canonical réagisse en faisant disparaitre les liens de téléchargement de son site.
Il faut dire que le résultat de la corruption est vraiment problématique. En installant Ubuntu 17.10 sur ces portables de marques Lenovo, Dell, Acer ou Toshiba, le système modifie non seulement l’UEFI mais empêche de revenir ensuite sur ces changements. Parmi les points les plus dérangeants, l’impossibilité de démarrer la machine sur un périphérique USB, ce qui empêche de revenir à une autre distribution par la suite… A moins d’extraire le stockage, ou d’avoir un lecteur optique sur son portable. On reste coincé sous Ubuntu 17.10.
Les possesseurs de portables ayant rencontré le problème n’ont pour le moment pas de solution. Vous trouverez plus d’informations techniques sur Linuxium.
Une mise à jour de Canonical devrait résoudre le problème et faire apparaître à nouveau le système sur leurs pages de téléchargement. L’éditeur précise tout de même au passage de ne pas télécharger le système dans cette version sur d’autres plateformes pour le moment. Les précédentes versions ne sont évidemment pas affectées par ce bug.
Une première liste des machines affectées par le bug :

[ul][li]Lenovo B40-70, B50-70, B50-80[/li]
[li]Lenovo Flex-3, Flex-10[/li]
[li]Lenovo G40-30, G50-70, G50-80[/li]
[li]Lenovo S20-30[/li]
[li]Lenovo U31-70[/li]
[li]Lenovo Y50-70, Y70-70[/li]
[li]Lenovo Yoga Thinkpad (20C0)[/li]
[li]Lenovo Yoga 2 11″ – 20332[/li]
[li]Lenovo Z50-70, Z51-70[/li]
[li]Lenovo ideapad 100-15IBY[/li]
[li]Acer Aspire E5-771G[/li]
[li]Acer TravelMate B113[/li]
[li]Toshiba Satellite S55T-B5233[/li]
[li]Dell Inspiron équipés d’un BIOS Insyde Software[/li][/ul]

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147

Vive l’UEFI !
Nous constatons des difficultés lors des installations,

  • pour désactiver le « démarrage rapide », lequel se fait aux dépens de l’extinction, rallongée pour ranger les programmes, et aussi encore allongée par les mises à jour…
  • il faut souvent trifouiller le BIOS-UEFI, lorsque l’ordinachose-windowsifiée ne veut pas démarrer sur l’USB.
  • sans oublier les surprises, en cours d’installation, ou pire lors du premier redémarrage.

C’est le progrès…

UEFI : ça y est, j’ai enfin compris :

  • il faut une partition (100 - 250 Mo) “EFI”
  • ou mettre le BIOS-EFI en mode “hérité” (en français : “Legacy”).

Il faudra prêter attention aux gens qui arrivent à 16 heures aux Linux Install ou plus tard pour une installation…
Nous risquons d’y passer la soirée et la nuit !

1 « J'aime »

Un ami m’a dit qu’un groupe d’utilisateurs de linux avait réussi à se passer de magie pour installer Linux sur un ordi UEFI. Sont-ils des envahisseurs venus d’une autre galaxie ? Sont-ils des voyageurs du temps venus un futur lointain ? Partageront-ils leur savoir avec nous pauvres linuxiens de Quimper ? Je vais sacrifier quelques poulets sur l’autel du gnu en offrande à ces demi-dieux venus d’ailleurs. Je garde les cochons et les veaux pour le remplacement de ma valve aortique et les restes pour un barbeuk pour feter mon retour, si j’en reviens :heart_eyes:

uefi

1 « J'aime »

C’est vrai que UEFI c’est simple…

Dans windows
Maj + redémarrer
ou
avec W10 : paramètres => mise à jour et sécurité => récupération =>redémarrer maintenant
avec W8 : paramètres => modifier les paramètres du pc => mise à jour et récupération => redémarrer maintenant
ensuite
-> Fenètre choisir une option : utiliser un périphérique
-> Fenètre utiliser un périphérique : EFI USB ou EFI DVD


SI la clé usb ou le dvd n'apparait pas = > désactiver le Secure Boot
Maj + Redémarrer => Résolution des problèmes => Options avancées => Changer les paramètres du microprogramme UEFI.
https://doc.ubuntu-fr.org/desactiver_secure_boot


W7 : à l'ancienne au démarrage trouver la touche qui permet d'aller dans le bios


Désactiver le démarrage rapide : paramètres => système => alimentation et mise en vielle => modifier des paramètres non disponibles => décocher le démarrage rapide ett enregistrer
Si bouton désactiver le démarrage rapide a disparu => désactiver la vieille prolongée
Démarrer et tapez CMD dans la boîte de recherche => clic droit sur l’icône Exécuter en tant qu’administrateur => lancer powercfg /hibernate off

Simple, en effet…
« Il suffit » de convaincre l’ordinateur récalcitrant d’accepter.

Ma découverte de ce jour.
S’il est possible d’installer Ubuntu sur un ordinateur configuré en UEFI et avec “secure boot” activé, par contre il ne vous sera pas possible de démarrer le nouvel Ubuntu tant que ce “secure boot” restera activé

Interessant ça !
Une fois le secure boot désactivé, est-il possible de le réactiver et faire booter le windows ? (j’avais en tête que la désactivation entraine une perte d’éléments nécessaire au boot windows).

Ce n’est pas tout à fait vrai. Si je comprends bien, d’après UEFI/SecureBoot - Ubuntu Wiki ubuntu est compatible Secure Boot puisque Canonical a acheté une clef de signature.

Cependant si tu utilises sur ton installation des drivers non-officiels (et donc pas signés par Canonical) tu devras désactiver Secure Boot — ou passer par une étape de signature des modules, je crois.

Je ne peux pas te répondre. Dans mon cas j’ai écrasé W7

Je ne peux que te rapporter mon expérience.
Le secure boot activé j’ai pu installé Ubuntu 18.04 à partir d’un iso qui était sur une clé USB MultySystem
Le secure boot activé je n’ai pas pu démarrer l’Ubuntu
Dès que je pourrai je referai l’installation à partir d’une clé usb n’ayant que Ubuntu

Peut-être qu’il faudrait faire des tests avec une 18.10 officielle ?

Bonne idée, je vais faire

1 « J'aime »

De l’intérêt d’installer Ubuntu en Legacy avec Secure Boot désactivé
Sur mon ordi je passe en UEFI uniquement, pour voir… Je ne pouvais plus redémarrer sur ma configuration Lubuntu 18.04, normal. Je pouvais démarrer sur mes clés USB d’installation Ubuntu, normal mais je n’avais plus accès au Bios :hot_face:
Cela n’a rien d’étonnant puisque la plupart des ordis avec W10 qui sont passés entre nos mains avaient cette caractéristique. Il fallait passer par W10 pour accéder au BIOS/micrologiciel UEFI
Heureusement sur ma carte mère Intel DZ77SL-50K il y a un jumper qui m’a permis de revenir au Bios et de le remettre en Legacy. Ouf mais pas simple !

C’est ça qui me choque. Si le disque est vierge, on fait comment ? :frowning:

Peux être que le firmware UEFI sur le disque devient prioritaire lorsqu’il est présent ??? Je n’ai pas pu prendre le temps de tester lorsque j’avais un pc full windows UEFI/WinSECURE… (mon pc a une touche pour choisir quel boot UEFI booter).

Comme moi on trouve le bon jumper ou comme toi, on a une touche booter
Mais face à un ordi inconnu avant d’effacer Windows j’en conclus que je dois le mettre en Legacy avec secure boot désactivé tant que je ne suis pas certain que Ubuntu, une fois installé, pourra redémarrer en UEFI avec secure boot activé :slight_smile:

Test positif en UEFI et avec secure boot activé de la 18.04 et la 18.10 à partir de clé usb faites avec le créateur de disques de démarrage d’Ubuntu
Les deux installations ont redémarrées normalement donc tu avais raison Canonical a bien acheté une clef de signature qui est installé sur ces deux versions

1 « J'aime »

hier, mardi 11, nous avons eu à passer sous Lubuntu 18.04 (simple boot) un ordinateur portable récent
J’ai découvert à cette occasion que UEFI de classe 3 est uefi uniquement sans couche CSM/Legacy.
Bien sur dans ce cas la distribution Linux ne peut être installée qu’en UEFI mais avec la possibilité de désactiver le secure boot car au démarrage de ce portable, il n’y avait plus de W10 mais un ESC permit d’aller dans le UEFI
Dans le cas courant où l’UEFI n’est pas accessible au démarrage et qu’il n’y a plus de W10, il faut prier pour que la clé usb d’installation d’Ubuntu soit reconnu au démarrage… :neutral_face:

Je pense (j’espère ?) que toute carte mère permet l’accès à l’UEFI par un raccourci clavier au démarrage, sans passer par l’OS.

Reste à trouver cette combinaison, dans la doc, ou par l’essai…

Secure Boot ne doit être désactivé que dans le cas d’une distro qui ne le supporte pas. Même Debian est en train de s’y préparer – c’est dire…

Modern versions of Ubuntu, Fedora, openSUSE, and Red Hat Enterprise Linux all “just work” without disabling or configuring Secure Boot. They use a small “shim” boot loader signed by Microsoft, which in turn confirms the main boot loader was signed by the Linux distribution before loading it. Some other smaller Linux distributions also use shim.

The Linux Foundation has released its own Secure Boot solution, which other Linux distributions would be free to use instead of shim. Matthew Garrett pledged to work on combining the Linux Foundation’s solution and shim to create one standard boot loader all Linux distributions can take advantage of. Work is ongoing on making this easier for Linux distributions, and all Linux distributions can support Secure Boot-enabled PCs with a bit of work already.

cf. How to install Linux on a PC with Secure Boot enabled | PCWorld

1 « J'aime »