staging.inyokaproject.org

Ich habe mal das ganze windows_names-Problem studiert. Dabei fehlt mir eine grundlegende Information: Wie findet standardmäßig – also ohne udev-Regel und ohne udisksctl.conf – die automatische Treiber-Auswahl statt und wovon hängt diese letztlich ab? Bei mir (Xubuntu 22.04 LTS, Upgrade von 20.04, Kernel 5.15.0.97 generic) wird nach wie vor standardmäßig NTFS-3G gewählt. An dem X kann es nicht liegen, das wurde längst schon überprüft. Warum ist es so? Was ist bei dem Upgrade anders als bei einem nativen 22.04.x? In welchen Konstellationen wird nun tatsächlich standardmäßig ntfs3 gewählt?

Wenn bei 20.04 standardmäßig immer NTFS-3G gewählt wird (??), dann reduziert sich dort das Problem doch sehr. Beim händischen Mounten und fstab lässt sich die Option windows_names für ntfs3 vermeiden. Man müsste nur darauf hinweisen. Und ab 22.04 kann man dann die Option via udisksctl.conf auch fürs automatische Mounten bzw. gio mount und GUI vermeiden.

Wirklich schlimm wäre doch nur, wenn bei 20.04 automatisch und unveränderlich der Treiber ntfs3 gewählt würde. Muss man damit wirklich rechnen?

Aber wahrscheinlich habe ich etwas nicht recht verstanden, denn so wäre es doch zu einfach… Denn die Regel wäre dann: in Ubuntu 20.04 darf ntfs3 nur über fstab bzw. mit mount und ohne windows_names verwendet werden, gio mount und Einbinden per GUI sind für ntfs3 ohne fstab-Eintrag tabu. Ab 22.04 gibt es dann ja udisksctrl.conf als Rettungsanker.

Max-Ulrich_Farber schrieb:

Wenn bei 20.04 standardmäßig immer NTFS-3G gewählt wird (??), dann reduziert sich dort das Problem doch sehr. Beim händischen Mounten und fstab lässt sich die Option windows_names für ntfs3 vermeiden. Man müsste nur darauf hinweisen. Und ab 22.04 kann man dann die Option via udisksctl.conf auch fürs automatische Mounten bzw. gio mount und GUI vermeiden.

Ich verstehe nicht, warum Du die Themen NTFS3 und windows_names miteinander "verquirlt" betrachten willst, auch wenn nicht alle Kombinationen davon funktionieren.

In den meisten Fällen will man ja die Option windows_names (bei NTFS3 wohl default und erst ab Kernel 6.5 als explizite Option (ohnehin redundant) erlaubt), um Windows-Kompatibilität zu erzielen, nur in wenigen Ausnahmefällen ist windows_names "Gift".

Max-Ulrich_Farber schrieb:

[…] Dabei fehlt mir eine grundlegende Information: Wie findet standardmäßig – also ohne udev-Regel und ohne udisksctl.conf – die automatische Treiber-Auswahl statt und wovon hängt diese letztlich ab?

Das ist die Frage aller Fragen! Ich habe bisher nur verstanden:

• Bei mount gibt es mehrere Methoden, die je nach Situation verschieden benutzt werden oder auch nicht und vielleicht sogar in der Reihenfolge umsortiert werden. Ich überblicke das Gesamtbild noch und vielleicht auch niemals nicht. Meine Versuche, die in der Manpage zu mount beschriebenen Methoden zu konfigurieren, waren bisher nicht oder nur teilweise erfolgreich.

• Bei udisks2 ist eine Reihenfolge dokumentiert, die aber leider erst ab Version 2.10.0 von udisks2 (also Ubuntu 23.10) gilt. Dabei hat mount bzw fstab das letzte Wort.

Ich denke, die in der Praxis beste Strategie hinsichtlich der Automatik bei mount ist, diese nicht zu benutzen.

Vielleicht habt Ihr es ja schon gewusst, ich habe es bisher nicht gewusst:

ntfs-3g unterscheidet beim Einhängen zwischen Cmdline options und Mount Options. Letztere werden bei der Ausgabe mittels z.B. mount | grep Mountpunkt angezeigt. Erstere aber nicht. Sehen kann man das nur in den Logs oder wenn man mount -t ntfs-3g ... die Option debug mitgibt.

