Auto-Mount-Problem seit Kernel 6.19.11

EOS Deutsch
1

Hallo zusammen,

der Fehler ist ein ziemlich unangenehmes Osterpräsent.

Ich beschreib mal die Symptome. SSD mit / und /Home werden korrekt eingebunden. Zweite SSD mit BTRFS verlangt plötzlich Passwort, wird aber danach gemountet.

HDD mit 3 Partitionen, zwei davon NTFS - die verlangen jetzt auch ein Password, verabschieden sich aber danach mit nicht näher spezifiziertem Fehler. Shutdown geht nur noch über langes Drücken des Ein-Aus Schalters.

Also Windows gestartet, alle Partitionen getestet - fehlerfrei - erstes Staunen. Smart-Werte ausgelesen - o.k.

Zurück in EOS, in FSTAB die bisherigen Einträge auskommentiert - neu gebootet. Jetzt können alle Partitionen nach Eingabe Passwort des Admin gemountet werden. Neue FSTAB Einträge mit UUID, leider wieder der gleiche Mist. Anbei mal die FSTAB, ich stehe auf’m Schlauch :grimacing:

FSTAB:

UUID=8035-31F9	/boot/efi	vfat	fmask=0137,dmask=0027	0	2
UUID=5c8f5664-6795-4126-88f0-7fdb40249abf	/	btrfs	subvol=/@,noatime,compress=zstd	0	0
UUID=5c8f5664-6795-4126-88f0-7fdb40249abf	/var/cache	btrfs	subvol=/@cache\*,noatime,compress=zstd	0	0
UUID=5c8f5664-6795-4126-88f0-7fdb40249abf	/var/log	btrfs	subvol=/@log,noatime,compress=zstd	0	0
UUID=bd5a4bde-6f58-4ada-8be8-7d403011a555	/home	btrfs	noatime,compress=zstd	0	0
tmpfs	/tmp	tmpfs	defaults,noatime,mode=1777	0	0\

------------- funktional bis Update 04.04.26 Kernel 6.19.11-----------

/dev/disk/by-label/FastData	/mnt/FastData	auto	nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=FastData	0	0

/dev/disk/by-label/Media	/mnt/Media	auto	nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=Media	0	0

/dev/disk/by-label/BackUp	/mnt/BackUp	auto	nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=BackUp	0	0

/dev/disk/by-label/TimeShift	/mnt/TimeShift	auto	nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=TimeShift	0	0

/dev/disk/by-uuid/6CF48445F484138C	/mnt/6CF48445F484138C	auto	nosuid,nodev,nofail,x-gvfs-show	0	0

----- neu erstellt, NTFS Partionen verlangen PW, mounten aber nicht ----------

/dev/disk/by-uuid/489607E19607CE7E /mnt/489607E19607CE7E auto nosuid,nodev,nofail,x-gvfs-show 0 0

/dev/disk/by-uuid/38921D20921CE462 /mnt/38921D20921CE462 auto nosuid,nodev,nofail,x-gvfs-show 0 0

/dev/disk/by-uuid/a27f548e-39cc-4cd9-bb31-d0ae02e2269c /mnt/a27f548e-39cc-4cd9-bb31-d0ae02e2269c auto nosuid,nodev,nofail,x-gvfs-show 0 0*

/dev/disk/by-uuid/9C54889754887634 /mnt/9C54889754887634 auto nosuid,nodev,nofail,x-gvfs-show 0 0

Z.Z. mounte ich die entsprechenden Partionen über Dolphin nach jedem Start…:thinking:

Gruß Michael

2

Hab Timeshift eingesetzt, zurück auf 6.19.10 (Backup vom 30.03.), damit werden alle Partitionen korrekt eingebunden. Das ist schon ein ziemlicher Hammer….!

Hat sonst niemand Probleme?

Gruß Michael

3

@joekamprad Looks like bugreport

4

@wodsfortdragon Denke nicht das ist ein allgemeines Problem. ( i do not think this is a general issue)

@MichaelP
Es könnte auch an den boot images initramfs liegen eventuell fehlerhaft gebaut..

Beim zurück gehen auf einen alten snapshot ist es alter kernel aber eventuell mit intakten images.

Aber ohne einen log/journal der irgendetwas über den aktuellen fehler nach dem Einbinden zeigt schwer etwas zu sagen.

