XFCE - neues Filesystem einbinden

[HumiNi]

Moin

Ich habe gestern auf meinem (immer noch recht) neu installiertem bookworm mit XFCE eine neue Partition mit gparted angelegt und habe danach vergeblich eine grafische Möglichkeit gesucht, diese Partition in die fstab zu bekommen. Ich musste dann einige Anstrengungen unternehmen mich zu erinnern, wie es händisch geht. Funktioniert jetzt auch mit diesem Eintrag in der fstab:

Code: Alles auswählen

PARTLABEL=Sicherungen			/Sicherungen	ext4	noauto,defaults 0 2

(Dabei war es auch eine kleine Hürde herauszubekommen, dass man GPT-Partitionen mit PARTLABEL (statt LABEL) einbindet.)

Meine Frage ist jetzt nur, wo ich etwas übersehen hab, was mir das manuelle Einbinden abgenommen hätte. Danke.

[rhHeini]

MMN: es gibt nichts vernünftigeres als so etwas auf der Konsole zu machen.

[hikaru]

Vorausgesetzt, thunar-volman ist installiert, solltest du in Thunar vorhandene, aber nicht gemountete Dateisysteme angezeigt bekommen und per Klick (und unter Eingabe deines, oder des root-Passworts - je nach sudo-Konfiguration) temporär einhängen können.
Ein GUI für permanente Mounts ist mir unter Xfce nicht bekannt.

(Dabei war es auch eine kleine Hürde herauszubekommen, dass man GPT-Partitionen mit PARTLABEL (statt LABEL) einbindet.)

Dateisysteme auf GPT können sowohl über das (Dateisystem-)Label, als auch über das Partlabel gemountet werden - vorausgesetzt die Label sind vorhanden.
Erzeugt man die Partitionen/Dateisysteme mit Gparted und ist es gewohnt, nur ein Label anzugeben, dann vergibt man schon mal ein Partlabel aber kein Dateisystemlabel, und kann Letzteres folglich auch nicht nutzen.
In deinem Fall köntest du das Dateisystemlabel nachträglich vergeben und dann auch nutzen:

Code: Alles auswählen

# tune2fs -L "Sicherungen" /dev/disk/by-partlabel/Sicherungen

[HumiNi]

Danke für die ausführliche Erklärung. Ich war davon ausgegangen, dass alles, was der Installer grafisch kann, auch im laufenden System gleichartig möglich ist.

[HumiNi]

MMN: es gibt nichts vernünftigeres als so etwas auf der Konsole zu machen.

Das mag wohl stimmen, ABER:
Wenn das nicht dein Tagesgeschäft ist bzw. seit vielen Jahren nicht mehr ist, kramt man die passenden grauen Zellen nur mit gaaanz viel Mühe wieder vor. Ich jedenfalls.

[thunder11]

Wieder allen "vernünftigen" Empfehlungen (ich mache es auch "zu Fuss") :
Man kann unter XFCE auch gnome-disk-utility installieren.
Ist auch für vieles Andere nützlich.

Literaturtipp: Mit der Suchmaschine deines Vertrauens nach fstab suchen.
Man glaubt nicht, wie viel Treffer da kommen.

[HumiNi]

Literaturtipp: Mit der Suchmaschine deines Vertrauens nach fstab suchen.
Man glaubt nicht, wie viel Treffer da kommen.

Genau das ist grundsätzlich eher das Problem. Wie filtert man aktuell gültige Lösungen heraus? Mein Gedächtnis - wenn es auch zuerst störrisch war - hat mich doch zum Ziel geführt.

BTW. Du glaubst nicht, wie viele fstab ich in meinem früheren Leben (länger als 10 Jahre zurück) händisch bearbeitet habe. Aber das Gedächtnis lässt eben nach...

[HumiNi]

Ich habe da noch eine Nachfrage zur Änderung der fstab. Nach Änderung und anschließendem "mount <neues FS>" erhalte ich:

Code: Alles auswählen