Das hat mich nämlich hinsichtlich windows_names verwirrt. Wenn man dagegen mittels ntfs3 einhängt, dann wird windows_names so wie man - oder zumindest ich - es erwarte(t), mittels mount | grep Mountpunkt auch ordentlich angezeigt.

LG, Newubunti

UlfZibis schrieb:

Ich verstehe nicht, warum Du die Themen NTFS3 und windows_names miteinander "verquirlt" betrachten willst, auch wenn nicht alle Kombinationen davon funktionieren.

Ich verquirle die nicht, sondern sie hängen halt leider eng miteinander zusammen. Wenn automatisch mit einem Treiber gemountet wird, der die fest vorgegebene Mount-Option nicht akzeptiert, dann entsteht Ungedeih. Ganz sicher.

In den meisten Fällen will man ja die Option windows_names (bei NTFS3 wohl default und erst ab Kernel 6.5 als explizite Option (ohnehin redundant) erlaubt), um Windows-Kompatibilität zu erzielen, nur in wenigen Ausnahmefällen ist windows_names "Gift".

Das ist an sich schon schlimm genug. Es geht mir nun darum: Sind das wirklich so wenige Ausnahmefälle, dass ein warnender Hinweis genügen muss, oder tritt die Situation mit so großer Wahrscheinlichkeit auf, dass es nötig wird, ausführlich ein Workaround zu beschreiben.

Nebenbei: Ich will die Option windows_names gar nicht, ich kann selber aufpassen! Und nicht auf jede meiner in Linux angelegten Dateien muss man unbedingt automatisch auch in Windows zugreifen können. Vielleicht werde ich in ein paar Jahren altershalber entmündigt ☹ 😢 , aber jetzt bitte noch nicht!

Newobunti schrieb:

ntfs-3g unterscheidet beim Einhängen zwischen Cmdline options und Mount Options. Letztere werden bei der Ausgabe mittels z.B. mount | grep Mountpunkt angezeigt.

Das muss wohl an FUSE liegen. Denn ins System gemountet wird FUSE, und da hinein wird dann die NTFS-Partition gemountet. allow_other ist z.B. keine übliche mount-Option sondern eine innere Angelegenheit von FUSE. Da spielt bei FUSE manches zusammen, von dem ich nicht behaupten kann, dass ich es durchschaue.

kB schrieb:

Das ist die Frage aller Fragen! Ich habe bisher nur verstanden:

Bei mount gibt es mehrere Methoden, die je nach Situation verschieden benutzt werden oder auch nicht und vielleicht sogar in der Reihenfolge umsortiert werden. Ich überblicke das Gesamtbild noch und vielleicht auch niemals nicht. Meine Versuche, die in der Manpage zu mount beschriebenen Methoden zu konfigurieren, waren bisher nicht oder nur teilweise erfolgreich.

Ja, und wenn das für kB so gilt, wie viel mehr dann für mich, der ich nicht die gleichen Kenntnisse habe! Ich will trotzdem eine Erklärung versuchen, die vielleicht auch daneben trifft:

Der Befehl mount -t ntfs-3g ruft das Dienstprogramm mount.ntfs-3g auf, das eine eigene Manpage hat (man mount.ntfs-3g). Was da drin steht, hat für NTFS-3G Gültigkeit und sonst nichts. Für ntfs3 tappen wir – genau so wie für den exFAT-Treiber – völlig im Dunkeln, denn darüber steht in man mount gar nichts (deshalb sind die Treiber IMO noch im experimentellen Stadium und nicht reif für eine "stable"-Version, wie ja Debian auch entschieden hat). Wir können nur vermuten, was vielleicht oder auch wahrscheinlich geschieht. Komplizierten Quelltext lesen will und kann ich nicht, und dazu ist auch niemand von uns verpflichtet. Wir haben auch noch anderes zu tun.

Deutlich, vielleicht zu deutlich gesagt heißt dies: Wer schon vor Ubuntu 22.04, wo dann ntfs3 Standard geworden ist, diesen Treiber benutzen will, tut dies auf eigenes Risiko! In 22.04 gibt es mittels udissctl.conf dann die Möglichkeit, wenn nötig, windows_names zu vermeiden, und damit ist das Problem vom Tisch. Und ab 23.10 gibt es offenbar das Problem nicht mehr.

