Nach dem Linux Mint 21-Login nur im Lesemodus!

[Yannik H]

Liebe Linuxfreunde,

seit 2008 nutze ich Linux (anfangs Ubuntu, aber seit 10 Jahren Mint), meistens im Dual-Boot mit Windows 8.1 oder inzwischen 10.
Ich habe am 22.4. in meinem Tripel-Boot-System (AMD FX6300. mit Mint 20.3, Mint 21, Windows 8.1) kürzlich von Mint 20.3 auf 21 upgegraded. Es ist zwar alles soweit gut gelaufen und das System lief 3 Tage, aber dafür komme ich seit einer Woche nicht mehr in den Schreibmodus auf der Partition. Beim Starten einiger Programme wie Firefox gibt es Probleme, dort hauptsächlich bei der Cookie-Abfrage. LibreOffice stürzt nach dem Start sofort ab. Ursprünglich hatte ich nur Mint 20.0 und Win 8.1 drauf. Dann habe ich mit Paragon Mint 20 geklont vor 3 Jahren. Seitdem hatte ich Tripel-Boot. Erst in den letzten Monaten musste ich feststellen, dass Timeshift viel Plattenplatz auffrisst. Ich hatte vorher von dem Programm noch nie was gehört. Habe mich in die Probleme damit in den letzten Wochen etwas eingelesen. Es kommt die Meldung, dass auf der Platte 0Bytes frei sind, und ob ich was unternehmen will. Z.B. Papierkorb löschen. Das macht er auch scheints, aber letztlich ändert sich nix, der Papierkorb wird nie gelöscht, so oft ich das auch klicke.
Was soll ich machen, dass das eigentliche System auf die eigenen Daten wieder Zugriff bekommt?

Vielen Dank für Eure Hilfe!

 

[josef-wien]

Das sind etwas wenig Informationen um zu helfen.

Timeshift

Meinst Du GitHub - teejee2008/timeshift: System restore tool for Linux. Creates filesystem snapshots using rsync+hardlinks, or BTRFS snapshots. Supports scheduled snapshots, multiple backup levels, and exclude filters. Snapshots can be restored while system is running or from Live CD/USB. oder TimeShift – Wikipedia

Treten die Probleme bei beiden Linux-Systemen auf?

Welche Dateisysteme verwenden Deine Linux-Systeme?

Kannst Du Dich im grafischen Modus anmelden? Oder kommst Du nur in den Textmodus?

Kannst Du mit journalctl umgehen?

 

[susejunky]

Hallo @Yannik H ,

herzlich willkommen im Linux-Club-Forum.

Ursprünglich hatte ich nur Mint 20.0 und Win 8.1 drauf. Dann habe ich mit Paragon Mint 20 geklont vor 3 Jahren.

Ich verstehe zwar nicht, was Du da genau gemacht hast, aber falls Du eine Bit-identische Kopie einer Partition Deines Systems erzeugt hast und diese dann auf einer weiteren Partition Deines Systems eingespielt und unverändert in Betrieb genommen hast, dann ist das ein riskantes Unterfangen.

Jede Partition (und auch jedes Dateisystem) eines Systems wird bei der Erstellung mit einer eindeutigen Kennung versehen (UUID). Wenn Du eine Bit-identische Kopie einer Partition im selben System betreibst, dann kann das zu Problemen führen, da die UUIDs (der Partition und des Dateisystems) dann doppelt vorhanden sind.

Bitte zeige das Ergebnis von

blkid

(als Benutzer "root" in einer Konsole ausführen).

Falls Du keines Deiner installierten Linux-Systeme mehr starten kannst, nutze ein LIVE-System dafür.

Viele Grüße

susejunky

 

[susejunky]

Hallo @Yannik H ,

Z.B. Papierkorb löschen. Das macht er auch scheints, aber letztlich ändert sich nix, der Papierkorb wird nie gelöscht, so oft ich das auch klicke

Bei der Verwendung von btrfs und snapshots ist zu beachten, dass eine Datei erst dann wirklich vollständig gelöscht werden kann, wenn kein snapshot mehr existiert, der diese Datei beinhaltet.

Bezüglich Hardlinks ist zu beachten, dass eine Datei erst dann tatsächlich gelöscht wird, wenn der letzte Hardlink gelöscht wird.

Viele Grüße

susejunky

 

[abgdf]

Mit anderen Worten: Neu-installieren!

 

[Yannik H]

Hallo!
Vielen Dank für Eure Antworten.

