Eigene fstab-Datei verstehen

Thorakon

Lt. Junior Grade
Registriert
Sep. 2014
Beiträge
433
Hallo,

ich muss ggf. in naher Zukunft die fstab Datei editieren um eine interne NTFS-Datenaustausch-Partition beim Systemstart von Kubuntu einzubinden. (Aktuell klappt es irgendwie doch grad wieder über KDE GUI-Tools zur Medienverwaltung scheint mir, aber es funktionierte die Tage davor nicht zuverlässig).

Bevor ich das mache, würde ich gern verstehen, was jetzt schon drin steht (ohne direkten Eingriff von mir) - und bei einem Eintrag bin ich unsicher, was der zu bedeuten hat.
fstabFrage.png

Warum gibt es den Eintrag in Zeile 14 zu /dev/nvme1n1p2 - ntfs, und bewirkt er irgendwas? Wird diese Partition nicht von meiner Linux-Homepartition mit ext4 ausgefüllt? Vgl. fstab Zeile 8/9 und Output von Befehl blkid:
/dev/nvme1n1p2: UUID="a246a642-6c05-4053-a721-b5b4234e2133" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="7c7781ec-9eba-4a90-a3d4-f8ecbf30ae7a"


Hintergrundinfos:
Ich verwende ein Dual-Boot mit Win 11 und Kubuntu 24.04 auf getrennten SSDs, Kubuntu wurde zuerst installiert. Die Win-Systempartition will ich absichtlich nicht unter Linux sehen. Auf jeder SSD liegt noch eine NTFS-Datenaustauschpartition. Siehe die Screenshots aus der Partitionsverwaltung.
Partitionen1.jpg
Partitionen2.jpg


Vielen Dank vorab für eure Hilfe.
Beste Grüße
Thorakon
 
Thorakon schrieb:
Warum gibt es den Eintrag in Zeile 14 zu /dev/nvme1n1p2 - ntfs, und bewirkt er irgendwas?
Da es keinen Einhängepunkt gibt, wird da auch nichts passieren. Ich kann mir vorstellen das der Eintrag durch ein Livesystem generiert wurde. Kann es sein das du aus einem Livesystem heraus installiert hast und die nur die Partitionen verändert hast, nicht aber einen ganz neuen Partitiontable erstellt hast?

Zum testen kannst du die Zeile einfach mal auskommentieren.
 
  • Gefällt mir
Reaktionen: SmokySmiley und CountSero
Bietet sich eine exFAT Datenaustausch Partition nicht eher an? Also wenn du diese eh schon hast. Ansonsten könntest du auch einfach hiermit direkt von ext4 Daten nach Windows ziehen.

Und zur Frage, das sind tatsächlich keine Einhängepunkte sondern wahrscheinlich Leichen aus der Installation.
 
Thorakon schrieb:
Bevor ich das mache, würde ich gern verstehen, was jetzt schon drin steht (ohne direkten Eingriff von mir)
In der fstab stehen die Daten wie folgt drinnen (von links nach rechts):
1. Gerät, das eingehängt wird (das kann eine Partition eines Laufwerks oder sogar ein Netzwerk-Share sein)
2. Der Mount-Point, der Pfad im Linux-Dateisystem, wo das Gerät eingehängt wird
3. Das zu verwendende Dateisystem
4. Optionale Mountoptionen, die zusätzlich angewandt werden
5. Dump überprüft bei ext2/3(/4?)-Partitionen, welche Daten gesichert werden müssen (braucht glaube ich das Programm dump)
6. Pass bzw. Fsck überprüft die Geräte und macht ggf. Reparatur vom Linux-Dateisystem

Der erste Eintrag ist der zu deiner Root-Partition (/), definiert durch die Partition-UUID; der zweite Eintrag ist der zu deiner EFI-Partition (/boot/efi), bestimmt durch die Dateisystem-UUID; der dritte Eintrag ist der zu deiner Swap-Partition, auch hier durch die Partition-UUID bestimmt; der vierte Eintrag ist nochmal deine Root-Partition (/) und der fünfte Eintrag ist (vermutlich) der zu deiner Windows-Partition.

EDIT: Weitere Infos zur fstab findest du auch noch im Ubuntuusers-Wiki und im Arch-Wiki.

Thorakon schrieb:
Warum gibt es den Eintrag in Zeile 14 zu /dev/nvme1n1p2 - ntfs, und bewirkt er irgendwas?
Keine Ahnung, warum da NTFS angegeben ist. /dev/nvme1n1p2 verweist auf deine Root-Partition, das tut der Eintrag mit UUID=a246a642-6c05-4053-a721-b5b4234e2133 allerdings auch und da ist ext4 als Dateisystem auch korrekt angegeben. Da der Eintrag /dev/nvme1n1p2 allerdings mit dem Mount-Point None angegeben ist und so erstmal nicht gemounted wird, sollte da nichts weiter passieren können. Ansonsten den Eintrag einfach mal auskommentieren.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: R00kie und Keylan
Das ist genau der Klassiker wegen dem immer geraten wird, die UUID zum identifizieren des Datenträgers zu verwenden.
Die mount pfade wie /dev/nvme1n1p2 werden vom Kernel beim Boot abhängig von der Reihenfolge der erkannten Geräte zugewiesen. Diese Reihenfolge ist aber nicht komplett deterministisch weshalb sie sich insbesondere beim Ein- und Ausbau weiterer Datenträger, in seltenen Fällen aber auch ohne solche Handlungen ändern können.

Hier wird die Partitionsverwaltung welche eben auch bei Installation oder auf Eingriff eines Nutzers (sudo) die fstab bearbeiten kann, diese Einträge angelegt haben auch wenn einer davon augenscheinlich nicht verlässlich auf den angegebenen pfad zugewiesen wird.

Solange das System/boot und / findet wird es trotzdem starten und fehlerhafte Zuweisungen ggf. ignorieren.
Ergänzung ()

Hyourinmaru schrieb:
Keine Ahnung, warum da NTFS angegeben ist. /dev/nvme1n1p2 verweist auf deine Root-Partition
Tut sie nicht, der Eintrag mit der UUID steht zum glück zuerst und deshalb wird der andere Eintrag ignoriert.
Der ist definitiv in einem anderen Boot oder bei Installation geschrieben worden und hat seit dem keine echte Auswirkung.
 
  • Gefällt mir
Reaktionen: CountSero und Hyourinmaru
@Der_Dicke82: Kann gut sein...ich habe höchstwahrscheinlich vom USB-Stick das Kubuntu 22.0x-live-System geladen und dann erst von dort aus den Installationsprozess auf der SSD angestoßen. Die hatte bis dahin Werkszustand, für die Installation bin ich irgendeiner Anleitung (evtl. aus der c't) gefolgt, die ich leider nicht mehr parat habe.
Da ich in versch. Guides gewarnt wurde, das falsche Einträge mein System evtl. nicht mehr starten lassen, wollte ich vor dem auskommentieren lieber nochmal nachfragen. (Klar, man kann die Datei sichern und live-System zum wiederherstellen verwenden, wenn ich sie dann wirklich ergänze werde ich das Backup machen.)

@mytosh: Ich habe mich an bestimmte Empfehlungen gehalten und komme an sich seit Monaten gut mit NTFS auf der internen Partition klar. Damals war ich mir auch noch nicht sicher, dass Linux mein Hauptsystem wird.

@Hyourinmaru: Danke auch nochmal für deine Erläuterung. Die anderen Einträge habe ich soweit auch verstanden, ja.

Aus-/umgebaut habe ich die SSDs soweit ich mich erinnere nicht (Kühlkörper klebt drauf).

Wird jetzt spät, ich melde mich morgen nochmal was nach der Änderung passiert ist. Ob z.B. ein Programm das gleich wieder so anlegt. Danke schonmal an alle.
 
  • Gefällt mir
Reaktionen: Hyourinmaru
Keylan schrieb:
Tut sie nicht, der Eintrag mit der UUID steht zum glück zuerst und deshalb wird der andere Eintrag ignoriert.
Würde das System einen Eintrag mit Gerätedatei und einen mit UUID nicht trotzdem korrekt zuordnen, sofern die Gerätedatei und die UUID auf dieselbe Partition verweisen und keine der beiden NVMe ausgebaut wird?
 
Die Einträge werden von oben nach unten abgearbeitet und wenn ein Eintrag ein valides Einhängen des Datenträgers erlaubt hat dieser Vorrang. Ein weiterer Eintrag der auf das selbe Gerät verweist wird dann ignoriert bzw. führt zu einem Fehler der aber für sich nicht zum kritischen Abbruch führt.

Wie gesagt startet das System wenn / und /boot gefunden werden und korrekt konfiguriert sind. Ob dann auch alles gefunden wird um einen Desktop zu starten oder einen Benutzer anzumelden ist eine andere Frage.

Es gibt, wenn ich mich recht Erinnere 5 Methoden ein Gerät zu identifizieren.

1. den vom Kernel erzeugte Pfad, der auch für automount von z. B. externen Datenträgern genutzt wird, aber wie gesagt nicht verlässlich deterministisch ist.

2. Die UUID die beim Formatieren einer Partition erzeugt wird.

3. Das Label des Dateisystems, welches aber nicht nur optional ist, sondern auch nicht zwingend eindeutig ist.

4. Die PARTUUID welche direkt in der Partitionstabelle angelegt ist.

5. Das Partitionslabel, welches ich nie genutzt habe und auch nicht wüste, dass dieses zwingend angelegt wird oder ob dieses Eindeutig ist.

Die Empfehlung ist ganz klar, mit den UUID's zu arbeiten, da diese bis zur Neuformatierung beständig und eindeutig sind.
Wer aber sein System händisch richtig einrichtet und die Abhängigkeiten dabei selbst überblickt, kann auch problemlos z.B. mit den Labels arbeiten.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Thorakon, CountSero, Alter_Falter und eine weitere Person
Mit dem hier klappt es hier bei mir unter Mint.

1747182892711.png


sdb1 ist ein Datentraeger im NTFS-Format.
Code:
UUID="69633D720C053DBE" /media/windows ntfs-3g uid=1000,locale=de_DE.utf8 0 0
1747182991503.png
 
Es steht in der fstab doch explizit drin.
Schau doch den ersten Screenshot von Dir einfach an.
/ was on ..... during installation
/boot/efi was on ..... during installation
Das ist wohl übrig, ich würde die Zeile 14 einfach mal auskommentieren.
 
Also nochmal zur Verständnis!
Ja Zeile 14 kann WEG!, die macht so keinen Sinn, da haben die Ubuntu Leute wohl nicht aufgepasst.
Da wird mir "ro" versucht die Partition auf "Read Only" für die Gruppe "users" zu stellen, und angeblich ist die Partition in "NTFS" ist sie aber nicht!
Sprich das ist wirklich ein Rest von der Installation, die vergessen würde zu entfernen.

Und da glücklicherweise weiter oben bereit das ganze korrekt eingerichtet würde wird das ignoriert.🙄

Zeile 15 würde ich drin lassen, da wird die Windows Partition auf der Kingston über "noauto" auf nicht automatisch einhängen und mit "ro,users" auf nur lesend einbinden gestellt, falls du diese doch irgendwann mal mounten willst, das ist wohl von der GUI der Medienverwaltung.
Das kann nicht schaden.😏
 
Keylan schrieb:
Diese Reihenfolge ist aber nicht komplett deterministisch weshalb sie sich insbesondere beim Ein- und Ausbau weiterer Datenträger, in seltenen Fällen aber auch ohne solche Handlungen ändern können.

Das ist kein seltener Fall. Bei nur einer NVME passiert nichts das kann dann ja nur nvme0 sein.

Aber bei jedem System mit mehreren NVMEs ändern diese ihre Nummern bei Reboots. Eben weil es keine Reihenfolge gibt sondern wer zuerst antwortet bekommt die erste freie Nummer. Das ist dann bei jedem Systemstart ein Wettrennen bzw. ein Lotterie Los.

fstab Einträge die sich nicht auf Uuid, Label oder feste LVM Namen beziehen sind streng genommen immer falsch.
 
  • Gefällt mir
Reaktionen: rgbs
kieleich schrieb:
fstab Einträge die sich nicht auf Uuid, Label oder feste LVM Namen beziehen sind streng genommen immer falsch.
Diese Aussage kann so nicht stehen gelassen werden. Das war früher absoluter Standard bei allen mir bekannten Distributionen, SuSE, Debian, usw. usf.

Geändert wurde das erst wegen der Möglichkeit, dass es dazu kommen kann, dass die Geräte gewürfelt werden. Das kann übrigens auch an anderen Stellen, wie etwa Netzwerkinterfaces passieren.
 
  • Gefällt mir
Reaktionen: BFF
Das kann ich jetzt so nicht stehen lassen 😏.
Die Änderung war Ende der Nuller Jahre, und schon damals würde von jeder ernsthaften Linux Distro darauf hingewiesen das man die Uuid für interner Laufwerke verwenden sollte, da die "alten" Bezeichnungen nicht mehr sicher funktionieren!

Das über 15 Jahre später das immer noch theoretisch geht, liegt halt daran, das im Linux Kernel sowas halt immer sehr lange braucht bis es rausfliegt!, siehe aktuell die 486 CPU's.😉
 
  • Gefällt mir
Reaktionen: Grzly und Piktogramm
Ok, ich hatte der Einfachheit halber nur darauf hingewiesen, dass die Zuordnung der Gerätepfade/Gerätedatei nicht streng deterministisch ist.
Das ist eine Abstraktion. Es heist nicht, dass hier gewürfelt wird, oder dass hier eine Zufälligkeit im Sinne quantenmechanischer Wahrscheinlichkeiten einspringt.

Es bedeutet vielmehr, das diese Zuordnung von Rahmenparametern anhängig ist, welche in diesem Kontext in der Regel nicht streng kontrolliert werden, oder zumindest nicht streng genug um einen Wechsel der Zuordnung auf diese Rahmenparameter zurückführen zu können.

Wer Details will, über die Lösung und den Bezug warum dies erst seit GTP Partitionierung so standardisiert wird, kann sich hier einlesen.

Defacto werden Systeme, wenn die Hardware nicht gewechselt wurde, in den meisten Fällen die Zuordnung der Gerätepfade Konsistent über mehrere Bootvorgänge identisch durchführen.

Wie Richtig angemerkt hängt diese Reihenfolge von der Antwortzeit der Geräte bei der Initialisierung durch den Kernel ab.

Ob ein System dabei Anfällig für Schwankungen ist, hängt in der Regel vom Bus des Mainboards ab. Viele Schnittstellen im Bus geben sehr vorhersehbar Prioritäten oder haben kürzere Übertragungswege zu bestimmten Anschlüssen.
Ursache für Schwankungen sind dabei oftmals auf Spannungsschwankungen (sehr klein und absolut innerhalb vorgegebener Größen) aber auch Übertragungsfehler die oft durch automatische Fehlerkorrekturen in den Gerätecontrollern abgefangen werden aber eben dabei zu Millisekunden an Verzögerung führen können.

Wenn also jemand wirklich feststellt, das seine 5 Geräte bei jedem Boot wahrlos gewürfelt werden, hätte einen extremen Fall, der auf Schäden am Mainboard, am PSU oder an der Mehrzahl der Geräte hinweist.

Wenn das nur nur hin und wieder mit einzelnen Drehern passiert, ist das ganz normal und kann schon an minimaler Korrosion am Mainboard oder in Abhängigkeit von Temperatur oder Luftfeuchtigkeitsunterschieden auftreten.
 
Zurück
Oben