Bei mount -t ntfs3 … und fstab-Eintag mit ntfs3 dürfte (?) kein Problem auftreten, wenn man nicht explizit windows_names angibt. Außerdem verwende ich in kritischen Situationen in der fstab gerne die Option nofail, dann hängt das System wenigstens nicht beim Booten. Bei einem unsicheren Treiber wie ntfs3 ist das wohl kein Fehler, denn wer weiß schon, was beim nächsten Kernel-Update passieren kann?

Gruß – Max-Ulrich

Max-Ulrich_Farber schrieb:

[…] Für ntfs3 tappen wir – genau so wie für den exFAT-Treiber – völlig im Dunkeln, denn darüber steht in man mount gar nichts (deshalb sind die Treiber IMO noch im experimentellen Stadium und nicht reif für eine "stable"-Version, wie ja Debian auch entschieden hat). […]

Es stimmt zwar, dass ntfs3 nicht in der Manpage von mount beschrieben ist, aber dokumentiert ist dieses neue Modul durchaus. Es gibt die offizielle Kernel-Dokumentation:
https://docs.kernel.org/filesystems/ntfs3.html

(Ein entsprechendes Kapitel für exfat gibt es dort übrigens leider nicht.)

Deutlich, vielleicht zu deutlich gesagt heißt dies: Wer schon vor Ubuntu 22.04, wo dann ntfs3 Standard geworden ist, diesen Treiber benutzen will, tut dies auf eigenes Risiko!

Ja, da schließe ich mich an, vermutlich aber aus anderen Gründen als Du:

• Das Modul ntfs3 wurde nach seiner Aufnahme in den Kernel 5.15 für ca. ein Jahr gar nicht gepflegt und es wurde sogar vorgeschlagen, es wieder aus dem Kernel zu entfernen. Erst mit Kernel 6.2 wurden Sicherheitslücken gestopft und neue Features (auch die Option windows_names) eingeführt und mit Kernel 6.4 weitere Pflegemaßnahmen durchgeführt. Ich würde es deshalb produktiv erst ab Kernel 6.4 einsetzen. Das entspricht in etwa einem aktuellen 22.04 HWE System (nicht LTS!) bzw. 23.10. Ich plane für den Artikel zu ntfs3 einen entsprechenden Hinweis.

Max-Ulrich_Farber schrieb:

Newobunti schrieb:

Das muss wohl an FUSE liegen. Denn ins System gemountet wird FUSE, und da hinein wird dann die NTFS-Partition gemountet. allow_other ist z.B. keine übliche mount-Option sondern eine innere Angelegenheit von FUSE. Da spielt bei FUSE manches zusammen, von dem ich nicht behaupten kann, dass ich es durchschaue.

Danke, Max-Ulrich_Farber! Ich beiße mir gerade in meinen Allerwertesten, weil ich das hier schon vor mir hatte, nur da standen die Optionen noch nicht im Fokus meiner Betrachtung. Tischplatte und Kopf schließen gerade eine enge Freundschaft! 😬

LG, Newubunti

Max-Ulrich_Farber schrieb:

Das ist an sich schon schlimm genug. Es geht mir nun darum: Sind das wirklich so wenige Ausnahmefälle, dass ein warnender Hinweis genügen muss, oder tritt die Situation mit so großer Wahrscheinlichkeit auf, dass es nötig wird, ausführlich ein Workaround zu beschreiben.

Ja ich finde, der Hinweis sollte auf jeden Fall rein, und wenn der Workaround nur 2 Zeilen erfordert ... warum nicht. Auch in Zusammenhang mit der Option permissions macht windows_names keinen Sinn mehr oder ist sogar hinderlich, denn so eine Partition will man ja nur mit Linux verwenden.

Und ab 23.10 gibt es offenbar das Problem nicht mehr.

Wieso. Auch da wird windows_names per default angewendet – zumindest per GUI bzw. gio mount, oder etwa nicht mehr.

Gruß Ulf

Auch in Zusammenhang mit der Option permissions macht windows_names keinen Sinn mehr oder ist sogar hinderlich, denn so eine Partition will man ja nur mit Linux verwenden.