@susejunky
Also jetzt wird mir auch klar warum manchmal das eine System startet obwohl ich genau das andere wollte.... nach der Auswahl des Dualboots der Linux Partitionen. Den Nur-Lese-Modus habe ich nur bei der V-Partition. Ich nenne sie so, weil ich da als Background das Vulkan-Motiv habe. Das andere nenne ich M-Partition. Letztere ist sda12, die V-Partition ist sda7.

@josef-wien: Ich meine das Snapshot-Programm von Linux.

hier mein blkid:

...:~$ blkid
/dev/sda1: LABEL="Wiederherstellung" UUID="B0749ABD749A85AE" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="de3fe532-ed0c-43e4-b768-35d58b0e17f8"
/dev/sda2: UUID="10A2-5730" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="b3cb187d-52ba-4e89-875d-26a93f572ac8"
/dev/sda3: UUID="3BD8-EB64" TYPE="vfat" PARTUUID="67b812dd-4885-4bb8-b6e4-1b1a3152b065"
/dev/sda4: UUID="6212E11612E0F049" TYPE="ntfs" PARTLABEL="H1" PARTUUID="181be59b-1d48-47c0-8ec1-c418454d5002"
/dev/sda5: UUID="282eb289-158e-4428-ae9e-4efdceb4022d" TYPE="ext4" PARTUUID="13f81a44-d147-45b0-934a-dff7c9380904"
/dev/sda6: UUID="57249AAA217BAE16" TYPE="ntfs" PARTUUID="8d882eed-0d7b-49f0-94ed-0cf649e74279"
/dev/sda7: UUID="81a886c4-1012-447a-8db0-5e5ffddff587" TYPE="ext4" PARTLABEL="Et1OF" PARTUUID="7b8d29ef-186b-4699-ab49-19091e5cadf6"
/dev/sda8: UUID="ab5c000c-d40b-4876-89b6-e259219cee4e" TYPE="swap" PARTUUID="cdcd1df3-e640-46fe-9dfb-6a8b61bf8cc2"
/dev/sda9: UUID="5992DB2349479E57" TYPE="ntfs" PARTUUID="a1282ab6-245d-46c4-b1f3-98830c3726a2"
/dev/sda11: SEC_TYPE="msdos" UUID="0038-1E13" TYPE="vfat" PARTUUID="9b06b75d-4dc5-4aef-9dfa-a27771474048"
/dev/sda12: LABEL="Et2OG" UUID="81a886c4-1012-447a-8db0-5e5ffddff587" TYPE="ext4" PARTLABEL="MNT6-3Vu" PARTUUID="ba5dec42-e89e-43fd-9973-beddfe2edbcc"
/dev/sda13: LABEL="TSHIF" UUID="3805ede9-5dff-4e35-8b54-a5b5f90c8b81" TYPE="ext4" PARTUUID="28321ad7-4573-47af-bd58-aa9c2b878fd6"

Man sieht also dass beide die gleiche UUID haben. Die sda7 habe ich mit Paragon geklont und wurde sda12, und war dann genau gleich, bis ich natürlich was jeweils verändert habe. Aktuell ist die V-P, also sda12 die Mint 20.3, die sda 7 ist die Mint 21. Mint 21 ist im Nur-Lese-Modus. ...

Kann ich nun vielleicht die UUID von der einen verändern, damit diese Zuordnungsfehler nicht mehr auftreten?
Komisch war ja damals auch, dass ich nur ein System von Mint 20.0 auf 20.3 geupgraded hatte, und nach 3 Monaten waren dann beide plötzlich 20.3 !!!
Ich hatte definitiv nur einmal ein Upgrade gemacht damals auf 20.3.

Danke Euch im Voraus!

 

[Yannik H]

Es starten beide Systeme bzw. alle 3 (sda4=Win8.1) fast problemlos, nur kommen bei der Mint21 aber die Fehlermeldungen, die von der eingefrorenen Partition herrühren. Neu installieren werde ich sicher nicht.

Bei der V Mnt21 lässt sich eben gar nix löschen, weil es keinen Schreibzugriff gibt. Bei den anderen lässt sich alles normal schreiben, löschen usw.

 

[susejunky]

Hallo @Yannik H ,

wie Du bereits festgestellt hast, haben die Dateisysteme auf den Partitionen sda7 und sda12 die selbe UUID (81a886c4-1012-447a-8db0-5e5ffddff587). Allerdings hat das Dateisystem auf sda12 zusätzlich einen Label (Et2OG). Ansonsten haben die Partitionen selbst unterschiedliche Partitions-UUIDs und auch unterschiedliche Partitions-Labels.