mount: (Hinweis) Ihre Fstab-Datei wurde geändert, aber Systemd nutzt
       noch die alte Version; verwenden Sie »systemctl daemon-reload«
       zum Neuladen

... obwohl das FS wie erwartet gemounted wird.
Was will mir der Hinweis sagen? Warum interessiert sich systemd für die fstab-Änderung?

[thunder11]

Was will mir der Hinweis sagen? Warum interessiert sich systemd für die fstab-Änderung?

Weil systemd de facto für das Mounten zuständig ist.

Die fstab ist nur die Vorlage für die Mount Vorgänge von systemd.
Kannst mal hier nachschauen: /run/systemd/generator/

Deshalb: Reload oder Neustart.

Literatur: https://wiki.ubuntuusers.de/systemd/Mount_Units/

[GregorS]

... Aber das Gedächtnis lässt eben nach...

Das ist halt Mist, der „durchrutscht“ (s. Deine Signatur)

Gruß

Gregor

[HumiNi]

Was will mir der Hinweis sagen? Warum interessiert sich systemd für die fstab-Änderung?

Weil systemd de facto für das Mounten zuständig ist.

Die fstab ist nur die Vorlage für die Mount Vorgänge von systemd.
Kannst mal hier nachschauen: /run/systemd/generator/

Deshalb: Reload oder Neustart.

Das klingt ja schön und gut. Aber einem Unix-Grufti wie mir fällt keine Situation außer dem Neustart ein, wo das System automatisch mounten möchte, also der Hinweis relevant wäre.

[thunder11]

Das klingt ja schön und gut. Aber einem Unix-Grufti wie mir fällt keine Situation außer dem Neustart ein, wo das System automatisch mounten möchte, also der Hinweis relevant wäre.

Beim Neustart liest systemd die fstab und generiert daraus seine mount-Units.
Es könnten ja in der fstab bestimmte Parameter stehen, (Berechtigungen, idle-timeout für das LW usw)
die systemd mit einem Mount- Befehl so nicht steuern kann.
Daher der dezente Hinweis

Heutzutage ist die fstab an sich überflüssig. Das kann man alles in in Systemd-Mount-Units erstellen.

[dasebastian]

... kann man alles in in Systemd-Mount-Units erstellen.

Hui, wieder was zum Schmökern, danke für den Hinweis.

[KP97]

Ich mache alles mit systemd, auch das Mounten meiner internen Testpartition.
In /etc/systemd/system eine Datei namens media-Test.mount erstellen mit folgendem Inhalt:

[Unit]
Description = Test einhängen
Before=local-fs.target

[Mount]
Where=/media/Test
What=/dev/sda3
Type=ext4
Options=defaults,users

[Install]
WantedBy=multi-user.target

Die Namenskonvention ist wichtig, da schon daraus hervorgeht, was und wohin gemounted werden soll.
Dann mit systemctl enable die Unit bekannt machen, und das war's auch schon.
Das funktioniert bei jedem Start und hat noch nie versagt.

man systemd.mount sollte man vorher gelesen haben.

[HumiNi]

[Unit]
Description = Test einhängen
Before=local-fs.target

[Mount]
Where=/media/Test
What=/dev/sda3
Type=ext4
Options=defaults,users

[Install]
WantedBy=multi-user.target

Und das ersetzt eine fstab-Zeile? Oha.

[juribel]

Meine 2 ct zu diesem Thema: Da es sich um ein Sicherungslaufwerk zu handeln scheint, ist es nicht sehr klug, dieses immer eingebunden zu lassen, egal ob intern eingebaut oder als USB-Laufwerk. Wenn es nicht eingehängt ist, kann man darauf auch nichts kaputt machen.

Vor einem Sicherungsvorgang: das Laufwerk wird im Xfce-Dateimanager thunar angezeigt, sofern es nicht zuvor "ausgeworfen" wurde. Ein Klick darauf hängt es ein und es kann verwendet werden. Anschliessend rechter Mausklick auf das Laufwerk → Aushängen. Wenn es ein externes Laufwerk ist, kann es in diesem Zustand auch ausgestöpselt werden.