Was "man" will, weiß ich nicht. Es gibt ja auch z.B. USB-Sticks, die "man" abwechselnd auf verschiedenen Systemen verwenden will. Für die macht User Mapping meistens keinen Sinn, aber windows_names vielleicht schon. Ich möchte nach Möglichkeit gerne entscheiden können, was ich tun will und brauche.

Wieso. Auch da wird windows_names per default angewendet…

Schon, aber der Treiber kommt in der neueren Version (Kernel 6.2 ff) damit klar. Newubunti hat das oben bereits sehr ausführlich erklärt.

Max-Ulrich_Farber schrieb:

Wieso. Auch da wird windows_names per default angewendet…

Schon, aber der Treiber kommt in der neueren Version (Kernel 6.2 ff) damit klar. Newubunti hat das oben bereits sehr ausführlich erklärt.

Ich denke, wir müssen hier zwei Szenarien unterscheiden:

1. Kommt – welcher Treiber auch immer – mit der Option windows_names klar?

2. Nicht-Funktion von manchen Anwendungen, wenn windows_names implizit per default vorgegeben ist.

Max-Ulrich_Farber schrieb:

... Wie findet standardmäßig – also ohne udev-Regel und ohne udisksctl.conf – die automatische Treiber-Auswahl statt und wovon hängt diese letztlich ab?

Nach meinen Beobachtungen erkläre ich das zum jetzigen Zeitpunkt so:

• Ein vorhandenes Kernel-Modul für einen Dateisystemtyp, wird einem externen Treiber für den selben Dateisystemtyp immer vorgezogen.

D.h. also vor der Einführung des ntfs3-Moduls, war der eigentliche Standard das alte Kernel-Modul ntfs. Dieser Standard kann jedoch für mount durch eine Datei der Form /usr/sbin/mount.Dateisystemtyp geändert werden. Im Falle von ntfs existiert eine Datei /usr/sbin/mount.ntfs. Damit wird mount mitgeteilt, diese Datei anstatt des Kernel-Moduls ntfs für den Dateisystemtyp ntfs auszuführen.

Und /usr/sbin/mount.ntfs ist eine symbolische Verknüpfung zu /usr/sbin/mount.ntfs-3g.

Bei Programmen die auf udisks2 beruhen, ändert sich an dem Grundsatz, dass das Kernel-Modul Vorfahrt hat, nichts. udisks2 kann aber - wenn wir udev und mount_options.conf außen vor lassen - im Code eine eigenständige Priorisierung gegenüber der von mount etablieren. Und das geschieht ja auch hinsichtlich ntfs3.

Deswegen habe ich auch weiter oben davon gesprochen, dass mount und udisks auf selbständigen Schienen laufen. Gemein ist beiden, dass Einträge in der /etc/fstab für beide Vorrang vor anderen Konfigurationen haben.

Man nehme einfach mal ein Ubuntu mit einem Kernel < 6.2 und lösche die Datei /usr/sbin/mount.ntfs und schon wird ein ntfs-Dateisystem mit dem alten Kernel-Modul ntfs eingebunden, wenn

sudo mount /dev/sdXY /my/mpoint 

oder

sudo mount -t ntfs /dev/sdXY /my/mpoint 

ausgeführt wird. Ein

sudo mount -t ntfs-3g /dev/sdXY /my/mpoint 

ist dann notwendig, um die Standard-Kernel-Modul-Wahl wiederum für den angegebenen Mount-Vorgang zu überschreiben.

Beim Dateisystemtyp ntfs kommt aktuell noch hinzu, dass es zwei Kernel-Module gibt. Deren Priorisierung untereinander dürfte wohl dem Kernel selbst innewohnen.

Bei mir (Xubuntu 22.04 LTS, Upgrade von 20.04, Kernel 5.15.0.97 generic) wird nach wie vor standardmäßig NTFS-3G gewählt.

Was hast Du denn jetzt aktuell für einen Kernel auf Deinem Xubuntu?

Die Frage wäre in Deinem Fall, wie das ntfs3 verhindert wird. Ist da vielleicht schon ein Blacklist-Eintrag vorhanden?

Zeigt

cat /proc/cmdline 

auf Deinem Xubuntu vielleicht etwas an?

LG, Newubunti

Die Frage wäre in Deinem Fall, wie das ntfs3 verhindert wird. Ist da vielleicht schon ein Blacklist-Eintrag vorhanden?

