Hallo, wage mich gerade an FreeBSD heran. Momentan tute ich mir schwer bei dem mounten von HDD's (4TB) eine davon via usb angeschlossen.
Das gewohnte funzt nicht wie z.B. 'fdisk -l' für die Laufwerksübersicht und 'sudo blkid' für die uuid.
z.B. hier alte fstab Ausschitte betreffend der HDD's:
# /dev/sdb1
UUID=456A2AB63A6D2873 /mnt/hdd1 ntfs-3g defaults 1 2
# /dev/sdc1
UUID=5F82438B5D3A2BB1 /mnt/hdd2 ntfs-3g defaults 1 2
Aber bevor ich die Einträge in die fstab von FreeBSD eintragen kann, versuche ich mich gerade in der Konsole mit dem mount, auch das funzt nicht, anbei mein Versuch:
# mount -t ntfs /dev/da1p1 /mnt/hdd1
mount: /dev/da1p1: Operation not supported by device
Wie bekomme ich das in der Konsole gemountet sowie die uuid's der Laufwerke angezeigt damit diese später in die fstab eingetragen werden können und wie ist der Aufbau der fstab in FreeBSD?
Die Sache funktioniert etwas anders als unter Linux. Linux verhält sich in Sachen Device Management und dem Mounten von Devices weitgehend wie ein klassisches Unix. Jedes physische oder virtuelle Gerät wird über eine Device Node anhand von Major Numbers (für den Treiber) und Minor Numbers (für das einzelne Gerät) angesprochen. Die Device Nodes müssen händisch angelegt werden. Auf modernen Distros sieht der Nutzer das nur nicht, weil sich ein Mechanismus wie udev (entweder eigenständig oder als Teil eines größeren Framesworks wie dem berüchtigten systemd) um das Anlegen kümmert. Dinge wie UUIDs für Dateisysteme kommen dabei einfach durch Symlinks zustande, für Abstraktionen wie Soft-RAIDs, per LUKS verschlüsselte Medien und so weiter gibt es mit dem Device Mapper eine recht simple Abstraktion.
FreeBSD ist andere Wege gegangen. Device Nodes können nicht mehr händisch angelegt werden, der Kernel stellt sie selbstständig über
devfs zur Verfügung. Sie haben keine Major Numbers. Für Endanwender wie dich ist das egal, aber wer Software auf FreeBSD portiert, muss das eventuell beachten. Man kann im devfs nur begrenzt symlinken, weil der Kernel jederzeit Änderungen vornehmen kann, die einen Symlink kaputt machen. Für Storage implementiert FreeBSD ein recht komplexes System mit dem namens GEOM. GEOM funktioniert in sogenannten Klassen, Klassen sind beispielsweise
gpart für Partitionen,
glabel für Partitionslabels,
gmirror für ein einfaches RAID1 und so weiter. Die Klassen werden "gestapelt", für den Anwender sieht es in etwa wie eine Matroskapuppe aus. Außen ist das Speichermedium, darauf folgen nach innen verschiedene Klassen und zuletzt das Dateisystem. Klingt erstmal kompliziert.
Daher ein Beispiel:
1. Außen ist ein Speichermedium. Klassische S-ATA Medien heißen
ada, alles was über SCSI angesprochen wird
da und NVMe-Medien
nvd. Nehmen wir als Beispiel mal eine ganz normale S-ATA SSD mit dem Namen
ada0.
2. Nun müssen Partitionen angelegt werden. Die Partitionen werden von der
gpart GEOM-Klasse gelesen, die daraufhin für jede Partition ein weiteres Device anlegt. Sagen wir der Einfachheit halber, dass es bei einer modernen GPT-Partition bleibt. Er erhält
ada0p1, also
ada0 für die SSD +
p1 für die erste und einzige Partition.
3. Der Nutzer möchte seine Partition verschlüsseln, dafür nimmt er
geli. Das ist eine GEOM-Klasse, nachdem er
geli init auf die Partition angewandt hat, erhält er nach dem Matroskaprinzip ein neues Devices
ada0p1.eli. Also
ada0 ganz außen,
p1 für die ersten Partition und darin
eli für die Verschlüsselung.
4. Das Dateisystem, nehmen wir mal UFS, legt er mit
newfs /dev/ada0p1.eli an.
Einfach
/dev/ada0p1.eli in die fstab einzutragen, ist keine gute Idee. Zwar sind Device Namen unter FreeBSD garantiert statisch, allerdings prinzipbedignt nur, solange das Mainboard sie bei jedem Start gleich enummeriert. Daher stellt die
glabel GEOM-Klasse eine Menge Label zur Verfügung. Unter anderem Partitionslabel, UUIDs und Dateisystemlabel. Hat der Nutzer im Beispiel der Partition das Label
example gegeben, legt glabel ein
/dev/gpt/example Pseudodevice an. Hat die Partition zudem die UUID
1234-5678 parallel dazu ein
/dev/gptid/1234-5678 Pseudodevice. Wenn man nach dem Matroskaprinzip arbeitet, sind mehrere Devices auf einer Ebene eine dumme Idee. Entweder kann der Nutzer die Devices unterschiedlich behandeln, also zum Beispiel
/dev/gpt/example verschlüsseln und
/dev/gptid/1234-5678 in einen Mirror einfügen. Das geht natürlich nicht. Oder man spielt alle höheren Klassen auf alle Devices zurück, legt also
/dev/gpt/example.eli und
/dev/gptid/1234-5678.eli an. Das wird sehr schnell sehr komplex. GEOM löst dies Problem, indem es auf jeder Ebene nur einen geben kann. In dem Moment, wo die Verschlüsselung auf
/dev/gptid/1234-5678 geöffnet wird, verschwindet
/dev/gpt/example.
Um beispielsweise deine Swap per UUID zu mounten musst du also erstmal die UUID rausfinden:
Code:
% glabel status
Name Status Components
gptid/1234-5678 N/A ada0p1
Und das kommt in Standard-Unix-Format in die fstab:
Code:
# Device Mountpoint Type Options Dump Pass
/dev/gptid/1234-5678 none swap sw 0 0
Testen kann man es mit:
