Die neue Datenpartition einbinden

Hauptkategorie: Computer und Spiele
Erstellt: 18 Januar 2016
Zugriffe: 869

So, bis hierhin war das ganze ja noch recht einfach. Nun kümmern wir uns um die neue Datenpartition.

Diese ist bis jetzt noch völlig blank. Außer einer Größe hat sie nichts. Insbesondere kein Dateisystem. Das war bei der Swap-Partition zwar auch so, aber da war es egal, denn ich hatte ja gesagt, dass der Kernel selbst am besten weiß, was er mit einem Swap-Device anzufangen hätte. Das ist bei einer Datenpartition ganz anders.

Aus Gründen der Einfachheit entscheide ich mich für das Standard-Dateisystem ext4. Das ist stabil und im Falle eines Stromausfalls oder anderen Absturzes hat es eine Log-Funktionalität, die die Daten wieder selbst restaurieren lässt. Mit

sudo mkfs.ext4 -i 65536 -m 2 /dev/mmcblk0p4

erstellen wir jetzt das Dateisystem.

Was heißen die beiden Parameter –i und –u? Für jede Datei wird bei Unix / Linux eine Struktur benötigt, in der steht, wem sie gehört, wie groß sie ist, wo sie auf der Partition liegt etc. Diese Struktur nennt man iNode (sprich Ei-nohd) und steht für Information – Node.

Den Standardwert für unsere Partition legt mkfs mit 8.192 iNodes an – das hieße, wir könnten nur 8K Dateien speichern. Das wird für die meisten Zwecke zu wenig sein.

Deshalb geben wir mit –i 65536 an, dass wir eine durchschnittliche Dateigröße von 64KB erwarten. Damit legt mkfs immerhin schon 442.368 iNodes an. Wenn Ihr nur Videos und andere große Dateien auf dem Filesystem speichern wollt, könnt Ihr das gerne anpassen.

Der zweite Parameter gibt an, wie viel Prozent der Partition ausschließlich für root reserviert werden, wenn der Platz eng wird. Da wir auf der Datenpartition (hoffentlich) keine wesentlichen System-Services laufen lassen werden, habe ich mal 2% reserviert (der Standardwert wäre 5%, wenn Ihr den Parameter einfach weglasst).

Das Ganze sieht dann so aus (und dauert ca. ½ Minute):
Partition 33

Aber bitte Achtung: Wenn Ihr den Befehl mkfs… eintippt oder kopiert, achtet bitte darauf, dass Ihr wirklich die richtige Partition (bei mir die mit der Nummer 4) erwischt, sonst initialisiert Ihr eine andere Partition und könnt von vorne anfangen . Das hat mich schon mal iRl ein paar Stunden gekostet…

Nun schauen wir uns noch mal die mount-Struktur an (jaja, haben wir schon, aber Wiederholung übt):
Partition 34

Jetzt hängen wir erst mal zum Testen die neue Partition in das Standard-Mount-Verzeichnis /mnt:

sudo mount /dev/mmcblk0p4 /mnt
Partition 35

Das sollte ohne Schwierigkeiten gelingen, denn Linux erkennt das ext4-Filesystem und wenn wir nichts anderes angeben, meint Linux, dass wir lesen und schreiben möchten:
Hier erkennt Ihr, weshalb man früher sagte, dass unix/Linux nicht besonders geschwätzig sei – offensichtlich hat das Mounten geklappt, denn es gab keine Fehlermeldung…

Schauen wir uns mount noch mal direkt an:

mount
Partition 37

Ei siehe da – eine neue Partition an der richtigen Stelle in der letzten Zeile!

Das wollen wir jetzt mal testen. Also ab nach /mnt und die üblichen Kommandos absetzen, die man nimmt, wenn einem nichts Besseres einfällt:

cd /mnt; ls –lsa; df –h .
Partition 38