Wenn die Einträge aus der fstab für ntfs / Btrfs dazu führen das die partitionen nicht automatisch eingebunden sind und dolphin nach einem passwort fragt wird es sein das du die dann sozusagen manuell einbindest.. es könnte sein das auto nicht mehr erkennt was für ein format es ist .. aber es würde helfen die Fehlermeldungen zu sehen.

5

@joekamprad danke für die Tipps… die “allgemeine” Fehlermeldung kam in Dolphin beim Versuch zu mounten… ja, ich hätte log/journal vor Timeshift sichern sollen, sorry (Paniksituation).

Das “auto” das format nicht mehr erkennt, scheint mir unwahrscheinlich.

Im betroffenen System befinden sich zwei baugleiche Toshiba HDDs, beide mit den Partitionen media (ntfs), backup (ntfs) und timeshift (btrfs) bzw. media-2, backup-2, timeshift-2.

Im Idealfall wären die perfekt gespiegelt (manuell) - das war aber nicht auf Stand :shushing_face: - inzwischen schon. Der Bug hat zwar viel Aufwand ( 4h zum spiegeln), aber auch eine steile Lernkurve bewirkt :smirking_face: .

Alle Partitionen der zweiten HDD ließen sich problemlos und ohne PW einbinden, das spricht m.E. gegen die “auto”-Vermutung.

Nachtrag: Ich hab auch mal vom LIVE-USB-Stick gebootet, da wurden alle(!) Partitionen korrekt gemountet. Auf der Live sollte Timeshift vorinstalliert sein…

Beim booten mit dem LTS-Kernel blieben die Partitionen dagegen auch unmountet.

Ich lasse das System jetzt mal ein paar Tage ohne Updates laufen um zu sehen, ob ähnliche Probleme/Berichte auftauchen. Dann mach ich einen neuen Update Versuch - ggf. warte ich bis 7.0 / KDE 6.6.4.

Gruß Michael

6

Ohne die Logfiles ist es schwer zu verstehen, was da wirklich das Problem war.
Ein Thema, was da ggf. mit reinspielt, sind die NTFS-Partitionen. Das kann beim Mounten schon die Probleme machen. Wie sind denn diese Einträge reingekommen? Hast Du die händisch hinzugefügt?
Ein weiterer Punkt, der mir in Deiner fstab aufgefallen ist, warum Deine BTRFS-Partition /home keinen subvol-Eintrag @home hat. Ist das schon nach der Installation so gewesen oder hast Du die SSD selbst händisch eingebunden?
Zur Frage nach den Passwörtern beim Mounten solltest Du in Deiner /etc/crypttab schauen, was es dort für Einträge gibt.
Aber in der Summe gilt der einleitende Satz: ohne die Logfiles ist eher Glaskugel-Raten.

7

@marteng69 ich bereue, die logfiles vor timeshift nicht gesichert zu haben. Naja, vielleicht tritt der Fehler nach dem nächsten Update wieder auf - bin lernfähig :pensive_face:

Die fstab Einträge bis tmpfs (ersten 6 Zeilen) sind noch von der EOS-Installation (unverändert).

Part 2 (funktional bis…) wurden mit gnome-disk-utility erzeugt und funktionierten ca. 2-3 Jahre. Mit 6.19.11 dann nicht mehr. Testweise hab ich diese Einträge auskommentiert und konnte dann die Partitionen nach Neustart manuell mounten. Probeweise hab ich dann (Part 3) mit dem gleichen Tool neue fstab-Eintrage für die betroffenen Partionen erstellt. Damit scheiterte dann manuelles mounten wieder.

Meine Vermutung, wenn es an den NTFS-Partitionen liegen würde, hätte es weder mit dem Live-Medium noch nach Timeshift geklappt - verstehen tue ich es aber nicht.

Wenn es keine neuen Erkenntnisse gibt werde ich jetzt erst mal, wie oben erwähnt, kein Update machen und Ruhe bewahren… bin froh, daß es im Moment stabil läuft und keine Daten ver”lustig”:wink: sind.

Gruß Michael

8

Kein Stress. Sowas kann passieren im Eifer des Gefechts … :wink:

Ich habe ein bisschen recherchiert. Wie es aussieht, wurde beim Kernel 6.9 etwas beim Mounten von NTFS-Partitionen angepasst. Die Vermutung von @joekamprad, dass die Mount-Option auto nicht mehr ausreichend sein könnte, erhält damit aus meiner Sicht etwas mehr Nahrung. Evtl. wurde dann mit dem Update 6.19.11 noch etwas mehr angepasst, so dass es jetzt eben nicht mehr geht wie bisher. Genaue Details zu Änderungen bei der 6.19.11 konnte ich leider nicht finden.
NTFS-Mounting unter Linux ist immer etwas heikel, v.a. wenn da regelmäßig ein Windows darauf zugreift. Für sowas zum Austausch ist FAT32 die bessere Option.
Dass es im Live-System keine Probleme gegeben hat, liegt an der älteren Kernel-Version.

Ja, jetzt erst mal nichts machen, ist OK. Trotzdem würde ich demnächst ein Update machen. Die Einträge in der fstab würde ich aber nicht unbedingt mit gnome-disk-utility machen, da es auch nur ein Frontend ist und ein bestimmtes Muster verwendet, das nicht immer passen muss. Auf der Seite https://wiki.archlinux.org/title/Fstab ist aus meiner Sicht gut erklärt, wie man Partitionen beim Start des Rechners über diese Datei einbindet.
Viel Erfolg!

9

Noch einen Test unternommen:

Plasma erlaubt ja auch in den Systemsettings automount - da mal nachgeschaut, welche Partitionen zur Verfügung stehen. Exakt die Partitionen, für die in der fstab zusätzliche Einträge vorhanden waren, fehlten. Also nochmal in fstab auskommentiert, neu gebootet und in den Settings nachgeschaut. Jetzt werden die gewünschten Automount Partitionen angezeigt.

Ausgewählt, gespeichert, neu gebootet..
Keine Fehlermeldung, aber auch kein Automount und nachgeschaut - kein Eintrag in fstab.

Mounten nach PW-Eingabe manuell möglich.

So ein Sch :hot_face: … initramfs neu initialisieren? :roll_eyes:

Gruß Michael

10

Hast Du vor dem Reboot geschaut, ob die Einträge in der /etc/fstab enthalten waren?
Wenn ja, dann ist das echt komisch, da das nicht mit der initramsfs-Erstellung zu tun hat.

Noch eine Bemerkung zum Thema Automount: das ist eigentlich eine Funktionalität um z.B. USB-Sticks, USB-SSDs etc. in der Laufzeit einzubinden. Wenn Du die Sachen schon direkt beim Start eingebunden haben willst, dann musst Du sie korrekt vorher in der /etc/fstab haben. Sollte das Laufwerk zum einbinden auch noch eine Passwortverschlüsselung haben, dann kannst Du über die /etc/crypttab diese Partition beim Start zur Passworteingabe mit anbieten oder die Partition ist mit einer Passwortdatei verschlüsselt, dann kannst Du die an der Stelle einbinden. Ist im Arch-Wiki ausführlich erläutert.

11

Es waren die Einträge drin, die unter 6.19.10 laufen. Diese Partitionen wurden in KDE-Systemsettings zur Auswahl automount gar nicht aufgeführt. Daher hab ich meine Einträge auskommentiert und neu gebootet.

Danach wurden diese Partitionen in den KDE-Systemsettings angezeigt. Automount war wählbar - Haken gesetzt, gespeichert und neu gestartet !

Ergebnis - kein automount, keine Fehlermeldung und keine von den KDE-Systemsettings neu generierten fstab-Einträge.

Das ist auf jeden Fall Mist, zumindest eine Fehlermeldung von KDE wäre doch erwartbar….!!!

12

Ich bin jetzt nicht sicher, ob wir aneinander vorbeigeredet haben.
Meine Frage bezog sich darauf, ob Du nach dem automount in den KDE-Settings vor dem Reboot die Einträge in der fstab gefunden hast? Wenn ja, dann wäre das tatsächlich seltsam, dass die nach dem Reboot weg sind. Wurdest Du vor dem Eintrag dieser Automount-Einträge nach dem root/sudo-Passwort gefragt? Wenn nein, dann kann das auch nicht in der fstab landen, da die nur als root/sudo geändert werden kann.

BTW: wo genau in den KDE-Settings hast Du es geschafft diese Automounts einzurichten? Ich habe das gleiche bei mir versucht und habe ich den KDE Settings keine Möglichkeit gefunden.
Mit der KDE Partitionsverwaltung habe ich einen Weg gefunden und damit bleibt das auch in der fstab nach dem Reboot drin.

13

Systemsettings aufrufen, im Suchfeld oben links automount eintragen - dann erscheint das Fenster Geräte automatisch einhängen mit den Auswahlfeldern für die noch nicht gemounteten Devices Option Bei der Anmeldung oder Beim Anschluss. Ausgewählt, gespeichert, klappte aber nicht.

Deinen Vorschlag, alternativ KPartition zu nehmen, probier ich mal aus… danke für den Tipp!

14

Ah, den Eintrag in den Settings hatte ich gefunden, aber da tauchte nie eines meiner USB-Geräte auf, egal zu welchem Zeitpunkt beim Anschluss. Vermutlich fehlt mir noch irgeneine KDE-Komponente, dass ich das über die Settings nutzen kann.

Noch vergessen zu schreiben: Einhängen mit UUID ist “Pflicht”, da die beiden anderen nicht eineindeutig sein können und es dann zu neuen Problemen kommen kann.

15

Hab es gerade in den Systemsettings noch mal mit einer weiteren Partition probiert:

Wie zuvor beschrieben Haken gesetzt, Anwenden gedrückt, mit Passwort bestätigt und vor Reboot in fstab nachgeschaut - nichts Neues drin.

Die System-Settings-Variante erscheint echt Fake :roll_eyes: - wenn es nicht klappt, sollte es doch wenigstens eine Meldung geben! :face_with_raised_eyebrow:

… bin ja mit meinen fstab-Einträgen nach Timeshift und Kernel 6.19.10 noch o.k. - werd es neu mit UUIDs probieren.

16

Das ist echt komisch, dass das nicht klappt. Ich suche mal ob ich was dazu in den KDE Bugs finde.

Probier das ruhig vor dem Update auf den nächsten Kernel. Das bringt ja nichts, wenn es schon vorher nicht geht … :face_with_peeking_eye:

17

hab meine optionalen fstab-Einträge auskommentiert und über kpartition Neue auf Basis UUID erstellt. Die Einträge werden auch in fstab eingetragen und automount unter 6.19.10 funktioniert damit einwandfrei - soweit ein erster Schritt… danke!

@joekamprad … wie zuvor getestet und beschrieben, bleibten automount-Einträge über die KDE-System-Settings wirkungslos, in fstab wird nichts eingetragen und eine Fehlermeldung erscheint auch nicht.

Nach meiner Einschätzung eindeutig ein KDE-Bug!

Bleibt abzuwarten, ob automount nach dem nächstem Update (warte auf Kernel 6.19.12 oder 7) funktional bleibt. Die mit Gnome-Disk-Utility erzeugten automounts über UUID waren es mit 6.19.11 nicht!

18

Das ist erfreulich zu lesen!

Wichtig! Die EOS Devs werden solche Bugs nicht selbst Upstream melden können. Das müssen wir als Betroffene schon selbst machen. Blöderweise kann ich Dein Vorgehen bei mir überhaupt nicht nachstellen. Ich habe in den KDE Bugs geschaut, aber nichts gefunden, was auf Dein Problem hindeutet. Die meisten Berichte sind ähnlich zu dem, was ich gefunden habe, dass die externen Laufwerke im Bereich Automount gar nicht angezeigt werden.

Ich würde nicht zu lange warten, sondern jetzt ein Update machen. Mittlerweile gibt es von KDE und Gnome mehrere Updates. Sollte es nach dem Kernel-Update wieder Probleme geben, dann wird irgendwann mal die Fehleranalyse schwierig, weil zu viele mögliche Fehlerquellen geändert wurden. Kernel 7.0 soll Mitte April erscheinen. Bis der dann in Arch bzw. EOS veröffentlicht wird, dann kann es auch Anfang Mai oder später werden.

19

Wichtig: die Sichtbarkeit und Auswahl automount ist in den KDE-System-Settings beschränkt auf Partitionen, die keinen(!) fstab-Eintrag haben. Das erscheint mir auch logisch und richtig.

Wenn Du Partitions-Einträge mal testweise auskommentierst, sollten diese Partitionen nach Reboot in den System-Settings erscheinen. Bei mir war das jedenfalls so…:thinking:

20

Ich habe eine externe Festplatte angeschlossen, sie aber nicht gemountet. Auch dann tauchte die nie in den KDE Systemsettings im Bereich Automount auf. Damit konnte ich den Weg von Dir nie ausprobieren.
Ist eigentlich egal. Ich vermute, dass dieser Weg derzeit defekt ist und der beste Weg über partitionmanager gehen sollte.