Genau das ist der Kern meiner Frage. Ich habe selbst nichts blacklisted, und die Situation ist auf zwei Laptops – beide gleichermaßen Xubuntu 22.04 und Upgrade von 20.04 – genau gleich.

Da ein Upgrade von LTS-Versionen ganz sicher kein seltener Sonderfall sein dürfte, müssen wir diese Situation leider mit in Betracht ziehen. Nur macht dies alles leider noch unübersichtlicher.

Ich bin fest überzeugt, dass es nicht an dem X liegt. Auf den verwendeten Kernel hat dies AFAIK keinen Einfluss.

Zeigt cat /proc/cmdline auf Deinem Xubuntu vielleicht etwas an?

nichts Zielführendes:

~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.15.0-97-generic root=UUID=a187ce8f-5755-4056-833a-7c1c799babb5 ro quiet splash vt.handoff=7

Den Kernel habe ich oben schon angegeben.

Die Angelegenheit mit den Symlinks war mir wohl bekannt. Sie betrifft so aber nur mount -t ntfs… und nicht das automatische Einbinden mittels udisks2 bzw. gio mount. Um das geht es hier. Und dabei wurde – Symlinks hin oder her – immer NTFS-3G vorgezogen. Auch ohne jeden fstab-Eintrag. Ich muss ’mal kontrollieren, ob ich vielleicht irgend etwas übersehen haben könnte. Sicher kein init-d-Skript, das mache ich nur, wenn unvermeidbar…

udisks2 kann aber - wenn wir udev und mount_options.conf außen vor lassen - im Code eine eigenständige Priorisierung gegenüber der von mount etablieren. Und das geschieht ja auch hinsichtlich ntfs3.

Auch das ist mir bekannt. Aber warum sollte das bei einem Upgrade anders sein als bei einer nativen Installation? Das ist doch die Crux…

Die Symlinks sind ja eine ganze Kette. Ich kann ’mal versuchen, diese weiter "innen" zu unterbrechen. Mal sehen, was das gibt.

Es stimmt zwar, dass ntfs3 nicht in der Manpage von mount beschrieben ist, aber dokumentiert ist dieses neue Modul durchaus. Es gibt die offizielle Kernel-Dokumentation:

https://docs.kernel.org/filesystems/ntfs3.html

Die kenne ich schon. Aber die ist recht mager und sagt nicht, was bei den anderen sog. "Dateisystem-unabhängigen" Mount-Optionen geschieht. man mount ist da meistens erklärender.

Max-Ulrich_Farber schrieb:

Die Frage wäre in Deinem Fall, wie das ntfs3 verhindert wird. Ist da vielleicht schon ein Blacklist-Eintrag vorhanden?

Genau das ist der Kern meiner Frage. Ich habe selbst nichts blacklisted, und die Situation ist auf zwei Laptops – beide gleichermaßen Xubuntu 22.04 und Upgrade von 20.04 – genau gleich.

Da ein Upgrade von LTS-Versionen ganz sicher kein seltener Sonderfall sein dürfte, müssen wir diese Situation leider mit in Betracht ziehen. Nur macht dies alles leider noch unübersichtlicher.

Ich bin fest überzeugt, dass es nicht an dem X liegt. Auf den verwendeten Kernel hat dies AFAIK keinen Einfluss.

Zeigt cat /proc/cmdline auf Deinem Xubuntu vielleicht etwas an?

nichts Zielführendes:

~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.15.0-97-generic root=UUID=a187ce8f-5755-4056-833a-7c1c799babb5 ro quiet splash vt.handoff=7

Den Kernel habe ich oben schon angegeben.

...

Aber warum sollte das bei einem Upgrade anders sein als bei einer nativen Installation? Das ist doch die Crux…

Mir war nicht ganz klar, ob Du unter Xubuntu immer noch auf Kernel 5.15 bist. Du könntest unter Xubunut nämlich unter 22.04 auch auf einem Kernel >= 6.2 sein.

Solange Du einen Kernel < 6.2 verwendest, bist Du bei 22.04 vom Fallback aufgrund des nicht unterstützten windows_names betroffen, dass bei udisks ab Version 2.8.2 einprogrammiert ist.

Ändere das in der /etc/udisks2/mount_options.conf wie folgt ab:

[defaults]
# Das sind die udisks-Defaults:
# # ntfs3, ntfs-3g and the legacy ntfs kernel driver options
# ntfs_defaults=uid=$UID,gid=$GID,windows_names
# ntfs_allow=uid=$UID,gid=$GID,umask,dmask,fmask,locale,norecover,ignore_case,windows_names,compression,nocompression,big_writes,nls,nohidden,sys_immutable,sparse,showmeta,prealloc
######
# Das ist die Anpassung:
ntfs_defaults=uid=$UID,gid=$GID
ntfs_allow=uid=$UID,gid=$GID,umask,dmask,fmask,locale,norecover,ignore_case,windows_names,compression,nocompression,big_writes,nls,nohidden,sys_immutable,sparse,showmeta,prealloc

Dann solltest Du auch mittels ntfs3 einhängen, falls udisks mit im Spiel ist.

LG, Newubunti

EDIT:

Aber warum sollte das bei einem Upgrade anders sein als bei einer nativen Installation? Das ist doch die Crux…

Habe gerade in einer VM mal ein Upgrade von 20.04 auf 22.04 gemacht. Vorgehensweise dabei nach offizieller Dokumentation für Desktop-Upgrade. Situation nach Neustart:

focal@focalvm01:~$ dpkg -l linux-image-generic* | grep ii
ii  linux-image-generic           5.15.0.97.92           amd64        Generic Linux kernel image
ii  linux-image-generic-hwe-20.04 5.15.0.97.107~20.04.51 amd64        Generic Linux kernel image
focal@focalvm01:~$ 

Bei einer Neuinstallation sieht es dagegen so aus:

jammy@jammyvm01:~$ dpkg -l linux-image-generic* | grep ii
ii  linux-image-generic-hwe-22.04 6.5.0.21.21~22.04.11 amd64        Generic Linux kernel image
jammy@jammyvm01:~$ 

LG, Newubunti

Danke Newubunti, jetzt wird mir alles klar.

Dass man nach einem Upgrade nicht den gleichen Kernel bekommt wie bei einer Neuinstallation, wusste ich nicht. Damit hatte ich auch wirklich nicht gerechnet.

An den Eintrag in /etc/udisks2/mount_options.conf hatte ich auch schon gedacht, und ich wollte ihn schon als Workaround vorschlagen, doch ich hatte eben noch nicht geprüft, ob er wirklich hart codierte Einstellungen überschreibt. Also ist ein Workaround für das ganze Problem doch recht einfach möglich.

Ich habe jetzt das dringende Bedürfnis, dass wir mit NTFS-3G (das zudem von dem Problem nur indirekt betroffen ist) recht bald zu einem Schluss kommen. Zu viel Zeit ist da schon hinein geflossen. Und ein befriedigender Abschluss scheint mir jetzt möglich zu sein.

Mein Vorschlag:

• fstab-Eintrag und mount -t <Treiber> grundsätzlich nur mit expliziter Treiber-Angabe empfehlen

• Dort die Option windows_names bei Versionen vor 23.10 beim Treiber ntfs3 lieber weglassen (oder nofail bei fstab)

• Sich bei ntfs-3g genau an die in man mount.ntfs-3g aufgeführten Optionen halten und insbes. users und user vermeiden (ist auch unnötig).

• Für Hotplug, DM, GUI und gio mount überprüfen, ob die in /etc/udisks2/mount_options.conf erlaubten Optionen für den verwendeten Treiber passen und nötigenfalls windows_names weglassen

• Wenn gewünscht, durch "hinten" bei 99… angehängte Regel in /etc/udev/rules.d den gewünschten Treiber erzwingen.

Das müsste eigentlich IMO so funktionieren. Als ultima ratio käme dann noch Blacklisting in Frage.

Ist das alles so ok? – Obwohl sich dies alles eigentlich nicht direkt auf NTFS-3G bezieht, müsste es (vorübergehend?) halt in diesem Artikel untergebracht werden.

Gruß – Max-Ulrich

EDIT:

@Newubunti: Ich weiß, "never touch a running system…". Trotzdem: Kann ich auf einem meiner Laptops problemlos Kernel 6.5.xx drüber installieren, oder zerschieße ich damit mein System? Und gibt es ggf. ein Metapaket, das alles auf einmal erledigt, oder welche Pakete muss ich zusammen installieren?

