Ubuntu installé en mode BIOS, impossible d'accéder au BIOS

Question

Attendez une minute avant de signaler ceci hors sujet. Je n'arrive pas à croire que ce n'est pas lié à Ubuntu puisque tout s'est passé juste après mon installation d'Ubuntu.

Cela dit, je vais continuer à expliquer ce qui se passe:

J'ai téléchargé et installé la dernière version d'Ubuntu. Je voulais un mode BIOS puisque je préfère cette façon et a terminé le processus d'installation. Ensuite, j'ai installé GNOME et redémarré. J'ai perdu l'accès à ma biographie après tout cela.

Ce n'est pas la première fois que cela se produit. C'est arrivé dans le passé et j'ai résolu le problème de la commutation de partition de démarrage lors de la réparation de démarrage à l'aide de mon disque dur secondaire, mais je ne peux plus le faire car je n'ai pas de partition Windows sur ce disque.

Ceci est mon lecteur:

Disk /dev/sdb: 119,2 GiB, 128035676160 bytes, 250069680 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xcaa3841c Device Boot Start End Sectors Size Id Type /dev/sdb1 * 2048 250068991 250066944 119,2G 83 Linux

Lorsque j'ai essayé la réparation de démarrage, à la fin du processus, il était indiqué que je devais créer une partition de 500 Mo au début de la liste des partitions pour que grub puisse fonctionner correctement, mais voici un autre problème:

GParted a cessé de fonctionner. C'est l'erreur si j'essaye de le lancer:

Created symlink /run/systemd/system/-.mount → /dev/null. Created symlink /run/systemd/system/mnt-Archive.mount → /dev/null. Created symlink /run/systemd/system/mnt-Linux\x20Games.mount → /dev/null. Created symlink /run/systemd/system/run-user-1000.mount → /dev/null. Created symlink /run/systemd/system/tmp.mount → /dev/null. /usr/sbin/gpartedbin: error while loading shared libraries: libgtkmm-2.4.so.1: cannot open shared object file: No such file or directory Removed /run/systemd/system/-.mount. Removed /run/systemd/system/mnt-Archive.mount. Removed /run/systemd/system/mnt-Linux\x20Games.mount. Removed /run/systemd/system/run-user-1000.mount. Removed /run/systemd/system/tmp.mount.

Je veux mentionner que:

oui je suis sûr que j'utilise le bouton droit pour entrer dans le bios
non, il n'y a pas d'écran de démarrage du bios
non, rien ne se passe si je spamme le DEL clé pour entrer dans le bios
oui la clé fonctionne bien
oui j'ai essayé de débrancher chaque lecteur
oui j'ai essayé de réinitialiser CMOS
oui j'ai installé le système d'exploitation en mode BIOS, j'ai vérifié via un terminal.

Ceci est la sortie de boot-repair

Voici le message d'alerte indiquant que je dois créer une partition pour démarrer correctement:

Les fichiers de démarrage de [Le système d'exploitation actuellement utilisé - Ubuntu 17.04] sont loin du début du disque. Votre BIOS peut ne pas les détecter. Vous voudrez peut-être réessayer après avoir créé une partition /boot (EXT4,> 200 Mo, début du disque). Cela peut être effectué via des outils tels que gParted. Sélectionnez ensuite cette partition via l'option [Séparer/partition de démarrage:] de [Réparation du démarrage]. ( https://help.ubuntu.com/community/BootPartition )

Rod Smith · Answer

Depuis le passage du BIOS à EFI, j'ai constaté à de nombreuses reprises que les EFI refusaient de lancer leurs utilitaires de configuration. Je ne les ai pas suffisamment suivis pour reconnaître les modèles (disons, un fournisseur de microprogrammes spécifique ou une marque de carte mère/d'ordinateur pose-t-il plus de problèmes que d'autres?), Mais cela constitue certainement un bogue du microprogramme, et non un bogue du système d'exploitation. Cela dit, cela peut être déclenché par des modifications apportées par le système d'exploitation aux paramètres du micrologiciel, tels que la séquence d'amorçage. La chose inhabituelle dans votre cas est que vous avez effectué une installation BIOS/CSM/en mode hérité, ce qui signifie que l'installation du système d'exploitation n'aurait pas dû apporter de telles modifications. Mon hypothèse est que votre passage du mode EFI au démarrage en mode BIOS dans le micrologiciel lui-même a provoqué la manifestation du bogue; ou peut-être changer un autre paramètre du firmware l'a fait.

Il existe plusieurs façons de contourner ce problème, par exemple:

Vous pouvez débrancher votre disque dur et démarrer l'ordinateur. Cela provoque normalement le lancement de l'utilitaire d'installation.
Si vous démarrez Ubuntu en mode EFI (par exemple, le programme d'installation a été démarré de cette manière), taper Sudo systemctl reboot --firmware-setup dans un shell devrait redémarrer dans l'utilitaire de configuration du microprogramme.
Certains gestionnaires de démarrage en mode EFI (mais pas en mode BIOS) offrent une option permettant de démarrer dans l'utilitaire de configuration du microprogramme. GRUB a cette fonctionnalité, mais je ne sais pas si elle est activée par défaut dans Ubuntu, et comme vous utilisez la version en mode BIOS, ce point n'a plus de raison d'être. Vous pouvez cependant utiliser mon gestionnaire de démarrage rEFInd sur une clé USB ou un CD-R (des images de téléchargement sont disponibles pour à la fois sur la page à laquelle je viens de relier). L'option devrait apparaître sur la deuxième rangée d'icônes (plus petites). Vous pouvez également utiliser rEFInd pour démarrer votre installation habituelle en mode EFI et utiliser systemctl, si vous le souhaitez.

Notez que Boot Repair est très peu susceptible de résoudre le problème, car il est dû à des problèmes dans le firmware avant GRUB (ou autre chose fourni par Ubuntu) prend le contrôle de l’ordinateur.

Une fois que vous êtes dans l’utilitaire de configuration, l’utilisation de l’option permettant de réinitialiser le microprogramme à ses paramètres par défaut corrigera probablement le problème, mais je ne peux pas vous le promettre. En fonction de votre configuration, vous devez soit réactiver le CSM, soit ajouter un chargeur de démarrage en mode EFI sur le disque pour pouvoir redémarrer. L'une ou l'autre procédure risque au moins de recréer le problème.

Comme il s’agit d’un bogue du micrologiciel, il vaut la peine de rechercher une mise à jour du fabricant. S'il n'y a pas de mise à jour, je vous recommande de signaler le bogue; les fabricants ne peuvent pas réparer les bogues s'ils ne savent pas qu'ils existent.

Notez que ce cas illustre l'un des avantages du démarrage en mode EFI: il existe des moyens d'accéder à l'utilitaire de configuration du microprogramme à partir du gestionnaire de démarrage ou du système d'exploitation. Le démarrage en mode EFI est également un peu plus rapide, il est moins restrictif sur les gros disques (plus de 2 To), il prend en charge le démarrage sécurisé, il est le mode de démarrage natif sur le matériel moderne (ce qui signifie qu'il est moins susceptible de créer de la confusion, comme décrit sur - cette page est la mienne ), et présente quelques avantages mineurs par rapport au démarrage en mode BIOS. Pour ces raisons, je recommande généralement l’installation en mode EFI sur du nouveau matériel, à moins d’une raison impérieuse de procéder à une installation en mode BIOS.

Vous pouvez en toute sécurité ignorer la plainte concernant les fichiers de démarrage résidant loin du début du disque. Cela a été un problème récurrent avec les BIOS, avec la définition de "loin" changer avec le temps. Votre disque ne représente que 119,2 Gio, avec l'avertissement que vous avez indiqué pour /dev/sdb mais pas /dev/sda. Par conséquent, si /dev/sda est plus grand et que le chargeur de démarrage y est installé, cela pourrait poser problème. Sur la plupart des ordinateurs modernes, je m'attendrais à ce que le BIOS (ou le CSM d'EFI) puisse lire jusqu'à 2 To, donc tout disque de taille inférieure à ce devrait être OK.

Je soupçonne que vos problèmes GParted ne sont liés à rien d’autre, mais ils sont troublants. Ils pourraient indiquer un disque défaillant - mais il est plus probable que le système de fichiers soit corrompu de manière aléatoire, en particulier si l'ordinateur est en panne ou complètement en panne à un moment donné. Je vous recommande vivement de vous pencher là-dessus, mais comme je soupçonne que c'est une question distincte de votre problème principal, je ne donnerai pas de conseil à ce sujet ici.

1500822802299 · Answer

J'ai résolu le problème comme ceci:

C'était en effet un problème de partition lorsque j'ai installé Linux sur mon SSD pour la première fois. D'une manière ou d'une autre, Ubuntu pensait que c'était en mode UEFI même si je l'avais installé en mode Legacy (BIOS), de sorte qu'il recherchait la partition de démarrage avec grub. Lorsque j'ai cliqué sur "Tout effacer et installer" lors de la première installation de Linux, le programme d'installation n'a pas créé de partitions supplémentaires pour Ubuntu (c'est parce que j'ai effectivement démarré le lecteur d'installation en mode Legacy!).

Je suggère de faire une sauvegarde de votre disque et faire une installation propre.

Pour éviter les erreurs à l'avenir, utilisez le mode d'installation personnalisé, que vous installiez en mode UEFI ou Legacy (BIOS) importe peu:

Créer une nouvelle table de partitions supprimant toutes les partitions précédentes
Créez une partition principale supplémentaire de 500 Mo (à partir de l'espace libre) marquée comme 'partition EFI'
Allouez tout l'espace libre (si vous le souhaitez, vous pouvez laisser plus d'espace libre pour un espace d'échange) au système d'exploitation en le formatant en tant que partition primaire ext4 et en utilisant / comme point de montage.
Définissez le lecteur sur lequel vous avez créé la partition efi de 500 Mo en tant que chemin où Ubuntu peut installer grub (exemple: si votre lecteur est/dev/sda et que votre partition efi est/dev/sda2, choisissez toujours/dev/sda comme partition!)
Cliquez sur la plus grande partition que vous avez faite dans la liste et cliquez enfin sur Installer.