Da gibt es ein Verzeichnis lost+found von gerade eben und das DiskFree sagt uns, dass hier immerhin schlappe 27 Gigabyte frei sind – Tschacka!

Das lost+found ist ein untrügliches Zeichen dafür, dass hier eine separate Partition beginnt. Wenn Euer System mal crasht und Ihr (z.B. beim Booten) eine Prüfung des Dateisystems einfordert, dann werden Dateien, die irgendwie in der Luft hängen, genau unter dieses Verzeichnis gepackt.

Schauen wir mal, ob wir auf der neuen Partition auch selbst was schreiben können. Dazu legen wir (als root) erst mal ein Verzeichnis an und schenken es dem User pi (einschließlich Gruppenzugehörigkeit):

sudo mkdir pitest
Partition 39

Funzt.

Also rein nach pitest (nicht mehr als root, denn dieses Verzeichnis gehört uns ja selbst!) und ein bisschen rumgeschrieben:

cd pitest; ls; echo ‚Das klappt ja hier vom feinsten!!!‘ > foo; ls –l; cat foo; ls –l; rm foo; ls –l; cd ..
Partition 40

Sieht vernünftig aus, was mein Ihr?

Jetzt beginnt die Arbeit.

Erst mal schmeißen wir pitest wieder weg,

cd /mnt
sudo rm –rf pitest

Partition 41

und tragen das neue Dateisystem in /etc/fstab ein, so wie wir es mit swap getan haben:

sudo nano /etc/fstab
Partition 42

Diese vierte Zeile ergänzen wir

/dev/mmcblk0p4 /var ext4 defaults,noatime 0 2

Das vierte Device

  • soll unter /var eingetragen werden (dazu kommen wir gleich)
  • ist Dateisystem ext4
  • Standardwerte, aber keine Uhrzeit-Aktivierung von iNodes
  • 0 = kein Dump
  • 2 = wenn ein Filesystemcheck gemacht wird, können /boot und /var parallel getestet werden

Dann können wir noch den kleinen Tippfehler bei der dritten Zeile korrigieren (ich hatte default geschrieben, nicht defaults).
Speichern und gut ist.
Partition 43

Aber noch nicht booten, die Zeit ist noch nicht reif!

Eingangs hatten wir uns vorgenommen, die Verzeichnisse /var, /tmp und /home auf die neue Partition zu legen. Aber da steht jeweils schon was drin! Also kopieren wir ein wenig herum.

Wir haben ja die neue Partition unter /mnt noch gemountet. Und da könnten wir jetzt einiges reinschreiben. Wir haben mit unserem raspi grundsätzlich ein „lebendes“ Mehrbenutzer-System. Was passiert, wenn wir die Inhalte der drei Verzeichnisse kopieren, während sie verändert werden?

Kurze Frage, kurze Antwort: Mist!

Also müssen wir Linux mitteilen, dass wir gerne alleine drauf rumturnen möchten. Dazu gibt es das init – Kommando. Init ist die Mutter aller Prozesse (sie hat auch die Nummer 1 und das immer!) und steuert mit sogenannten runlevels, was gerade auf dem System passieren darf und was nicht.

  • Der standard-Runlevel ist 2 (das habt Ihr sicherlich auch schon mal beim Booten gesehen) Dann gibt es noch 6 (reboot) und s für Single-User.
  • 0 (wird beim Booten genutzt)
  • Nummer 7 ist für den X11-Betrieb gedacht.
  • Und mit den Leveln 3, 4, 5, 6, 8, … könnt Ihr mehr oder weniger steuern, wer oder was auf Euren Rechner darf.
    Das ist beim Raspi aber nicht besonders ausgefeilt. Denkt aber mal an Kisten, die Tausende User verkraften müssen mit zig Daemons (Services unter Windingens).
  • Und dann gibt es noch den Runlevel 1, fast ohne jeglichen Dienst. Den nutzen wir jetzt.

sudo init 1