Ich habe jetzt den Abschnitt "Einhängen..." noch nach den gesammelten Erkenntnissen feingeschliffen.

Max-Ulrich_Farber schrieb:

Mein Vorschlag:

• fstab-Eintrag und mount -t <Treiber> grundsätzlich nur mit expliziter Treiber-Angabe empfehlen

Habe ich umgesetzt, wegen späterer Gleichförmigkeit im Wiki hinsichtlich eines Artikels ntfs3.

• Dort die Option windows_names bei Versionen vor 23.10 beim Treiber ntfs3 lieber weglassen (oder nofail bei fstab)

Das betrifft IMO diesen Artikel nicht und es gibt in diesem Artikel keinen Grund, das so zu empfehlen, denn ntfs-3g kommt in allen derzeit aktuellen Versionen mit dieser Option klar. Wenn man ntfs3 verwenden will, dann spielt das eine Rolle. Aber das wollen wir hier ja gerade nicht.

• Sich bei ntfs-3g genau an die in man mount.ntfs-3g aufgeführten Optionen halten und insbes. users und user vermeiden (ist auch unnötig).

Ich habe jetzt darauf hingewiesen, die beiden von Dir explizit genannten Optionen nicht zu verwenden.

• Für Hotplug, DM, GUI und gio mount überprüfen, ob die in /etc/udisks2/mount_options.conf erlaubten Optionen für den verwendeten Treiber passen und nötigenfalls windows_names weglassen

Ist im Moment eigentlich nur ein Problem für ntfs3, aber wie von UlfZibis weiter vorne schon angemerkt, sollte man darauf aufmerksam machen, dass diese Option seit udisk 2.8.2 standard ist, was IMO aber eher in den Abschnitt "Standard-Einstellungen" gehört.

• Wenn gewünscht, durch "hinten" bei 99… angehängte Regel in /etc/udev/rules.d den gewünschten Treiber erzwingen.

Gegen die udev-Regel sträube ich mich noch ein wenig, lasse mich aber gegebenenfalls mehrheitlich überstimmen.

Begründung:

Das Manipulieren der Eigenschaft ENV{ID_FS_TYPE} ist keine udisks-eigene Eigenschaft wie z.B. ENV{UDISKS_SYSTEM}. Man dreht hier zwecks gewünschter Treiberauswahl am Dateisystemtyp und manipuliert diesen in Richtung ntfs-3g. Einen solchen Dateisystemtyp gibt es aber eigentlich nicht. Es gibt nur das Dateisystem ntfs und dann eben verschiedene Treiber, die damit umgehen können.

Theoretisch ist eine solche Manipulation dazu geeignet, Probleme verursachen zu können. Man sieht die Auswirkung, wenn man bei aktiver udev-Regel die Ausgaben folgender Befehle vergleicht:

sudo blkid -p
lsblk --fs 

Bei ersterem wird als Dateisystemtyp ntfs angezeigt, bei letzterem ntfs-3g.

Da diese Regel praktisch eigentlich nur für Ubuntu 22.04 eine Rolle spielt und es ab 23.10 bzw. udisks 2.10.X eine bessere Alternative über die Datei /etc/udisks2/mount_options.conf gibt, plädiere ich gegen die Aufnahme in den Wiki-Artikel.

@Newubunti: Ich weiß, "never touch a running system…". Trotzdem: Kann ich auf einem meiner Laptops problemlos Kernel 6.5.xx drüber installieren, oder zerschieße ich damit mein System? Und gibt es ggf. ein Metapaket, das alles auf einmal erledigt, oder welche Pakete muss ich zusammen installieren?

Ich übernehme selbstverständlich keine Haftung, aber unter normalen Umständen sollte die parallele Installation verschiedener Kernel-Linien kein Problem verursachen, weil man ja praktisch am Ende immer nur einen dieser Kernel gleichzeitig betreiben kann.

Das generische Paket für den Ubuntu HWE Kernel für 22.04 ist grundsätzlich linux-image-generic-hwe-22.04. Ob es das für Xubuntu auch gibt, kannst Du ja vorher mit prüfen.

sudo apt install linux-image-generic-hwe-22.04 

sollte Dich zum aktuell verfügbaren HWE-Kernel bringen.

LG, Newubunti