Tu te souviens, je t'ai parlé d'un ordinateur portable foiré ? Eh bien, précisons, allons-nous. Je faisais des tests avec un logiciel d'imagerie et de récupération, et une fois que j'avais terminé, je voulais voir à quel point le processus s'était bien passé. Pas bien, il s'est avéré. GRUB était là, mais aucune entrée dans le menu ne fonctionnait initialement. Une fois que j'ai résolu ce problème rapidement, j'ai vu que Windows 10 ne démarrait pas et ne se réparait pas automatiquement, et la moitié des distributions sur le système (sur un total de huit) dans la configuration multi-démarrage ne démarrait pas non plus , passant en mode d'urgence. Nous parlons de la part complète des distributions, faites votre choix.
Maintenant, la récupération GRUB était assez délicate - aucune des méthodes auxquelles je pouvais penser ne fonctionnait, et j'ai fini par installer une distribution de test juste pour configurer correctement le chargeur de démarrage. Ensuite, j'ai démarré l'une des distributions qui fonctionnaient et j'ai remarqué qu'il n'y avait aucune perte de données. Tout était là, toutes les partitions étaient saines et entières, et les fichiers étaient à leur place, Linux et Windows inclus. Dans cet article, j'aimerais vous montrer comment j'ai résolu ce problème et comment je l'ai résolu - et dans la suite, nous ferons de même pour Windows 10. Un exercice utile. Suivez-moi.
Problème plus en détail
J'ai fait l'exercice suivant avec le néon comme entrée, mais il s'applique à presque toutes les distributions depuis environ 2011-2012. Donc, ce qui se passe, c'est que KDE neon commence à démarrer puis tombe dans le shell d'urgence. Le système me dit que je devrais exécuter journalctl -xb pour voir le journal de démarrage et comprendre ce qui n'allait pas. Maintenant, ce n'est pas la première fois que nous rencontrons cela. J'ai traité un problème similaire avec Fedora il n'y a pas si longtemps.
Mais ici, le problème était légèrement différent. Oui, le journal de démarrage a montré des problèmes avec /boot/efi, mais la raison pour laquelle cela s'est produit découle d'un autre problème. Si vous vous demandez comment j'ai obtenu et copié les journaux lors de la session d'urgence (si vous avez besoin de quelque chose comme ça), vous pouvez copier le contenu dans un fichier, puis le récupérer via une session en direct (avec redirect> ou en utilisant la commande tee ), ou une fois que vous avez résolu le problème, vous pouvez vider le dernier moins un journal avec journalctl -x --boot=-1. C'est la technologie moderne qu'il vous faut.
6 décembre 12:57:09 testeur systemd[1] :Échec de la dépendance pour la vérification du système de fichiers sur /dev/disk/
-- Objet :Unité systemd-fsck@dev-disk-by\x2duuid-641C\x2d39CE. le service a échoué
-- Defined-By :systemd
-- Support :http://www.ubuntu.com/support
--
-- Unit systemd-fsck@ dev-disk-by\x2duuid-641C\x2d39CE.service a échoué.
--
-- Le résultat est RÉSULTAT.
Déc 06 12:57:09 testeur systemd[1] :Échec de la dépendance pour /boot/efi.
-- Objet :L'unité boot-efi.mount a échoué
-- Défini par :systemd
-- Support :http://www.ubuntu.com/support
--
-- L'unité boot-efi.mount a échoué.
Solution
Je me demandais ce qui avait pu mal tourner. L'ensemble dev-disk-by était un gros indice. Vous vous souvenez quand je vous ai montré comment résoudre les problèmes de démarrage lent lorsque l'UUID de la partition d'échange a été modifié ? Cela ressemblait à cela, sauf que /boot/efi est essentiel dans le processus de démarrage du système.
J'ai ouvert /etc/fstab, et en effet, l'UUID répertorié pour la partition d'échange (dev/sda10) n'était PAS correct. Le fichier contient même un commentaire indiquant que l'entrée de la partition était le numéro de périphérique, puis elle a été remplacée par l'UUID prétendument "moderne" et "utile" qui ne fait que causer des problèmes.
# swap était sur /dev/sda10 lors de l'installation
UUID=8140c8d0-1e33-42c1-8c3c-828449adfe08 none swap swap 0 0
J'ai changé l'UUID en /dev/sda10, j'ai redémarré et tout était parfait !
Commandes dont vous aurez besoin pour le faire
Maintenant, ralentissons une seconde. C'est ainsi que vous pouvez vérifier si votre système utilise les bons numéros d'appareil ou identifiants. Tout d'abord, vous pouvez lister les partitions avec fdisk -l. Cette commande vous donnera un aperçu de toutes les différentes partitions et de leurs systèmes de fichiers. De cette façon, vous pouvez obtenir une compréhension de base de votre système. Notamment, vous avez besoin de la partition racine (/), vous pouvez avoir une partition /boot séparée, ce qui est souvent le cas sur les systèmes UEFI, vous pouvez utiliser un /home séparé, et vous pouvez également avoir une partition swap facultative et séparée. Ceux-ci seront marqués avec des numéros de périphérique, comme /dev/sda2, /dev/sda8, etc.
Le problème commence par la façon dont les versions plus récentes des distributions Linux mappent les périphériques dans /etc/fstab, un fichier qui est analysé au démarrage du système pour obtenir des informations sur les périphériques à monter automatiquement. Dans le passé, les périphériques étaient référencés comme le fait fdisk, dev/XdYZ, où X signifiait le type de disque (généralement des lettres h ou s), Y serait la lettre du périphérique (comme ordonné par le BIOS de votre système, par exemple a, b ou similaire), et Z serait le numéro de partition. Par exemple, /dev/sdb3 signifie la troisième partition sur le deuxième disque avec le type de connexion SATA/SCSI/PCI-E.
En effet, les distributions "modernes" utilisent UUID - il s'agit d'une chaîne de chiffres et de lettres sans signification humaine, quelque chose comme a45f-cc9a, destinée à mapper de manière unique les partitions, donc si l'ordre du disque est modifié d'une manière ou d'une autre, le système peut toujours démarrer. Cela a peut-être du sens dans l'entreprise, mais dans l'environnement domestique, c'est un non-sens absolu et complet - comme à peu près TOUTES les solutions "modernes", comme systemd, une nouvelle convention de dénomination d'interface réseau, de nouveaux outils de gestion de réseau, etc. Plus sur la philosophie plus tard.
Maintenant, si vous avez un mauvais UUID répertorié dans /etc/fstab, le système ne peut pas monter ces partitions - le mécanisme est super floconneux, car il n'a pas la capacité de vérifier, rechercher ou réparer une configuration cassée - vous pouvez vous retrouver avec un non amorçable système. Cette situation est également impossible à résoudre rapidement, car les chaînes UUID sont totalement inutiles pour les humains.
Vous pouvez vérifier la liste des UUID de l'appareil avec la commande blkid, par exemple :
blkid
/dev/mapper/sda3_crypt :UUID="TpZGKB-31Lq-U1Ap-BZJCcX" TYPE="LVM2_member"
/dev/mapper/kubuntu--vg-root :UUID="dcae17fd-7cfe -c0b721e" TYPE="ext4"
Vous devez comparer visuellement et ensuite déterminer ce qui manque. Et puis corrigez manuellement /etc/fstab.
Moderne, tu n'arrêtes pas d'utiliser ce mot...
La simple réalité est la suivante :je travaille avec Linux depuis plus de 15 ans. À un certain moment de ma vie, je gérais une belle configuration HPC avec environ 50 000 serveurs physiques répartis dans une quarantaine de centres de données. J'ai eu ma part de systèmes professionnels et domestiques, avec des technologies anciennes et nouvelles.
J'ai rencontré des systèmes défectueux principalement depuis que nous sommes passés de l'ancien BIOS + MBR + GRUB + init au nouveau UEFI + GPT + GRUB2 + systemd. Il n'y a rien de magique, de résilient ou d'amélioré dans ces solutions. Ils résolvent de véritables limitations techniques dans l'industrie, c'est vrai. Mais ils introduisent également une configuration beaucoup moins robuste qui est infiniment plus difficile à déboguer et à dépanner par les humains. Par exemple, je n'ai JAMAIS vu un système en panne parce que l'ordre des disques a été perturbé. Mais j'ai vu BEAUCOUP d'exemples de systèmes bloqués par l'utilisation de l'UUID au lieu de la simple notation du numéro de périphérique.
Réparer GRUB était une chose triviale consistant à copier 512 octets de données ici ou là dans le pire des cas et à éditer un fichier texte. Maintenant, c'est presque une religion scientifique d'accéder aux nouvelles interfaces, de travailler avec EFI et autres. Réparer le démarrage cassé de Linux n'était pas un problème, et maintenant, je dois analyser les journaux binaires en texte, puis comprendre pourquoi mes systèmes peuvent être bancaux, seulement pour découvrir que c'est parce que je suis obligé d'utiliser des "solutions " à des problèmes qui n'existent pas. Par exemple, la chose UUID. La chose ip contre ifconfig. Pourquoi enp0s0, ou quel que soit le nouvel identifiant de carte réseau, est meilleur ou plus intelligent ou plus intuitif que eth0 ? Utilisé pour être logique, ethernet =eth.
Quel est le scénario dans lequel les utilisateurs à domicile doivent fréquemment ajouter ou retirer des disques durs dans et hors de leurs boîtes ou jouer avec les paramètres du BIOS ? Ce n'est pas. Alors pourquoi les systèmes domestiques proposent-ils des solutions inadéquates ? Parce que Linux n'est intrinsèquement pas censé être une solution domestique, et je me sens comme un idiot.
Et ce n'est que le début. Au fil du temps, nous aurons plus d'abstraction, d'abstraction, d'abstraction, d'automatisation, de merde optimisée pour la machine, et vous devrez compter et dépendre de la merci de toute entité qui pompe son dernier Quoi que ce soit en tant que service. Il arrivera un moment où toute cette absurdité explosera, car elle ne peut pas être déboguée. Ou ce sera laissé aux machines de gérer par elles-mêmes, en utilisant leurs horribles protocoles que les humains n'ont jamais été censés voir ou expérimenter en premier lieu. En parlant de mauvaise conception.
Conclusion
Tout d'abord, j'espère que vous trouverez cet article utile. Dans la plupart des cas où un système Linux ne démarre pas, vous rencontrez probablement des problèmes avec, eh bien, quelque chose à voir avec /boot ou /boot/efi. Si cela se produit, vous devriez être un peu confiant en lisant les journaux, puis essayez de déterminer si vous avez des composants manquants ou cassés, comme je vous l'ai montré avec les bogues initrd et initramfs (liés ci-dessus), ou si la configuration du système est erronée. , et il essaie de référencer des ressources inexistantes. Dans notre cas, comme le problème de démarrage lent, l'utilisation de faux UUID pour les partitions était le coupable.
Cela devrait être résolu au niveau du système. Mais comme je l'ai noté à plusieurs reprises auparavant, la validation n'est tout simplement pas une chose sous Linux. Les développeurs font leur travail et passent à autre chose. Personne ne prend la peine de penser à la situation dans son ensemble, à la philosophie. Mais c'est la pensée logicielle :fonction -> sortie. Personne ne se soucie de ce qui vit en dehors de la fonction et encapsule la fonctionnalité.
Un système robuste examinerait en fait les périphériques et les systèmes de fichiers existants et essaierait de déterminer s'il y a un problème dans la configuration. Un système robuste aurait une sauvegarde des fichiers critiques et essaierait de les référencer. Un système robuste tenterait quelque chose de plusieurs manières différentes et corrélerait les choses avant d'échouer de manière significative. Rien de tout cela n'existe aujourd'hui, pas dans Linux ou dans tout autre système, car il est moins cher de maintenir une horde de techniciens pauvres que d'inventer des mécanismes intelligents d'auto-guérison. Et si cela vous arrive chez vous, eh bien vous n'êtes qu'un collatéral. Ainsi, lorsque les gens parlent de liberté et d'open source, ils parlent de la mauvaise chose. À quoi sert l'open source s'il est utilisé pour développer des solutions obfusquées ? Je suis triste. Je dois pleurer.