Canonical a rappelé la distribution Ubuntu 17.10 publiée en octobre et a
caché le lien du site de téléchargement . La raison en était un
bug critique avec des dommages au BIOS dans certains modèles d'ordinateurs portables Lenovo et un modèle Acer. Une liste complète des modèles concernés est actuellement mise à jour et mise à jour.
Les dommages au BIOS se manifestent par le fait que les nouveaux paramètres ne peuvent plus être enregistrés, et après un redémarrage, l'ordinateur portable démarre avec les anciens paramètres.
Pour aggraver les choses, le démarrage à partir d'une clé USB s'arrête car l'USB n'est pas reconnu.
À en juger par la description du bogue, il semble se produire après l'activation des pilotes intel-spi- * dans le noyau. Apparemment, ces pilotes ne sont pas encore entièrement développés et ne sont pas prêts à être utilisés sur les systèmes utilisateur.
Comme solution de contournement, vous pouvez essayer de désactiver les pilotes intel-spi- *. La description du bogue indique que les conséquences de telles actions seront minimes: "Il est peu probable que quelqu'un fasse vraiment quelque chose qui nécessite ce pilote."
Liste des modèles d'ordinateurs portables concernés:
- Lenovo B40-70
- Lenovo B50-70
- Lenovo B50-80
- Lenovo Flex-3
- Lenovo Flex-10
- Lenovo G40-30
- Lenovo G50-70
- Lenovo G50-80
- Lenovo S20-30
- Lenovo U31-70
- Lenovo Y50-70
- Lenovo Y70-70
- Lenovo Yoga Thinkpad (20C0)
- Lenovo Yoga 2 11 "- 20332
- Lenovo Z50-70
- Lenovo Z51-70
- Lenovo Ideapad 100-15IBY
- Acer Aspire E5-771G
Comme déjà indiqué, la liste s'allonge.
Les commentaires de bogue mentionnent également le Toshiba L50B-23G.
Dans de nombreux forums, les utilisateurs se plaignent de ce problème, car de nombreux ordinateurs portables n'ont pas de lecteurs de CD-ROM - ils ne peuvent donc plus démarrer à partir d'une autre distribution.
Surtout beaucoup de plaintes sur les forums Lenovo. C'est particulièrement désagréable, car ce sont souvent les ordinateurs portables Lenovo ThinkPad qui sont souvent recommandés pour travailler avec Linux, et Canonical les a sur le site, ils sont inclus dans la liste des équipements officiellement pris en charge.
Dans les versions précédentes d'Ubuntu, aucun bogue ne se produit.
Théoriquement, le BIOS peut être flashé et remis à son état d'origine (par exemple, en utilisant le programmateur), mais il s'agit d'une procédure non triviale et légèrement risquée. De plus, tous les utilisateurs n'ont pas de programmeur. Par conséquent, on peut comprendre la forte insatisfaction de ceux qui sont confrontés à ce problème et ne peuvent pas charger l'ordinateur portable. "C'est inacceptable, en ce moment mon Lenovo G50-80 est devenu une brique", a écrit l'une des victimes dans un commentaire sur un bug sur le site Canonical.
UPD Note de l' utilisateur r0mik dans les commentaires de l'article: «Le BIOS ne se détériore pas» au sens littéral - la puce Flash SPI repose sur l'enregistrement. Apparemment, cela se produit via le module de noyau susmentionné, car c'est le seul qui est capable de telles actions (pour cela, il a également été écrit). C'est précisément parce que SPI Flash est verrouillé au niveau matériel pour l'enregistrement qu'aucun moyen de revenir aux paramètres standard du BIOS ne fonctionnera, car les paramètres sont stockés dans SPI Flash. Le programmeur n'aidera pas non plus. Seul le remplacement physique du microcircuit aidera ...
Canonical travaille maintenant activement avec Lenovo pour trouver la véritable cause du problème et publier le correctif. De nouvelles images sont en cours de préparation pour Ubuntu 17.10 avec un noyau mis à jour qui ne cassera pas le BIOS sur les nouvelles installations.
Malheureusement, les nouvelles images n'aideront personne qui a déjà installé Ubuntu 17.10 et endommagé le firmware du BIOS. Un cas extrême est de transporter un ordinateur portable en réparation pour remplacer la carte mère. Si l'ordinateur portable se charge toujours, vous pouvez essayer une telle
solution de contournement qui est proposée sur les forums de support technique de Lenovo.
Cet utilisateur a également échoué à enregistrer les nouveaux paramètres du BIOS et a perdu la possibilité de démarrer à partir de l'USB. Tout d'abord, il a vérifié la séquence de démarrage EFI. Cela se fait avec la commande suivante:
efibootmgr -vDans son cas, la séquence de démarrage ressemblait à ceci:
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0002,2001,2002,2003
Boot0001* antergos_grub HD(1,GPT,f128f12b-fa3e-45b1-b5c9-f03c328498cb,0x800,0x64000)/File(\EFI\antergos_grub\grubx64.efi)
Boot0002* Windows Boot Manager HD(1,GPT,f128f12b-fa3e-45b1-b5c9-f03c328498cb,0x800,0x64000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)RC
Boot2001* EFI USB Device RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network RCIl s'ensuit que grubx64.efi du répertoire antergos_grub sera le premier à se charger de quelque manière que ce soit, et uniquement à partir du disque spécifié.
Il est logique de supposer que nous pouvons contrôler le téléchargement en modifiant le contenu du dossier antergos_grub. Il a simplement remplacé le contenu de ce dossier par le contenu du package du gestionnaire de téléchargement
rEFInd , renommant refind_x64.efi en grubx64.efi. Ensuite, après avoir chargé l'ordinateur portable, le menu de démarrage standard rEFInd apparaît.