Die Frage ist nun, wie die Partitionen in den /etc/fstab der Systeme (20.3, 21) eingehängt werden (über UUID oder Label).

Komisch war ja damals auch, dass ich nur ein System von Mint 20.0 auf 20.3 geupgraded hatte, und nach 3 Monaten waren dann beide plötzlich 20.3 !!!

Allerdings ist das meines Erachtens ein Hinweis darauf, dass zumindest ein System manchmal sda7 und manchmal sda12 verwendet. Da man sehr wahrscheinlich nicht sagen kann, welche Änderungen dabei auf welcher Partition vorgenommen wurden ...

Neu installieren werde ich sicher nicht.

ist eine Neu-Installation sehr wahrscheinlich die einzig sichere Vorgehensweise, um wieder zu einem konsistenten System zu gelangen.

Ich persönlich würde noch einmal die aktuellste Version (auf sda7 oder sda12) neu installieren und dabei die zu verwendende Partition neu formatieren.

Ansonsten wäre noch zu sagen, dass Du kein btrfs-Dateisystem verwendest, womit laut timeshift-Dokumentation die Schnappschüsse auf Deinem System mittels rsync und hard-links erstellt werden.

Viele Grüße

susejunky

 

[josef-wien]

Die verschiedenen Distributionen verwenden üblicherweise die UUID, um ein Dateisystem anzusprechen. Ob das bei Dir der Fall ist, würde ich mit cat /proc/cmdline und cat /etc/fstab prüfen. Trifft es zu, dann liegt das Problem vor allem darin, daß Du in der Vergangenheit nie gewußt hast, welche Partition jeweils verwendet wurde (das kann theoretisch pro verwendetem Befehl anders sein). Unter diesem Gesichtspunkt ist eine Neuinstallation tatsächlich der empfehlenswerte Weg.

Da kannst natürlich auch einen anderen Weg gehen und eine UUID ändern:

tune2fs -U random /dev/sda7

Die neue UUID zeigt Dir:

dumpe2fs /dev/sda7 | grep UUID

In diesem Fall mußt Du dafür sorgen, daß in beiden /etc/fstab und in der GRUB 2-Konfiguration alles korrekt eintragen wird. Die Systempartition wird mit der Boot-Option root=xxx festgelegt, trotzdem gibt es Programme, die sie anders ermitteln. Ich gehe davon aus, daß das funktionierende System konsistent sein wird, aber ob es tatsächlich so aussieht, wie Du erwartest, kann ich nicht sagen (Nachtrag: "Nebensächlichkeiten" mögen nicht korrekt sein). Beim nicht funktionierenden System müßte man z. B. mit journalctl den tatsächlichen Zustand klären.

Wenn Timeshift während der Installation eingerichtet wurde und die Ursache für den Platzmangel ist, dann paßt die Konfiguration nicht zur Größe des Dateisystems. Außerdem stellt sich dann die Frage, warum trotz "Klonen"das Problem nur bei einem System auftritt. Auch unter diesem Gesichtspunkt ist eine Neuinstallation der empfehlenswerte Weg.

 

[Yannik H]

Okay danke Josef. Ich habe jetzt mal

cat /proc/cmdline

ausgeführt. Es kam Folgendes heraus:

BOOT_IMAGE=/vmlinuz-5.15.0-105-generic root=UUID=81a886c4-1012-447a-8db0-5e5ffddff587 ro quiet splash

Das ist eben kritisch, beide sind die Boot, da kommt er manchmal durcheinander.

Ich hatte nochmal nachgedacht. Das Vernünftigste wäre, derjenigen, die hier gerade aktuell nicht genutzt wird, (ich schreibe hier das alles mit der funktionierenden sda12), eine neue UUID zuzuweisen. Und Du lieferst mir gleich den Code dafür, merci im Voraus. Mal sehen.

:~$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda4 during installation
UUID=81a886c4-1012-447a-8db0-5e5ffddff587 /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=ab5c000c-d40b-4876-89b6-e259219cee4e none            swap    sw              0       0
#UUID=0038-1E13  /boot/efi       vfat    defaults      0       1
#UUID=10A2-5730  /boot/efi       vfat    defaults      0       1
#UUID=282eb289-158e-4428-ae9e-4efdceb4022d  /boot       ext4    defaults      0       2
#UUID=282eb289-158e-4428-ae9e-4efdceb4022d  /boot       ext4    defaults      0       2
UUID=282eb289-158e-4428-ae9e-4efdceb4022d  /boot       ext4    defaults      0       2