Wenn Ihr bis jetzt über ssh von einem anderen Terminal aus mit dem Raspi gearbeitet habt, geht es ab sofort nur noch über die Raspi-Konsole (also über den HDMI oder DVI-Anschluss). Darauf seht Ihr unten die Zeilen

INIT: Sending Processes the TERM signal
INIT: Sending Processes the KILL signal
 # 

Nun seid Ihr alleine auf der Kiste, auch alle Services sind derzeit gestoppt (macht mal „ps alxww“).

Die folgenden Kommandos führt Ihr einfach in der angegebenen Reihenfolge aus.

cd /mnt

Hier wollen wir alles reinkopieren

tar cvf - /home | tar xf -

Das muss man erklären

  • tar steht für Tape ARchiver.
  • tar cvf – erzeugt (c) ein Archiv, gibt die enthaltenen Namen aus (v) und schreibt alles nach stdout (f -)
  • Das schreiben wir in eine Pipe.
  • Am anderen Ende der Pipe sitzt wieder ein tar, aber das soll das Gelesene extrahieren (x) und zwar von stdin (f -)

Warum kein copy per cp? Weil sich tar um alles kümmert: Neue Verzeichnisse, Berechtigungen, Spezialdateien usw.

(cd /var; tar cvf - *) | tar xf -

Hier fast das gleiche wie eben. Aber in der Klammer steht noch ein „cd“. Das brauchen wir, weil wir nicht /var kopieren wollen, sondern nur den Inhalt von /var.
Das dauert auch schon etwas länger, als die Geschichte mit dem Home-Verzeichnis oben. Sind ja auch 108 MB

ls -l

Am besten schaut Ihr Euch jetzt das Ergebnis mal an.

Neben den Dateien, die aus /var kopiert wurden, findet Ihr ein Verzeichnis /home mit (mindestens) dem User pi:
Partition 44

cd /

Jetzt ab nach oben…

mv home orig-home

… um die die alten Verzeichnisse umzubenennen.

mv var orig-var

Ob Ihr /var auch verschiebt oder belasst, ist Eure Entscheidung. Wenn mal ein Fehler mit der neuen Partition passieren sollte, hättet Ihr zumindest ein „veraltetes“ /var, wenn Ihr es einfach da stehen lasst, wo es ist. Aber dann belegt es dauerhaft Platz auf der root-Partition (ca. 108 MB).

Ich meine: Lieber kein /var, als ein veraltetes.

rm –rf tmp

tmp können wir gleich löschen

mkdir /var
chmod 755 /var

Wenn wir später booten, ist die neue Partition zunächst noch nicht gemountet. Trotzdem wird Linux versuchen, /tmp zu leeren. Damit wir dazu keine Fehler bzw. Warnungen bekommen, legen wir einfach ein leeres /var/tmp an

mkdir /var/tmp
chmod 777 /var/tmp

   

ln -s /var/tmp /tmp

Nun legen wir als letztes die beiden symbolischen Links für /tmp und /home an. Diese sollen zukünftig auf die neue Partition zeigen

ln -s /var/home /home

reboot

Fertig !

Nach dem Booten sollten die wesentlichen Informationen zu Partitionen und Verzeichnissen folgendermaßen aussehen:

mount
Partition 45

Passt, unterste Zeile ist OK, die Partition ist auf /var gemountet.

ls –l /
Partition 47

Passt auch, die hellblauen symbolischen Links zeigen jeweils auf das Verzeichnis, wie es geplant war. Sollte einer der Links rot sein, stimmt was nicht…

cd /tmp; ls –l
Partition 48

Passt auch. Nur eine Datei in /tmp, das geht ja noch…

cd
pwd
ls –lsa

Partition 49

Passt auch. Mit cd ins Home-Verzeichnis und mit pwd nachsehen, wo wir sind. Die Inhalte stimmen auch, das erkenne ich an der Datei c.c, die ist nicht Standard im Rasperry