Erinnerst du dich, ich habe dir von einem kaputten Laptop erzählt? Nun, lassen Sie uns näher darauf eingehen. Ich habe einige Tests mit Bildbearbeitungs- und Wiederherstellungssoftware durchgeführt, und als ich fertig war, wollte ich sehen, wie gut der Prozess verlaufen war. Nicht gut, wie sich herausstellte. GRUB war da, aber zunächst funktionierte kein Eintrag im Menü. Nachdem ich das umgehend behoben hatte, sah ich, dass Windows 10 nicht booten und nicht automatisch reparieren würde, und die Hälfte der Distributionen auf dem System (von insgesamt acht) im Multi-Boot-Setup würde auch nicht starten , geht in den Notfallmodus. Wir sprechen über den vollen Anteil an Distributionen, treffen Sie Ihre Wahl.
Nun, die GRUB-Wiederherstellung war ziemlich knifflig – keine der Methoden, die mir einfielen, funktionierte, und ich endete damit, eine Testdistribution zu installieren, nur um den Bootloader richtig zu konfigurieren. Dann startete ich eine der Distributionen, die funktionierten, und stellte fest, dass es keinen Datenverlust gab. Alles war da, alle Partitionen waren sauber und vollständig, und die Dateien waren an ihrem richtigen Ort, einschließlich Linux und Windows. In diesem Artikel möchte ich Ihnen zeigen, wie ich dieses Problem angegangen bin und wie ich es behoben habe - und im Folgenden werden wir dasselbe für Windows 10 tun. Eine nützliche Übung. Folge mir.
Problem im Detail
Ich habe die folgende Übung mit Neon als Starter gemacht, aber sie gilt für so ziemlich jede Distribution seit ungefähr 2011-2012. Was also passiert ist, KDE neon beginnt zu booten und fällt dann in die Notfall-Shell. Das System sagt mir, ich solle journalctl -xb ausführen, um das Startprotokoll anzuzeigen und herauszufinden, was falsch war. Nun, das ist nicht das erste Mal, dass wir darauf stoßen. Ich habe vor nicht allzu langer Zeit ein ähnliches Problem mit Fedora behandelt.
Aber hier war das Problem etwas anders. Ja, das Boot-Protokoll zeigte Probleme mit /boot/efi, aber warum dies geschah, lag an einem anderen Problem. Wenn Sie sich fragen, wie ich die Protokolle in der Notfallsitzung erhalten und kopiert habe (falls Sie so etwas brauchen), können Sie den Inhalt in eine Datei kopieren und ihn dann über eine Live-Sitzung abrufen (mit Umleitung> oder mit dem Befehl tee). ), oder sobald Sie das Problem behoben haben, können Sie das letzte minus ein Protokoll mit journalctl -x --boot=-1 ausgeben. Das ist moderne Technologie für Sie.
Dez. 06 12:57:09 Tester systemd[1]:Abhängigkeit für Dateisystemprüfung auf /dev/disk/ fehlgeschlagen
-- Betreff:Unit systemd-fsck@dev-disk-by\x2duuid-641C\x2d39CE. Dienst ist fehlgeschlagen
-- Definiert von:systemd
-- Support:http://www.ubuntu.com/support
--
-- Unit systemd-fsck@ dev-disk-by\x2duuid-641C\x2d39CE.service ist fehlgeschlagen.
--
-- Das Ergebnis ist ERGEBNIS.
6. Dezember 12:57:09 Tester systemd[1]:Abhängigkeit für /boot/efi fehlgeschlagen.
-- Betreff:Unit boot-efi.mount ist fehlgeschlagen
-- Definiert von:systemd
-- Support:http://www.ubuntu.com/support
--
-- Unit boot-efi.mount ist fehlgeschlagen.
Lösung
Ich habe mich gefragt, was schief gelaufen sein könnte. Das ganze dev-disk-by war ein großer Hinweis. Erinnerst du dich, als ich dir gezeigt habe, wie man Probleme mit langsamem Booten behebt, wenn die UUID der Swap-Partition geändert wurde? Dies schien ganz so, außer dass /boot/efi im Systemstartprozess kritisch ist.
Ich habe /etc/fstab geöffnet, und tatsächlich war die aufgeführte UUID für die Swap-Partition (dev/sda10) NICHT korrekt. Die Datei hat sogar einen Kommentar, der besagt, dass der Partitionseintrag früher die Gerätenummer war und dann in den angeblich "modernen" und "hilfreichen" UUID-Unsinn geändert wurde, der nur Probleme verursacht.
# Auslagerung war während der Installation auf /dev/sda10
UUID=8140c8d0-1e33-42c1-8c3c-828449adfe08 keine Auslagerung Auslagerung 0 0
Ich habe das UUID-Zeug in /dev/sda10 geändert, neu gestartet und alles war pfirsichfarben!
Befehle, die Sie dazu benötigen
Lassen Sie uns jetzt eine Sekunde langsamer werden. So können Sie überprüfen, ob Ihr System die richtigen Gerätenummern oder Kennungen verwendet. Zunächst können Sie Partitionen mit fdisk -l auflisten. Dieser Befehl gibt Ihnen einen Überblick über alle verschiedenen Partitionen und ihre Dateisysteme. Auf diese Weise erhalten Sie ein grundlegendes Verständnis Ihres Systems. Insbesondere benötigen Sie die Root-Partition (/), Sie haben möglicherweise eine separate /boot-Partition, was häufig auf UEFI-Systemen der Fall ist, Sie verwenden möglicherweise ein separates /home und Sie haben möglicherweise auch eine optionale und separate Swap-Partition. Diese werden mit Gerätenummern gekennzeichnet, wie /dev/sda2, /dev/sda8 usw.
Das Problem beginnt damit, wie neuere Versionen von Linux-Distributionen Geräte in /etc/fstab abbilden, einer Datei, die beim Systemstart nach Informationen darüber geparst wird, welche Geräte automatisch gemountet werden sollen. In der Vergangenheit wurden die Geräte wie fdisk referenziert, dev/XdYZ, wobei X den Typ der Festplatte bezeichnet (normalerweise die Buchstaben h oder s), Y der Gerätebuchstabe war (wie von Ihrem System-BIOS angeordnet, z. B. a, b oder ähnlich), und Z wäre die Partitionsnummer. Zum Beispiel bedeutet /dev/sdb3 dritte Partition auf zweiter Festplatte mit dem Verbindungstyp SATA/SCSI/PCI-E.
Tatsächlich verwenden die "modernen" Distributionen UUID - dies ist eine für Menschen bedeutungslose Zeichenfolge aus Zahlen und Buchstaben, etwa a45f-cc9a, die Partitionen eindeutig zuordnen soll, sodass das System immer noch booten kann, wenn die Festplattenreihenfolge irgendwie geändert wird. Im Unternehmen vielleicht sinnvoll, aber in der Heimumgebung ist das absoluter und kompletter Unsinn - wie so ziemlich JEDE "moderne" Lösung, wie systemd, neue Namenskonvention für Netzwerkschnittstellen, neue Netzwerkverwaltungstools und so weiter. Mehr zur Philosophie später.
Nun, wenn Sie eine falsche UUID in /etc/fstab aufgelistet haben, kann das System diese Partitionen nicht mounten – der Mechanismus ist super labil, da er keine Möglichkeit hat, eine defekte Konfiguration zu überprüfen, zu suchen oder zu reparieren – Sie können am Ende nicht mehr bootfähig sein System. Diese Situation kann auch nicht schnell behoben werden, da die UUID-Strings für Menschen völlig nutzlos sind.
Sie können die Liste der Geräte-UUID mit dem blkid-Befehl überprüfen, zum Beispiel:
blkid
/dev/mapper/sda3_crypt:UUID="TpZGKB-31Lq-U1Ap-BZJCcX" TYPE="LVM2_member"
/dev/mapper/kubuntu--vg-root:UUID="dcae17fd-7cfe -c0b721e" TYPE="ext4"
Sie müssen visuell vergleichen und dann herausfinden, was fehlt. Und dann /etc/fstab manuell reparieren.
Modern, du verwendest immer wieder dieses Wort ...
Die einfache Realität sieht so aus:Ich arbeite seit mehr als 15 Jahren mit Linux. Irgendwann in meinem Leben arbeitete ich an einem schönen HPC-Setup mit ungefähr 50.000 physischen Servern, die über etwa 40 Rechenzentren verteilt waren. Ich hatte meinen Anteil an Geschäfts- und Heimsystemen mit alten und neuen Technologien.
Ich bin meistens auf kaputte Systeme gestoßen, seit wir vom alten BIOS + MBR + GRUB + init auf das neue UEFI + GPT + GRUB2 + systemd umgestiegen sind. Diese Lösungen haben nichts Magisches, Belastbares oder Verbessertes. Sie lösen einige echte technische Einschränkungen in der Branche, das stimmt. Aber sie führen auch ein weitaus weniger robustes Setup ein, das von Menschen unendlich schwerer zu debuggen und Fehler zu beheben ist. Zum Beispiel habe ich NIE ein kaputtes System gesehen, weil die Festplattenreihenfolge durcheinander geraten ist. Aber ich habe VIELE Beispiele von Systemen gesehen, die durch die Verwendung von UUID anstelle der einfachen Notation der Gerätenummer kaputt gegangen sind.
Das Reparieren von GRUB war eine triviale Sache, im schlimmsten Fall 512 Byte Daten hier oder dort zu kopieren und eine Textdatei zu bearbeiten. Jetzt ist es fast wissenschaftliche Religion, auf die neuen Schnittstellen zuzugreifen, mit EFI und so zu arbeiten. Das Reparieren eines fehlerhaften Linux-Startvorgangs war kein Problem, und jetzt muss ich Binärprotokolle in Text zerlegen und dann herausfinden, warum meine Systeme möglicherweise wackelig sind, nur um herauszufinden, dass alles daran liegt, dass ich gezwungen bin, "Lösungen" zu verwenden „zu Problemen, die es nicht gibt. Zum Beispiel die UUID-Sache. Die Sache mit IP und ifconfig. Warum ist enp0s0, oder was auch immer die neue Netzwerkkartenkennung sein mag, besser oder intelligenter oder intuitiver als eth0? War früher logisch, ethernet =eth.
Was ist das Szenario, in dem Heimanwender häufig Festplatten in ihre Boxen hinzufügen oder entfernen oder mit BIOS-Einstellungen spielen müssen? Es ist nicht. Warum kommen Heimsysteme mit Lösungen, die unzureichend sind? Weil Linux von Natur aus nicht als Heimlösung gedacht ist und ich mich wie ein Idiot fühle.
Und das ist erst der Anfang. Mit der Zeit werden wir mehr Abstraktion, Abstraktion, Abstraktion, Automatisierung, maschinenoptimierten Mist haben, und Sie werden sich auf die Gnade der Entität verlassen müssen, die ihr neuestes Whatever as a Service herauspumpt. Irgendwann explodiert dieser ganze Unsinn, weil er nicht debuggt werden kann. Oder es wird den Maschinen überlassen, sich selbst zu verwalten, indem sie ihre hässlichen Protokolle verwenden, die Menschen nie sehen oder überhaupt erleben sollten. Apropos schlechtes Design.
Schlussfolgerung
Zunächst hoffe ich, dass Sie diesen Artikel nützlich finden. In den meisten Fällen, in denen ein Linux-System nicht bootet, haben Sie wahrscheinlich Probleme mit etwas, das mit /boot oder /boot/efi zu tun hat. Wenn das passiert, sollten Sie sich beim Lesen der Protokolle einigermaßen sicher sein und dann versuchen herauszufinden, ob Sie fehlende oder defekte Komponenten haben, wie ich Ihnen mit den initrd- und initramfs-Bugs (oben verlinkt) gezeigt habe, oder ob die Systemkonfiguration falsch ist , und es wird versucht, auf nicht vorhandene Ressourcen zu verweisen. In unserem Fall war, wie beim Problem mit dem langsamen Booten, die Verwendung einer falschen UUID für Partitionen der Übeltäter.
Dies sollte auf Systemebene gelöst werden. Aber wie ich schon oft angemerkt habe, ist Validierung unter Linux einfach keine Sache. Entwickler machen ihr Ding und machen weiter. Niemand macht sich die Mühe, über das große Ganze nachzudenken, über Philosophie. Aber das ist Softwaredenken:Funktion -> Ausgabe. Niemand kümmert sich darum, was außerhalb der Funktion lebt und die Funktionalität kapselt.
Ein robustes System würde tatsächlich die vorhandenen Geräte und Dateisysteme untersuchen und versuchen herauszufinden, ob es ein Problem in der Konfiguration gibt. Ein robustes System hätte ein Backup der kritischen Dateien und würde versuchen, darauf zu verweisen. Ein robustes System würde etwas auf verschiedene Arten versuchen und Dinge korrelieren, bevor es auf sinnvolle Weise versagt. Nichts davon existiert heute, nicht in Linux oder irgendeinem anderen System, weil es billiger ist, eine Horde armer Techniker zu unterhalten, als intelligente Selbstheilungsmechanismen zu erfinden. Und wenn Ihnen das zu Hause passiert, dann sind Sie nur eine Sicherheit. Wenn Leute also über Freiheit und Open Source sprechen, sprechen sie über das Falsche. Wozu ist Open Source gut, wenn es zur Entwicklung verschleierter Lösungen verwendet wird? Ich bin traurig. Los, ich muss heulen.