Hier bezieht sich was auf die sda4, die aber nur gestartet wird, wenn ich bei der Grub-Auswahl auf "Windows BootManager" gehe. Wenn ich im Uefi einstelle, dass direkt die Festplatte gebootet werden soll, bietet er mir ja die Grub-Auswahl an.

 

[Yannik H]

Wenn Timeshift während der Installation eingerichtet wurde und die Ursache für den Platzmangel ist, dann paßt die Konfiguration nicht zur Größe des Dateisystems. Außerdem stellt sich dann die Frage, warum trotz "Klonen"das Problem nur bei einem System auftritt. Auch unter diesem Gesichtspunkt ist eine Neuinstallation der empfehlenswerte Weg.

Nunja, Timeshift hatte sich automatisch installiert, Ich weiß nicht genau, wann es anfing, automatisch zu sichern. Das war mit 20.0 noch nicht der Fall. Mit der V-Partition, die jetzt die Mnt21 ist, bin ich vor einigen Monaten schon mal in die Bootschleife (man gibt das Paswort richtig ein, dann passiert nix und der Login-Bildschirm kommt wieder...) geraten, weil wegen Timeshift zweimal die Partition voll war (das hatte ich in einem Forum gelesen). Ich hatte dann die sda13 eingerichtet und Timeshift "gebeten", dort zu sichern. Seit Mitte April habe ich eingestellt, dass nur einmal wöchentlich gesichert werden soll.

Das Problem kommt doch daher, dass er nicht immer weiß, welche Partition gestartet werden soll. Die beiden Partitionen mit der identischen UUID sind ja inzwischen längst nicht mehr gleich. (Übrigens war das Klonen keine Absicht. Paragon 17 ist leider inzw. sehr kompliziert in der Bedienung und das Klonen war ja als Sicherung gedacht.)

 

[josef-wien]

Ich sehe zwei Kommentarzeilen zu zwei verschiedenen EFI-Systempartitionen in /etc/fstab. Ich sehe aber keine aktive Eintragung, die eine EFI-Systempartition einhängt (nachdem es eine Boot-Partition gibt, darf die EFI-Systempartition erst danach einhängt werden). Ohne eingehängter EFI-Systempartition wirst Du irgendwann Probleme bekommen, da dort der Bootloader gespeichert ist (ohne eingehängter EFI-Systempartition schreibt der ins Verzeichnis /boot/efi auf der Boot-Partition, und die berücksichtigt das UEFI nicht). Mehrere EFI-Systempartitionen sind zwar formal durchaus erlaubt, eine solche Konstellation solltest Du aber nur dann wählen, wenn Du Dich besonders gut mit UEFI auskennst.

Üblich ist eine EFI-Systempartition, auf der alle installierten Systeme das speichern, was zu Ihrem Start notwendig ist. Bei mehreren Linux-Systemen rate ich Dir, nur auf einem einzigen einen Bootloader zu installieren. Die üblichen Automatismen sind nicht darauf ausgerichtet, daß es mehrere Bootloader gibt, daher sind irgendwann Probleme zu erwarten, wenn detailliertes Wissen über diese Thematik fehlt.

 

[Yannik H]

Hallo Josef, vielen Dank für Deine Antwort.

Also ich habe nun der sda7 (Mint21) eine neue UUID zugewiesen. Mit Deinem Befehl ging das aber nicht, auch nicht mit Root-Rechten "sudo". Ich habe mit Gparted eine zufällige UUID zugewiesen, die jetzt mit 9d7d6 beginnt. Nun kann ich die Mnt21 nicht mehr starten um ins Linux zu kommen, d.h. egal welches System ich im Linux-Auswahlmenü wähle, es kommt immer nur die sda12. sda12 geht problemlos.

Bei mir zeigt Gparted folgenden Beginn der Partitionen der 2TB-HD an.
Am Schluss jew. Anmerkung bzw. erste 4 Bytes UUID
sda11 ------------- FAT16 100MB legacy boot, msftdata 0038
sda1 Basic Data Partition NTFS 300MB Wiederherst. hidden, diag B074
sda2 EFI System Partition FAT32 100MB boot, esp 10A2
sda3 ------------- FAT32 128MB msftres
sda4 H1 NTFS 109GB msftdata
sda5 ext4 106GB (Hier ist Einhängepunkt: /boot)

Was heißt bei einer Partition "Einhängepunkt: /boot"? Ich verstehe nicht wie das gemeint ist. Nutzt hier eine andere Partition einen Einhängepunkt??
Wie Du siehst, sind also /boot/efi sda11 und sda2. Wahrscheinlich ist es am besten, die sda11 nicht mehr als boot zu nehmen. Wahrscheinich kommt was durcheinander, wenn ich die einfach lösche. Was schlägst Du vor?