Da muss auf jeden Fall NICHTS in der /etc/fstab eingetragen werden.

Sicher ist sicher

[rhHeini]

Und das Laufwerk nicht als /dev/sdax sondern als /dev/disk/by-uuid oder by-label angeben ...

[HumiNi]

Ich zeige euch noch einmal meinen fstab-Eintrag:

Code: Alles auswählen

PARTLABEL=Sicherungen			/Sicherungen	ext4	noauto,defaults 0 2

[dasebastian]

man systemd.mount sollte man vorher gelesen haben.

Da ging ich gleich als erstes hin...

[ernohl]

man systemd.mount sollte man vorher gelesen haben.

Da ging ich gleich als erstes hin...

Wenn das notwendig wird, um ein neues Filesystem einzubinden, bin ich nach über 20 Jahren weg von Debian und ich suche mir eine systemd-freie Distri.

[GregorS]

man systemd.mount sollte man vorher gelesen haben.

Da ging ich gleich als erstes hin...

Wenn das notwendig wird, um ein neues Filesystem einzubinden, bin ich nach über 20 Jahren weg von Debian und ich suche mir eine systemd-freie Distri.

Das mit dem Wechsel zu Devuan habe ich Anfang Oktober erledigt. Das ist ein systemd-freies Debian.

Gruß

Gregor

[ernohl]

Das mit dem Wechsel zu Devuan habe ich Anfang Oktober erledigt. Das ist ein systemd-freies Debian.

Die Notwendigkeit sehe ich noch nicht.
Wir schweifen etwas ab, aber kurz dazu, was ich ausdrücken wollte:
Ich habe fast mein ganzes Leben als Unix- und später Linux-Systemadmin mein Geld verdient. Da hatte man permanent nicht bootende Systeme zu reparieren, oft wegen Filesystemproblemen. In eingeschränkten Systemumgebungen (single mode, maintanance mode, Rettungssystem,...) ist es einfach sehr hilfreich, kompakte config-Dateien zu haben (wie die fstab). Und genau die will ich auch im normalen Betrieb bearbeiten, damit sie mir im Ernstfall vertraut sind. Es ist eine Horrorvorstellung, im Ernstfall riesige systemd-units zu analysieren. Das ist ein NoGo für mich.
Falls systemd nicht mehr auf die klassischen Unix- bzw. Linux-configfiles zurückgreift, wäre für mich die Notwendigkeit zum Umstieg gegeben. Ich werde es niemals akzeptieren, zur Einrichtung eines FS irgendeine Unit zu bauen und dafür systemd-Doku lesen. Never ever.

[GregorS]

Das mit dem Wechsel zu Devuan habe ich Anfang Oktober erledigt. Das ist ein systemd-freies Debian.

Die Notwendigkeit sehe ich noch nicht.
Wir schweifen etwas ab, aber kurz dazu, was ich ausdrücken wollte:
Ich habe fast mein ganzes Leben als Unix- und später Linux-Systemadmin mein Geld verdient. Da hatte man permanent nicht bootende Systeme zu reparieren, oft wegen Filesystemproblemen. In eingeschränkten Systemumgebungen (single mode, maintanance mode, Rettungssystem,...) ist es einfach sehr hilfreich, kompakte config-Dateien zu haben (wie die fstab). Und genau die will ich auch im normalen Betrieb bearbeiten, damit sie mir im Ernstfall vertraut sind. Es ist eine Horrorvorstellung, im Ernstfall riesige systemd-units zu analysieren. Das ist ein NoGo für mich.
Falls systemd nicht mehr auf die klassischen Unix- bzw. Linux-configfiles zurückgreift, wäre für mich die Notwendigkeit zum Umstieg gegeben. Ich werde es niemals akzeptieren, zur Einrichtung eines FS irgendeine Unit zu bauen und dafür systemd-Doku lesen. Never ever.

