Update, seitdem wird booten verhindert
Hi, * Opensuse, Mo, 11.04. früh, Update eingespielt. (erfolgt täglich morgens) Bei der abendlichen Sicherung dann abgestützt. Seitdem: Systemneustart nicht mehr möglich. Rettung nur durch Neuinstallation Inzwischen nun auf mehreren Rechnern bzw. Neuinstallationen. Reproduzierbar! Irgendwann hatte ich gelernt bzw. mir angelesen: Zu einer "ordentlichen" Sicherung unter Linux gehören: /etc, /var und /home. (Zu fragen wäre, ob /etc bzw. /var überhaupt gebraucht werden) Mein Sicherungsskript (bash), läuft täglich oder mehrmals wöchentlich, ist in den Ursprüngen vermutlich schon aus dem letzten Jahrhundert(!), ist aber immer wieder erweitert und angepasst worden. Die entscheidende ("abstürzende") Stelle sieht so aus: cd /etc tar cvWf etc_`date +%y%m%d%H%M%S`.tar * Im Ergebnis dann im Sekundenabstand die ständig wiederholte Mitteilung: kann /etc/mtab nicht öffnen (mtab ist ein link; / und /home liegen in unterschiedlichen Partitionen) Nach Abbruch und versuchtem Neustart: Booten nicht möglich, weil Dbus nicht startbar (oder in einem Fall auch: havedged nicht startbar). Vll. wären Profis nie auf die Idee gekommen, das Verzeichnis, in dem "man" "sitzt", zu taren, aber bis So, 10.04. ist das nie als Fehler "erkannt" worden und immer einwandfrei "durchgelaufen" und hatte nach mv und gz eine Größe von ~ 4 MB. Als Lösung für die Sicherung setze "ich" mich nun in ein anderes Verzeichnis, aber muss dann auf das W beim taren verzichten??! Sind meine Gedanken/Schlußfolgerungen so richtig? Welche Änderungen könnten im Update zu diesem Ergebnis geführt haben? Mit freundlichen Grüßen Frank p.s. opensuse leap 15.3, alle Rechner/Neuinstallationen auf aktuellem Stand. d.o.
Am 19.04.22 um 21:39 schrieb eilf:
Hi, *
Opensuse, Mo, 11.04. früh, Update eingespielt. (erfolgt täglich morgens)
Bei der abendlichen Sicherung dann abgestützt.
Seitdem: Systemneustart nicht mehr möglich.
Rettung nur durch Neuinstallation
Inzwischen nun auf mehreren Rechnern bzw. Neuinstallationen.
Reproduzierbar!
Irgendwann hatte ich gelernt bzw. mir angelesen: Zu einer "ordentlichen" Sicherung unter Linux gehören: /etc, /var und /home. (Zu fragen wäre, ob /etc bzw. /var überhaupt gebraucht werden)
Mein Sicherungsskript (bash), läuft täglich oder mehrmals wöchentlich, ist in den Ursprüngen vermutlich schon aus dem letzten Jahrhundert(!), ist aber immer wieder erweitert und angepasst worden.
Die entscheidende ("abstürzende") Stelle sieht so aus:
cd /etc tar cvWf etc_`date +%y%m%d%H%M%S`.tar *
Im Ergebnis dann im Sekundenabstand die ständig wiederholte Mitteilung: kann /etc/mtab nicht öffnen (mtab ist ein link; / und /home liegen in unterschiedlichen Partitionen)
Nach Abbruch und versuchtem Neustart: Booten nicht möglich, weil Dbus nicht startbar (oder in einem Fall auch: havedged nicht startbar).
Vll. wären Profis nie auf die Idee gekommen, das Verzeichnis, in dem "man" "sitzt", zu taren, aber bis So, 10.04. ist das nie als Fehler "erkannt" worden und immer einwandfrei "durchgelaufen" und hatte nach mv und gz eine Größe von ~ 4 MB.
Als Lösung für die Sicherung setze "ich" mich nun in ein anderes Verzeichnis, aber muss dann auf das W beim taren verzichten??!
Sind meine Gedanken/Schlußfolgerungen so richtig? Welche Änderungen könnten im Update zu diesem Ergebnis geführt haben?
Mit freundlichen Grüßen
Frank
p.s. opensuse leap 15.3, alle Rechner/Neuinstallationen auf aktuellem Stand. d.o.
Hi, Dein Problem liegt vermutlich genau darin: "kann /etc/mtab nicht öffnen", denn das sollte mit dem von Dir geposteten Script nicht so sein, bei mir läuft Dein Script fehlerfrei durch und in der etc....tar finde ich dann mtab als unaufgelösten Link auf "../proc/self/mounts", was ja korrekt ist. Irgendwas hat Dir die mtab bzw. die Partitionen, die vom System gemountet werden, verpfuscht, deshalb bootet es auch nicht mehr. Ein guter Kandidat ist die /etc/fstab, wenn da Mist steht, findet er keine/falsche Partitionen. Es ist auch egal, wo Du den tar-Befehl laufen lässt, es schadet definitiv nicht, es in /etc zu tun ... wenn Du die .tar dann woanders hin verschiebst ;-) Ich kann mir nicht vorstellen, dass ein Update allein das verursachen soll, dass die Partitionen nicht korrekt gemountet werden, hast Du mehrere physikalische Platten und / oder /boot oder / an einer ungewöhnlichen Stelle der Platte(n)? Wenn Du mittels Rettungssystem oder Knoppix oder so rankommst, kannst Du ja mal nachsehen, was in der /etc/fstab steht und ob die anders ist, als in Deinem Backup. Du kannst sie ja dann auch mal durch die gesicherte ersetzen. Wenn Du im Rettungssystem oder Knoppix... bist, siehst Du ja auch, ob Deine Partitionen korrekt erkannt werden (lsscsi, fdisk -l)... hth -- cu jth
Am Mittwoch, 20. April 2022, 07:46:54 CEST schrieb Jörg Thümmler: Hi, Jörg, Hi, Ulf, danke für eure schnelle Antworten
Irgendwas hat Dir die mtab bzw. die Partitionen, die vom System gemountet werden, verpfuscht, deshalb bootet es auch nicht mehr. Ein guter Kandidat ist die /etc/fstab, wenn da Mist steht, findet er keine/falsche Partitionen.
das sind jedesmal Standardinstallationen mit/von Suse.
Es ist auch egal, wo Du den tar-Befehl laufen lässt, es schadet definitiv nicht, es in /etc zu tun ... wenn Du die .tar dann woanders hin verschiebst ;-)
gut zu wissen (aber führt zum wiederholten Male zum Absturz und das will ich mir im Moment (noch nicht wieder) antun.
Ich kann mir nicht vorstellen, dass ein Update allein das verursachen soll, dass die Partitionen nicht korrekt gemountet werden, hast Du mehrere physikalische Platten und / oder /boot oder / an einer ungewöhnlichen Stelle der Platte(n)?
Wenn Du mittels Rettungssystem oder Knoppix oder so rankommst, kannst Du ja mal nachsehen, was in der /etc/fstab steht und ob die anders ist, als in Deinem Backup. Du kannst sie ja dann auch mal durch die gesicherte ersetzen. Wenn Du im Rettungssystem oder Knoppix... bist, siehst Du ja auch, ob Deine Partitionen korrekt erkannt werden (lsscsi, fdisk -l)...
Mit Rettungssystem, Recovery, Knoppix usw. war ich nicht so erfolgreich. (Vll. z. T. auch auf mein mangelndes Wissen zurückzuführen.) Beide Rechner sind inzwischen (z. T. mehrfach) neuinstalliert. (Die Neuinstallation geht ja inzwischen ganz schön schnell. Aber die Vor- (UEFI/BIOS-Umstellungen) und Nachbereitungen (weitere Repos, Zusatzprogramme, Einbindung von Geräten und vll. auch individuelle Einstellungen) sind immer sehr aufwändig.) Eine Veränderung wird von mir an fstab nicht vorgenommen. (So eine Operation "am offenen Herzen" trau ich mir gar nicht zu.) Im Moment bin ich noch etwas ratlos; die Zeilen zur /etc-Sicherung sind im Moment auskommentiert. Frank
Am 20.04.22 um 10:43 schrieb eilf:
Am Mittwoch, 20. April 2022, 07:46:54 CEST schrieb Jörg Thümmler:
Hi, Jörg, Hi, Ulf,
danke für eure schnelle Antworten
Irgendwas hat Dir die mtab bzw. die Partitionen, die vom System gemountet werden, verpfuscht, deshalb bootet es auch nicht mehr. Ein guter Kandidat ist die /etc/fstab, wenn da Mist steht, findet er keine/falsche Partitionen.
das sind jedesmal Standardinstallationen mit/von Suse.
Es ist auch egal, wo Du den tar-Befehl laufen lässt, es schadet definitiv nicht, es in /etc zu tun ... wenn Du die .tar dann woanders hin verschiebst ;-)
gut zu wissen (aber führt zum wiederholten Male zum Absturz und das will ich mir im Moment (noch nicht wieder) antun.
Ich kann mir nicht vorstellen, dass ein Update allein das verursachen soll, dass die Partitionen nicht korrekt gemountet werden, hast Du mehrere physikalische Platten und / oder /boot oder / an einer ungewöhnlichen Stelle der Platte(n)?
Wenn Du mittels Rettungssystem oder Knoppix oder so rankommst, kannst Du ja mal nachsehen, was in der /etc/fstab steht und ob die anders ist, als in Deinem Backup. Du kannst sie ja dann auch mal durch die gesicherte ersetzen. Wenn Du im Rettungssystem oder Knoppix... bist, siehst Du ja auch, ob Deine Partitionen korrekt erkannt werden (lsscsi, fdisk -l)...
Mit Rettungssystem, Recovery, Knoppix usw. war ich nicht so erfolgreich. (Vll. z. T. auch auf mein mangelndes Wissen zurückzuführen.)
Beide Rechner sind inzwischen (z. T. mehrfach) neuinstalliert. (Die Neuinstallation geht ja inzwischen ganz schön schnell. Aber die Vor- (UEFI/BIOS-Umstellungen) und Nachbereitungen (weitere Repos, Zusatzprogramme, Einbindung von Geräten und vll. auch individuelle Einstellungen) sind immer sehr aufwändig.)
Eine Veränderung wird von mir an fstab nicht vorgenommen. (So eine Operation "am offenen Herzen" trau ich mir gar nicht zu.)
Im Moment bin ich noch etwas ratlos; die Zeilen zur /etc-Sicherung sind im Moment auskommentiert.
Frank
Hallo, nur so ein Schuss ins Blaue: ich weiß nicht so recht, was ein "tar cvWf" macht, wenn es solche scheiternden Symlinks, wie den von /etc/mtab trifft, bei mir, wie gesagt, anscheinend nix (mal sehen, ob er morgen früh noch bootet). Evt. kannst Du auch mit "-h" den "echten" Inhalt einschließen, aber wozu... Ich würde solche Dateien evt. ausschließen (--exclude-from=FILE)... Eigentlich würde das aber auch nicht wirklich eine Erklärung liefern. Hat Dein script evt. im Umfeld noch "verdächtige" Zeilen? -- cu jth
Am Di., 19. Apr. 2022 um 21:39 Uhr schrieb eilf <eilfh156@posteo.de>:
Bei der abendlichen Sicherung dann abgestützt.
Seitdem: Systemneustart nicht mehr möglich.
Dein *Backup* macht das System kaputt? Srsly?
Rettung nur durch Neuinstallation
Neuinstallation sollte nicht nötig sein. Das ist nicht Windows.
Als Lösung für die Sicherung setze "ich" mich nun in ein anderes Verzeichnis, aber muss dann auf das W beim taren verzichten??!
Vermutlich. Wenn Du mehr Hilfe willst, poste das Script. Für Backups von Linuxsystemen gibt es bewährte Lösungen. Gruß Martin
Am Mittwoch, 20. April 2022, 12:34:14 CEST schrieb Martin Schröder: Hallo, Martin
Dein *Backup* macht das System kaputt? Srsly?
In meinem Script ist nichts aufregendes, aber vermutlich nicht alles DIN-gerecht! ich setz mich nacheinander in cd /etc bzw. cd /var und /home (dort allerdings nur in ausgewählte Verzeichnisse) tar mit cvWf bzw. exclude Verzeichnisse (exclude nicht in /etc) und mit mv dann alle in ein gemeinsames Verzeichnis gebracht und dann dort g(e)zip(pt). Auf beiden Rechnern (und auch nach den Neuinstallationen) kommt (kam) __nach__ dem taren im Sekundentakt ein Fenster mit der Mitteilung: mtab nicht lesbar (mtab ist ein link, / und /home liegen (auf beiden Rechner) auf unterschiedlichen Partitionen. System hart beendet! Nächster Neustart beim booten: kann nicht booten, weil dbus nicht startet (bzw. in einem Fall haveged o.ä) (In dieser Reihenfolge nach mehreren Installationen bzw. auf beiden Rechnern) Meine Versuche mit recovery, Rettung (auch Knoppix) waren (vermutl. meiner Unkenntnis geschuldet) nicht erfolgreich. Als das dann das dritte Mal (Neuinstallationen) auftrat (inzwischen auch auf einem anderen Rechner) hab ich das Script abschnittsweise gestartet. Da konnte ich sehen, das es eindeutig unmittelbar nach dem taren von /etc auftrat. Die anderen Teile laufen unverändert durch. Die letzten Sicherungen von /etc sind von sa/so, 09./10.04. Erster Absturz: Mo, abend, beim (ersten) täglichen Sicherungslauf (nach dem update). Danach nicht mehr bootbar. Im Moment laufen beide Rechner (ohne Sicherung von /etc). Das Vor- bzw. vorallem aber das Nachbereiten (Anpassen) der Installation ist allerdings mit reichlich Aufwand verbunden. Frank
Am Mi., 20. Apr. 2022 um 18:30 Uhr schrieb eilf <eilfh156@posteo.de>:
ich setz mich nacheinander in cd /etc bzw. cd /var und /home (dort allerdings nur in ausgewählte Verzeichnisse) tar mit cvWf bzw. exclude Verzeichnisse (exclude nicht in /etc) und mit mv dann alle in ein gemeinsames Verzeichnis gebracht und dann dort g(e)zip(pt).
Laß das --verify weg (ist IMHO eh unnötig). Der überschreibt ja dabei wohl archivierte Symlinks.
Auf beiden Rechnern (und auch nach den Neuinstallationen) kommt (kam) __nach__ dem taren im Sekundentakt ein Fenster mit der Mitteilung: mtab nicht lesbar (mtab ist ein link, / und /home liegen (auf beiden Rechner) auf unterschiedlichen Partitionen.
Ist /etc/mtab danach noch ein Symlink auf ../proc/self/mounts ?
kann nicht booten, weil dbus nicht startet (bzw. in einem Fall haveged o.ä) (In dieser Reihenfolge nach mehreren Installationen bzw. auf beiden Rechnern)
Vermutlich würde ein Löschen von /etc/mtab und ein reboot reichen... Gruß Martin
Am Mittwoch, 20. April 2022, 18:58:31 CEST schrieb Martin Schröder: Hallo, Martin Danke für Deine Hinweise
Laß das --verify weg (ist IMHO eh unnötig). Der überschreibt ja dabei wohl archivierte Symlinks.
Versuch ich bei nächster Gelegenheit (Dumme Frage: Ist das Überschreiben erst neuerdings so? -- bisher "lief" das ohne "Beanstandung" durch)
Ist /etc/mtab danach noch ein Symlink auf ../proc/self/mounts ?
Ist mir nicht gelungen, dass zu testen, da ich ja den/die Rechner nicht mehr starten konnte und ich bisher den Ausweg nur in einer Neuinstallation gesehen habe.
Vermutlich würde ein Löschen von /etc/mtab und ein reboot reichen...
Im laufenden Betrieb? Da läuft ein Stakkato von "Fehlerfenstern" !! ... und falls ja: startet und läuft der dann auch ohne /etc/mtab? Frank
Am Mi., 20. Apr. 2022 um 21:11 Uhr schrieb eilf <eilfh156@posteo.de>:
Am Mittwoch, 20. April 2022, 18:58:31 CEST schrieb Martin Schröder:
Ist /etc/mtab danach noch ein Symlink auf ../proc/self/mounts ?
Ist mir nicht gelungen, dass zu testen, da ich ja den/die Rechner nicht mehr starten konnte und ich bisher den Ausweg nur in einer Neuinstallation gesehen habe.
Naja, ich hätte halt erstmal ein Livesystem gestartet und mir die Partition angesehen.
Vermutlich würde ein Löschen von /etc/mtab und ein reboot reichen...
Im laufenden Betrieb? Da läuft ein Stakkato von "Fehlerfenstern" !! ... und falls ja: startet und läuft der dann auch ohne /etc/mtab?
Das ist ein Symlink, der vermutlich bei der Installation von mount angelegt wird. Zur Not auf der Konsole einloggen und löschen & neu anlegen. Ansonsten: - man 8 mount - https://askubuntu.com/q/754091/62688 Achja: Das "Stakkato von Fehlerfenstern" ignorieren und mit journalctl ansehen, was eigentlich kaputt ist. Und: Du legst anscheinend das Backup-tar in /etc an. Ganz böse. Mach das woanders. Gruß Martin
On 20.04.22 21:11, eilf wrote:
Am Mittwoch, 20. April 2022, 18:58:31 CEST schrieb Martin Schröder: Hallo, Martin
Danke für Deine Hinweise
Laß das --verify weg (ist IMHO eh unnötig). Der überschreibt ja dabei wohl archivierte Symlinks.
Versuch ich bei nächster Gelegenheit
(Dumme Frage: Ist das Überschreiben erst neuerdings so? -- bisher "lief" das ohne "Beanstandung" durch)
Die tar Version ist schon länger nicht mehr geändert worden. ulf@leap153-p330:~> rpm -qi tar |grep "Build Date" Build Date : Fr 18 Jun 2021 12:30:49 CEST Ich interpretiere das 'wohl' in Matrins Aussage so, dass das nur eine Theorie ist. Die ich nicht teile.
Ist mir nicht gelungen, dass zu testen, da ich ja den/die Rechner nicht mehr starten konnte und ich bisher den Ausweg nur in einer Neuinstallation gesehen habe.
Ich dachte, Du könntest Dein Problem reproduzieren? Viele Grüße Ulf
Am 20.04.22 um 22:08 schrieb Ulf Volmer:
On 20.04.22 21:11, eilf wrote:
Am Mittwoch, 20. April 2022, 18:58:31 CEST schrieb Martin Schröder: Hallo, Martin
Danke für Deine Hinweise
Laß das --verify weg (ist IMHO eh unnötig). Der überschreibt ja dabei wohl archivierte Symlinks.
Versuch ich bei nächster Gelegenheit
(Dumme Frage: Ist das Überschreiben erst neuerdings so? -- bisher "lief" das ohne "Beanstandung" durch)
Die tar Version ist schon länger nicht mehr geändert worden.
ulf@leap153-p330:~> rpm -qi tar |grep "Build Date" Build Date : Fr 18 Jun 2021 12:30:49 CEST
Ich interpretiere das 'wohl' in Matrins Aussage so, dass das nur eine Theorie ist. Die ich nicht teile.
... Hi, also bei mir (aber das ist hier 15.1) ist das gestern in /etc und mit W korrekt durchgelaufen und hat mir ein tar-Archiv in /etc angelegt. Und danach hat das System heut nacht ganz normal rebootet. Ja, ich würde auch kein Backup in /etc erzeugen, aber prinzipiell ist das kein Problem. ich sehe auch gar nicht so recht, warum ein "verify" von "außen" nicht gehen soll, musst Du halt mit "P" die absoluten Pfade archivieren, wenn Du es für vollständiges Rücklesen brauchst, ist das eh ok, ansonsten kannst Du mit chroot oder mit den tar-Optionen --strip-components=NUMBER Strip NUMBER leading components from file names on extraction. --transform=EXPRESSION, --xform=EXPRESSION Use sed replace EXPRESSION to transform file names. auch den störenden / beim Entpacken entfernen lassen. Wenn Du z.B. mit mc in so ein Archiv gehst, kannst Du eh jede Datei einzeln rauskopieren, die Du brauchst. Ich kann mir aber nach wie vor nicht vorstellen, wie ein "verify" einen /etc/mtab-Symlink zerstört... -- cu jth
participants (4)
-
eilf -
Jörg Thümmler -
Martin Schröder -
Ulf Volmer