Zweite Frage: Wie komme ich bei der sda7 aus dem Nur-Lesemodus raus? Wenn ich jetzt diese nochmal klone, und dann die alte lösche, und zurückklone, ist es dann wieder gleich? Oder wo wird bestimmt, dass es nur einen Nur-Lesemodus gibt? Danke!

PS: Ich möchte auch deswegen nicht neu installieren, weil ein bestimmtes Programm, was es nicht in den offiziellen Repositories gibt, damals nur schwer zu installieren war, und nach 2 Tagen probieren habe ich es doch noch hinbekommen auf der sda7. Es wird nicht mehr gepflegt und niemand kümmert sich derzeit darum. Auf der sda12 ist es nicht!

 

[josef-wien]

In Beitrag 9 steht, was Du nach Vergabe einer neuen UUID machen mußt. Weder bei GRUB 2 noch bei journalctl (zur Klärung des "Nur-Lesemodus") kann ich Dir helfen.

Deine Parttitionierung ist mehr als fragwürdig. Du hast eine Boot-Partition (und ich frage mich, wozu), die zumindest bei einem System im Verzeichnis /boot der Systempartition eingehängt ist. Im Verzeichnis /boot bzw. auf der dort eingehängten Boot-Partition befinden sich Kernel und initrd, die vom Boot-Manager gestartet werden. Kernel und initrd müssen natürlich zu den Modulen auf der mit der Boot-Option root=xxx definierten Systempartition passen. Auf der EFI-Systempartition befinden sich in jeweils eigenen Verzeichnissen jene Programme, das vom UEFI) gestartet wird, und die von den Programmen benötigten Dateien. Wenn im laufenden System dort etwas gespeichert werden soll, muß diese eingehängt sein, und üblicherweise lautet der Einhängepunkt /boot/efi.

Ohne grundlegendes Wissen über die Zusammenhänge wundern mich Deine Vorgangsweise und die daraus resultierenden Probleme nicht. Etwas Lesestoff:
Partitionierung und Verzeichnisstruktur – Linupedia.org
Mountpoint – Linupedia.org
UEFI – Linupedia.org

Trotz Deiner Bedenken hinsichtlich des einen Programms rate ich dringend, alle Linux-Partitionen zu löschen und neu zu installieren.

 

[susejunky]

Hallo @Yannik H ,

Trotz Deiner Bedenken hinsichtlich des einen Programms rate ich dringend, alle Linux-Partitionen zu löschen und neu zu installieren.

das sehe ich auch so und zwar aus folgendem Grund:

Selbst wenn es Dir gelingen sollte das System auf sda7 zu "re-animieren" bleibt immer noch die Frage offen, wie sich die alternierende Nutzung von sda7 und sda12 (aufgrund der identischen UUID der darauf befindlichen Dateisysteme) auf die Stabilität der dort installierten Systeme auswirken wird. Das Risiko eines schleichenden Systemversagens ist meines Erachtens unkalkulierbar.

Aus meiner Sicht stellt sich die Frage, was sich für Dich schwieriger gestalten und Dich zukünftig mehr Zeit kosten wird:

Das eine Programm noch einmal zu installieren oder die kontinuierliche Analyse und Reparatur eines schleichenden Systemversagens.

Es sind Deine Systeme und damit auch Deine Entscheidung ...

Viele Grüße

susejunky

 

[Yannik H]

Hallo, also wenn ich es mir genau überlege, ist es alles gar nicht so kompliziert. Die Probleme sind nur entstanden, weil ich mir im Hinblick aufs Klonen nicht bewusst war, dass dann beide Systeme auf die gleiche Boot zugreifen. Jetzt muss es eben sauber getrennt werden.
Ich habe von der sda12 aus ins Terminal os-prober eingegeben. Findet nur sda7. Gebe ich aber "sudo os-prober" ein, findet es sda7 und sda12. Heute habe ich allerdings kaum Zeit dafür, weiter zu suchen und mich zu informieren über fstab usw.
Nachdem ich viel Zeit ins Upgrade reingesteckt habe, werde ich nicht gerade jetzt plötzlich neu aufsetzen. Das bräuchte dann fast eine Woche neben meiner Arbeit. Und habe auch privat zu Hause viel zu tun, das wäre jetzt nicht möglich.
Da versuch ich lieber die elegante Lösung. Danke Euch weiterhin.

Yannik