Nachdem mit Debian 8 systemd kam, habe ich mich zunächst in Richtung Slackware von Debian verabschiedet. Nachdem ich damit nicht wieder glücklich wurde, habe ich wieder zurück gewechselt und mich auf das Dasein eines reinen Anwenders zurückgezogen. Mit dem systemd-Dreck wollte ich mich jedenfalls nicht beschäftigen.
Nunja, Devuan ist seit ich es kenne und nutze für mich zum optimalen Ersatz geworden und da Devuan aus den Debian-Quellen gebaut wird, brauchte ich mich beim Umstieg nicht mit möglicherweise anderen Programmversionen herumschlagen. Und das geliebte SysV-Init funktioniert im Ggs. zu systemd ohne jegliches Gehampel. Seither befasse ich mich auch wieder mehr mit dem System (also wieder mehr Admin als nur Anwender).

Devuan funktioniert auf mittlerweile allen meinen Rechnern vollkommen problemlos und v.A. deterministisch. Das war mit Debian nicht so.

Gruß

Gregor

[KP97]

Leute, bleibt doch mal ganz ruhig, niemand hat gesagt, daß die fstab nicht mehr zu pflegen wäre, das mounten daraus erledigt systemd-generator im Hintergrund, wie thunder11 auch schon angemerkt hat.
Man _kann_ systemd.mount nutzen, muß es aber nicht. Mein Hinweis richtete sich an die Interessierten, die es mal ausprobieren wollen.
Meine Unit ist für eine interne Partition gedacht, es gibt natürlich auch Möglichkeiten für externe Geräte.
Da ich zwar Xfce verwende, als Dateimanager aber spacefm, habe ich dafür udevil installiert. Der erledigt den Job zuverlässig und äußerst komfortabel, ganz ohne fstab, gvfs und udisks2.
Leider kommt Thunar damit nicht zurecht, sehr schade.

@ernohl
Gerade wenn man soviel Erfahrung hat, ist es doch interessant, mal was Neues kennenzulernen und nicht im immer Gleichen zu verharren.
Da muß man keine Distro wechseln...

@HumiNI
Noch ein Hinweis:
Wenn Du einen Eintrag in der fstab hast, schau mal in /run/systemd/generator. Da müßte dann eine Unit des Gerätes stehen, die von systemd automatisch angelegt wurde. Wenn Du die öffnest, siehst Du, was der Generator aus dem Eintrag in der fstab generiert.
Das kann man auch für was Eigenes nehmen, zwar nicht 1:1 aber als Vorlage taugt es allemal.

[KP97]

So, damit man sich ein umfassenderes Bild machen kann, habe ich auch für ein USB Gerät eine Unit angelegt.
Meine USB Platte heißt mit Label Backup, wie zuvor schon erwähnt, habe ich zwar Xfce, aber weder gvfs noch udisks2 installiert.
Daß der mountpoint in /media existieren muß, setze ich als Wissen voraus.

Also wieder in /etc/systemd/system eine Datei mit Namen media-Backup.mount anlegen mit diesem Inhalt:

Code: Alles auswählen

[Unit]
Description = USB-Platte einhängen
After=blockdev@dev-disk-by\x2dlabel-Backup.target

[Mount]
What=/dev/disk/by-label/Backup
Where=/media/Backup
Type=ext4
Options=defaults,noauto,nofail,users

[Install]
WantedBy=multi-user.target

Dann systemctl enable media-Backup.mount ausführen.
Wenn ich nun die Platte einschalte, wird diese auch direkt gemounted, wie bereits erwähnt ohne fstab, gvfs und udisks2.
Die Platte erscheint natürlich auch in Thunar, systemd.mount steht obendrüber und kümmert sich nicht um gvfs.
Wenn ich umounte, verschwindet der Eintrag auch wieder, ganz wie es sich gehört.
Wenn ich z.B. drei Geräte habe, muß ich auch drei Units anlegen, da sich die Namen ja unterscheiden. Das ist aber kein Aufwand, kann man ja kopieren.

Ich überlege, ob ich das in die gesammelten Werke eintrage, der Ein oder Andere hat sicher Interesse.