Übersicht für diesen Eintrag
Anmerkung: Ist ja wieder einige Zeit vergangen seit dem letzten Eintrag. Eigentlich wollte ich gar nicht so lange warten, aber einige Dinge haben mich dann doch wieder von einem konsequenten Arbeiten und Schreiben hieran abgehalten. Dazu gehört auch, dass insbesondere die zweite Variante zur Erstellung einer "benutzerdefinierten" Live-Umgebung mehr Zeit braucht, als ich zunächst vermutet hatte. Dementsprechend habe ich mich (wieder mal) zum Auftrennen entschieden (alles zusammen würde wohl locker 6000 Wörter bedeuten). Jedenfalls gehe ich in diesem Eintrag damit hauptsächlich auf meine Gedanken hinter der Nutzung von Parrot OS für die Backups meiner Hostsysteme ein. Außerdem zeige ich einen (relativ einfachen) Weg, eine an die eigenen Bedürfnisse angepasste Live-Umgebung zu erhalten. Im komenden Eintrag kommt dann die (deutlich) komplexere Variante, die allerdings eben auch wieder deutlich mehr Möglichkeiten bietet.
Warum gerade ParrotOS?
Vorbemerkungen unabhängig der gewählten Verfahrensweise
Variante 1: USB-Laufwerk mit Persistenz
Fußnoten
Warum gerade ParrotOS?
Der ein oder andere wird sich an dieser Stelle wohl etwas wundern - für Backups gibt es naheliegendere Lösungen. Allen voran sei hier
Clonezilla genannt. Allerdings gibt es da ein Problem, dass es für mich persönlich unbenutzbar macht.
Zwar ist es möglich, mit Clonezilla für LVM genutzte Partitionen zu sichern (und wiederherzustellen). Dabei gilt allerdings: Beim Start des Backup-Vorgangs wird der LVM-Dienst beendet. Dies führt zunächst dazu, dass keinerlei LVM-Einheiten (Physische Volumes, Volume Groups oder einzelne Logische Volumes) mehr angesprochen können. Ein gezieltes Backup nur des Volumes für
/var/log ist so etwa nicht möglich. Weiterhin hat dies unnötig große Backups zur Folge. Clonezilla sichert zwar grundsätzlich nur belegten Platz, von "außen" (auf dem Level der physischen Partition) kann das aber nicht effektiv beurteilt werden. Siehe dazu auch
dieser Bug-Report (am Ende wohl eher ein Feature Request, aber gut).
Dazu kommt allerdings noch eine weitere Sache: Üblicherweise werden Backups bei Änderungen am System gemacht - ob das nun größere Updates oder Konfigurationsänderungen sind. Diese will ich (in erster Linie für mich) prüfen, freigeben und dokumentieren. Für eine entsprechende Nachvollziehbarkeit und eine (zumindest halbwegs) komfortable Durchführung werden allerdings entweder Tools benötigt, die nicht in den üblichen Backup-Livesystemen vorhanden sind oder direkt professionelle Server-Systeme. Zweiteres steht für mich wie schonmal beschrieben in vorhersehbarer Zeit nicht zur Debatte. Zentral ist für mich jedenfalls, die Backups der Hostsysteme aus einer Live-Umgebung heraus auszuführen und nicht etwa vom Host selbst (wie etwa mit Timeshift, Testumgebungen werde ich hier, wie schonmal angedeutet, aber etwas anders behandeln).
Dennoch gibt es eine zentrale Funktion, die ich von Clonezilla mitnehme:
partclone. Dieses (Command-Line)Tool kann nämlich sehr wohl dafür genutzt werden, logische Volumes zu sichern. Sie müssen eben entsprechend vefügbar (aktiviert) sein. In der Vergangenheit hatte ich dabei
Tails in Verbindung mit dessen
persistenten Speicher (nur englisch) verwendet. Die Nutzung der Persistenz mit Tails wird mit der Zeit aber dann doch recht unkomfortabel (für
meine Art der Nutzung!). Zudem musste ich nach einiger Zeit feststellen, dass doch relativ viele Tools, die ich dafür benötige, fehlen. Da wären z.B.:
- Partclone: Offensichtlich, wie oben beschrieben zum Ziehen der Backups (alleine erstmal nur Kommandozeile).
- Git und Git-Cola: Für die Dokumentation meiner Änderungen sowie Logs (Repos separiert nach Bedarf).
- Meld: Zum Vergleichen, insbesondere bei ganzen Ordnerstrukturen1.
Natürlich könnte man diese Tools innerhalb des persistenten Speichers ablegen, die dann bei jedem Start (sofern gewünscht) zur weiteren Nutzung temporär installiert werden. Jedenfalls bewog mich das dann doch dazu, nach alternativen Möglichkeiten zu suchen.
Nachdem ich angefangen hatte, an diesem Tagebuch zu schreiben, bin ich dann relativ bald auf
ParrotOS gestoßen.
Nach einigen Tests war mir relativ schnell klar, dass dies mein neues System für Backups der Hostsysteme und damit in Verbindung stehende Tätigkeiten wird, aus den folgenden Gründen:
- Es ist Debian-basiert (allerdings Testing, also aktuellere Pakete), damit kenne ich mich zumindest halbwegs gut aus.
- Auf der Website ist ein offizielles Image mit dem KDE-Desktop verfügbar, was aufgrund meiner sonstigen Installationen definitiv willkommen ist.
- Der eigentliche Hauptgrund: Es ist verhältnismäßig einfach, ein aktualisiertes, angepasstes Image zu erstellen, ohne auf Persistenz zurückgreifen zu müssen. In der Tat wäre ich sonst vermutlich hierfür bei Tails geblieben. Es gibt selbstverständlich aber auch andere Distributionen, die angepasste Images einfach ermöglichen. Meines Wissens nach ist dies für Tails z.B. aber nicht (offiziell) unterstützt - siehe Website dazu (englisch).
Ein paar Worte zu Home vs. Security
An dieser Stelle ist es wohl angebracht, auf die verschiedenen zum
Download angebotenen ISO-Versionen einzugehen, dabei lege ich den Fokus auf Home und Security. Die anderen Images (verschiedene Desktops, Virtualisierungen oder Netinst-Images) sind hier unerheblich. Jedenfalls sollte man bedenken, dass Pentesting-Umgebungen üblicherweise nicht zur regulären (täglichen) Nutzung gedacht sind.
Dies gilt prinzipiell unabhängig von der Distribution - Parrot OS (in der Security-Variante), Kali, Black Arch und wie sie alle heißen. Warum sich ein solches System zwar sehr gut zur Schwachstellenanalyse eignet, aber kaum als "Daily Driver", lässt sich auch recht schnell nachvollziehen:
- Die Nutzung einer solchen Distribution bringt keinen wirklichen Vorteil gegenüber einer "regulären". Es fehlen gewisse Programme? Gut, dazu gibts ja Repositories (bzw. AUR für Arch und Derivate), die gerade bei den "üblichen Verdächtigen" fast immer irgendwas hergeben. Wenn's hier jedenfalls nicht verfügbar ist, wird die Nutzung einer Pentesting-Distribution vermutlich auch nichts daran ändern. Das allein wäre eigentlich schon Begründung genug, aber schauen wir doch nochmal genauer (und etwas spezieller für Parrot Os)...
- Die meisten Distributionen, die sich auf Pentesting spezialisieren, sind alles andere als schlank. Dies gilt sowohl für die hardwareseitigen Anforderungen als auch die installierten Pakete. Dazu im Folgenden zunächst die in der KDE-Home-ISO von Parrot OS Anzahl an gelisteten Paketen (Release 4.9.1)
Im Vergleich dazu KDE-Security von Parrot OS
Anmerkung: Obiger Befehl gibt mit dpkg alle installierten Pakete aus und "zählt" die ausgegebenen Zeilen dann. Genau genommen muss man für das "richtige" Ergebnis noch 6 abziehen (Kopfzeilen von dpkg -l), auf die Vergleichbarkeit hat das allerdings bei den Zahlen kaum Auswirkungen.
- Nun ist bereits die "Home"-Variante alles andere als schlank und hat etwa schon mehr Pakete als ein standardmäßiges Ubuntu. Ob man OOTB etwa mehrere Mediaplayer braucht, ist sicher Ansichtssache. Beim Security-Image sind das jedenfalls nochmal gut 60% an Paketen oben drauf. Für die Differenz kann man schon fast ein separate Distribution mit (schlanker) Desktopumgebung installieren.
- Selbst in der Home-Variante sind bereits bestimmte Dinge vorhanden, die sich nicht wirklich an den Einstiegsnutzer richten. Als Beispiel sei hier nur der Tor-Browser genannt. Sicher kann die Nutzung vorteilhaft sein. Wer sich aber bestimmten Sachen nicht bewusst ist, bekommt hier unter Umständen ein Gefühl von Sicherheit, das gar nicht vorhanden ist2.
- Vergleicht man nun die in Security zusätzlich installierten Pakete, wird man feststellen, dass fast nichts davon für die tägliche Nutzung gedacht ist. Anders gesagt - mit "Security" im Sinne eines sicheren Systems hat das eigentlich kaum etwas zu tun.
- Im Gegenteil - durch die zusätzlich installierten Pakete kann man sich sogar zusätzliche Sicherheitslücken ins System holen, die sonst gar nicht vorhanden wären. Die Gefahr dazu verstärkt sich natürlich, wenn einem gar nicht bewusst sein sollte, was man da eigentlich installiert hat bzw. wie die angedachte Handhabung ist3.
- Dazu kommt weiterhin, dass man bei der Anwendung vieler Tools im Security-Image schnell mal in einen Bereich der strafbaren Handlung kommen kann.
An dieser Stelle komme ich dann doch zum ersten Teil, den man durchaus als "Guide" bezeichnen könnte. Nachdem es mir nicht ohne weiteres möglich war, entsprechend detaillierte Guides (erst recht in Deutsch) für ParrotOS zu finden, dachte ich mir, kann es nicht schaden, das mal festzuhalten. Dabei werde ich zwei verschiedene Varianten vorstellen, die sich je nach gewünschter Anwendung recht stark in Aufwand und Anpassbarkeit unterscheiden.
Anmerkung: Es ist hier wichtig darauf hinzuweisen - es wird hier von unverschlüsselten Partitionen ausgegangen. Die reine Definition zusätzlich zu nutzender Pakete benötigt nicht wirklich eine verschlüsselte Persistenz. Für kritische Daten mag dies natürlich sinnvoll sein. Dann würde ich persönlich aber ohnehin nach Nutzungszweck separierte VeraCrypt-Container (oder eben LUKS
4) empfehlen, auf die je nach Bedarf zugegriffen werden kann. Sollte es dennoch gewünscht sein, eine verschlüsselte Partition als Persistenz zu nutzen, werde ich im Rahmen der zweiten Variante (folgender Eintrag) wohl noch einen Blick darauf werfen.
Im Rahmen der Persistenz gehe ich an dieser Stelle kurz einmal auf die (Meta)Pakete ein, die ich in beiden Varianten zusätzlich installieren werde.
Partclone
Es wurde ja bereits angesprochen, dass ich meine Hostsystem-Backups damit durchführe. Die Gründe dafür sind recht einfach - es hat mich bisher noch nie im Stich gelassen, wenn es denn benötigt wurde (also gerade wenn es ums Zurückspielen geht). Zudem ist die Anwendung an sich auch gar nicht so kompliziert, wenn das Prinzip der verschiedenen "Unterprogramme" einmal verinnerlicht ist.
Keepassxc
Ein Passwortmanager ist meiner Ansicht nach ein MUSS für absolut jeden. Es gibt hier verschiedenste Möglichkeiten, meiner Meinung nach kommt für so etwas aber nur ein "Offline"-Konzept in Frage (was die Datenbank-Ablage in der Cloud nicht notwendigerweise ausschließt). Keepassxc hier ist plattformunabhängig und wird aktiv weiterentwickelt. Für weitergehende Infos kann ich nur den (hervorragenden)
Guide von OldKnitterhemd hier im Forum empfehlen.
Eric
Skripte können natürlich für die unterschiedlichsten Aufgaben verwendet werden. Bash hat zwar den großen Vorteil, universell einsetzbar zu sein. Allerdings eignet es sich nur schlecht für komplexere Aufgaben. Für diese Fälle greife ich dann auf "ernsthaftere" Alternativen zurück. Ich persönlich nutze hin und wieder mal Python. Dabei ist
eric eben eine entsprechend spezialisierte Entwicklungsumgebung hierfür.
Parrot-devel
Dieses ist etwas spezieller, da es sich hierbei um ein Metapackage handelt. Dies bedeutet, dass es sich dabei eigentlich vielmehr um eine ganze Liste an Paketen handelt, die installiert werden sollen (nicht zu verwechseln mit Abhängigkeiten). Das Ziel meiner persönlichen Live-Umgebung soll nämlich sein, dass ich auch die Schritte zur Dokumentation bzw. Versionierung von Änderungen an meinen Systemen in der gleichen Umgebung wie meine Backups vornehmen kann. Dazu werden hier unter anderen GIT (Versionsverwaltung), GIT-Cola (ein etwas komfortableres GUI für Git) und Meld (Datei- und Ordnervergleich) installiert.
Anmerkung: Es wird bei beiden Varianten davon ausgegangen, dass die gewünschte ISO bereits heruntergeladen und verifiziert ist. Das Prinzip hatte ich bereits in
Eintrag 7 beschrieben.
Variante 1: USB-Laufwerk mit Persistenz
Diese Variante wird in der Tat für die meisten die passende sein. Der Aufwand hält sich verglichen mit der Erstellung eines "regulären" Live-USBs wirklich in Grenzen. Weiterführende Kenntnisse werden nicht wirklich benötigt. Allerdings gibt es hier (bei weitem) nicht so viele und tiefgreifende Individualisierungsmöglichkeiten. Zudem sind die Pakete unter Umständen nicht ganz aktuell, da man grundsätzlich an das ISO gebunden ist
5. Wir starten hier jedenfalls ohne angestecktes Ziellaufwerk und prüfen die verfügbaren Block-Devices.
Code:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
...
sda 8:0 0 238,5G 0 disk
├─sda1 8:1 0 238,4M 0 part /boot/efi
├─sda2 8:2 0 3,5G 0 part
└─sda3 8:3 0 234,7G 0 part /run/timeshift/backup
nvme0n1 259:0 0 1,8T 0 disk
├─nvme0n1p1 259:1 0 2,8G 0 part
├─nvme0n1p2 259:2 0 279,4G 0 part
└─nvme0n1p3 259:3 0 9,3G 0 part
└─vg00_boot-boot_testenv
253:0 0 1,9G 0 lvm
nvme1n1 259:4 0 1,8T 0 disk
Man beachte, dass die Ausgabe etwas gekürzt ist. Wer häufiger mitliest, wird bemerken, dass es sich hierbei weder um ein Live-System noch um etwas auf meinen NVME-Laufwerken handelt. Stattdessen läuft hier Dells Ubuntu-Installation auf der Original-SSD in einem externen Gehäuse. Jedenfalls sollte man nun das Ziellaufwerk verbinden und die Änderung an den Block-Devices beobachten (Ausgabe auf interessanten Bereich beschränkt).
Code:
$ lsblk
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
...
sda 8:0 0 238,5G 0 disk
├─sda1 8:1 0 238,4M 0 part /boot/efi
├─sda2 8:2 0 3,5G 0 part
└─sda3 8:3 0 234,7G 0 part /run/timeshift/backup
sdb 8:16 1 115,5G 0 disk
nvme0n1 259:0 0 1,8T 0 disk
...
Wir wissen nun also, dass
sdb unser Ziellaufwerk ist. Somit können wir im Folgenden dieses mit unserem ISO beschreiben.
WICHTIG: Es wäre an dieser Stelle sehr sinnvoll, die Ausgabe gewissenhaft zu prüfen. Der Inhalt des Ziellaufwerks wird im nächsten Schritt nämlich überschrieben, eventuell zuvor vorhandenes ist dann (mit mehr oder minder hoher Wahrscheinlichkeit) nicht mehr zu retten!
Code:
$ sudo dd if=Downloads/Parrot-kde-home-4.9.1_x64.iso of=/dev/sdb bs=1M && sync
2098+1 Datensätze ein
2098+1 Datensätze aus
2200514560 Bytes (2,2 GB, 2,0 GiB) kopiert, 5,42765 s, 405 MB/s
An dieser Stelle haben wir nun bereits einen grundsätzlich bootfähigen USB-Stick. Wie kriegt man nun die Persistenz hin? Nun, wir öffnen dafür zunächst einmal eine
fdisk-Session für unser Ziellaufwerk
6.
Code:
$
sudo fdisk /dev/sdb
Willkommen bei fdisk (util-linux 2.31.1).
Änderungen werden vorerst nur im Speicher vorgenommen, bis Sie sich
entscheiden, sie zu schreiben.
Seien Sie vorsichtig, bevor Sie den Schreibbefehl anwenden.
Befehl (m für Hilfe):
Hier sollte zunächst einmal das aktuelle Partitionslayout des geladenen Datenträgers geprüft werden.
Code:
Befehl (m für Hilfe): p
Festplatte /dev/sdb: 118 GiB, 126701535232 Bytes, 247463936 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0x8af7818e
Gerät Boot Anfang Ende Sektoren Größe Kn Typ
/dev/sdb1 * 64 4295807 4295744 2G 17 Verst. HPFS/NTFS
/dev/sdb2 4295808 4297279 1472 736K 1 FAT12
Die obige ausgabe sollte dringend auf Plausibilität geprüft werden. Stellt man hier Unregelmäßigkeiten fest (wie etwa unerwartet viele Partitionen), sollte man sicher stellen, dass nicht versehentlich der falsche Datenträger zur Bearbeitung geöffnet ist
7! Ist dies also erledigt, können wir eine neue Partition für die Persistenz erstellen.
Die folgenden Abfragen nach Partitionsnummer und -größe sollten individuell nach Anforderung definiert werden. Man kann hier auch mit
ENTER einfach die Standardwerte übernehmen. Für die Größe wird dann der verbleibende freie Platz auf dem Laufwerk angenommen. Insgesamt sollte die Ausgabe ähnlich der folgenden aussehen:
Code:
Befehl (m für Hilfe): n
Partitionstyp
p Primär (2 primär, 0 erweitert, 2 frei)
e Erweitert (Container für logische Partitionen)
Wählen (Vorgabe p):
Standardantwort p wird verwendet.
Partitionsnummer (3,4, Vorgabe 3):
Erster Sektor (4297280-247463935, Vorgabe 4298752):
Letzter Sektor, +Sektoren oder +Größe{K,M,G,T,P} (4298752-247463935, Vorgabe 247463935):
Eine neue Partition 3 des Typs „Linux“ und der Größe 116 GiB wurde erstellt.
Nach der vorgenommenen Definition sollte zunächst einmal noch das neue Partitionslayout geprüft werden (Ausgabe gekürzt).
Code:
Befehl (m für Hilfe): p
...
Gerät Boot Anfang Ende Sektoren Größe Kn Typ
/dev/sdb1 * 64 4295807 4295744 2G 17 Verst. HPFS/NTFS
/dev/sdb2 4295808 4297279 1472 736K 1 FAT12
/dev/sdb3 4298752 247463935 243165184 116G 83 Linux
Bis zu diesem Zeitpunkt sind die Änderungen am Partitionslayout noch gar nicht auf das Laufwerk geschrieben
8. Das holen wir nun nach.
Code:
Befehl (m für Hilfe): w
Die Partitionstabelle wurde verändert.
Festplatten werden synchronisiert.
An diesem Punkt wird die
fdisk-Sitzung beendet und man wechselt zurück ins reguläre Terminal. Die Partition ist erstellt, allerdings muss zur eigentlichen Verwendung noch ein entsprechendes Dateisystem erstellt werden.
Code:
$ sudo suomkfs.ext4 /dev/sdb3
mke2fs 1.44.1 (24-Mar-2018)
Ein Dateisystem mit 30395648 (4k) Blöcken und 7602176 Inodes wird erzeugt.
UUID des Dateisystems: 33be69df-17e3-473b-acee-3a36ff4f046a
Superblock-Sicherungskopien gespeichert in den Blöcken:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872
beim Anfordern von Speicher für die Gruppentabellen: erledigt
Inode-Tabellen werden geschrieben: erledigt
Das Journal (131072 Blöcke) wird angelegt: fertig
Die Superblöcke und die Informationen über die Dateisystemnutzung werden
geschrieben: erledigt
Um die Partition nun als persistent zu konfigurieren, muss darauf noch eine kleine Konfigurationsdatei erstellt werden. Dazu mounten wir die Persistenz-Partition zunächst
9.
Code:
$sudo mkdir /mnt/parrot_usb && sudo mount /dev/sdb3 /mnt/parrot_usb
Erstellt nun eine Textdatei
persistence.conf im Wurzelverzeichnis der Persistenzpartition.
$sudo nano /mnt/parrot_usb/persistence.conf
Der Inhalt ist nur folgende Zeile.
Nach dem Schrägstrich
muss ein Leerzeichen kommen, sonst funktioniert das nicht! Am Anfang wird hier vielmehr mit
/ auf das Wurzelverzeichnis der Live-Umgebung Bezug genommen. Dann folgt mit
union die Definition, dass Änderungen an der Umgebung auf der Persistenz-Partition gespeichert werden sollen
10. Jedenfalls kann
nano dann mit
STRG+X (Verlassen),
Y (Bestätigen der Änderung),
ENTER die Datei wieder gespeichert und geschlossen werden.
Nun ist es an der Zeit, das System mit dem vorbereiteten USB-Stick neu zu starten. Also auf das Einmalbootmenu eures Systems zugreifen und vom USB booten. Im Bootmenu von Parrot OS muss nun "Persistence" gewählt werden.
Nach kurzer Zeit solltet ihr den Desktop von Parrot OS dann vor euch sehen. Bevor wir Pakete installieren, ist anzuraten, die Paketlisten zu aktualisieren.
Anschließend sollten die gewünschten Pakete installiert werden können.
Code:
$sudo apt install partclone keepassxc eric
Nach abgeschlossener Installation solltet ihr zur Funktionskontrolle das System neu starten und ebenso wieder den Modus "Persistence" anwählen. Dann sollten wie zu erwarten auch die soeben installierten Anwendungen zur Verfügung stehen.
- Man merkt es an dieser Stelle dann ja wohl doch: Ich bin keineswegs nur aufs Terminal fixiert. Ich versuche individuell das zu nutzen, mit dem ich im konkreten Fall komfortabel arbeiten kann. Wenn ich dafür zusätzliche Software installieren muss, ist das eben eine Abwägungssache. Aus Effizienzsicht ist das Terminal bei richtiger Anwendung aber wohl kaum zu schlagen.
- Für weitergehende Informationen empfehle ich an dieser Stelle zum Beispiel die offizielle Tails-Doku und dort insbesondere den Abschnitt zu kompromittierten Exit-Nodes.
- Ich werde dazu im nächsten Eintrag noch einmal einen genaueren Blick auf die unterschiedliche Ausführung von Home und Security im Rahmen meines eigenen ISO-Images legen, dort gibt es nämlich bei den sogenannten "Hooks" einige Abweichungen, die aufzeigen, was eigentlich bei Security alles für Services manuell deaktiviert werden.
- Es mag vielleicht etwas verwundern, aber LUKS kann sehr wohl für verschlüsselte Container genutzt werden. Für mehr Infos, siehe z.B. das offizielle Wiki von Ubuntu dazu.
- Auch wenn das Updaten eines USB-Live-Systems grundsätzlich möglich ist, würde ich dies üblicherweise nicht empfehlen. Typischerweise sind USB-Sticks nämlich mit den dann häufig notwendigen (kleinen) Schreibzugriffen auf die Persistenz nämlich hoffnungslos überfordert. USB-Sticks mit SSD-basierter Technik mögen hierfür besser geeignet sein. Jedenfalls ist das im konkreten Fall mit Parrot OS verglichen etwa mit Debian ein nicht so großes Problem, da Images hier deutlich häufiger herausgegeben werden.
- Es mag hier der Einwand kommen, warum hierfür nicht GUI-Tools wie Gnome's gparted oder ähnliches genutzt wird. Und das ist im Grunde auch erst einmal sehr gut. Solche Tools haben nämlich sehr oft Sicherheitsvorkehrungen, um das versehentliche Überschreiben eines falschen Laufwerks zu verhindern. Allerdings wird man wohl inzwischen gemerkt haben, dass es mir nicht darum geht. Ich will das zugrunde liegende Prinzip verstehen, bevor ich zur Nutzung von Software übergehe, die darunter liegende Sachen abstrahiert. Im Falle von Problemen ist dann nämlich oft schon bekannt, was schief läuft.
- An dieser Stelle sei angemerkt, dass
fdisk etwas speziell ist, da ihr während einer Session in einer Art "abgeschotteten" Umgebung arbeitet. Es gibt hier eine Reihe von festgelegten befehlen, die je nach ausgeführter Aktion zusätzliche Parameter vom Benutzer abfragen. Aus dieser Session heraus gibt es dann allerdings keinen Zugriff auf "reguläre" Terminalbefehle (ls, lsblk usw.), bis fdisk beendet wird..
- Die meisten Partitionstools (ob Kommandozeile oder grafisch) funktionieren nach diesem Prinzip. Zunächst wird gemäß der Anforderungen ein Partitionslayout definiert. Erst wenn dass Layout finalisiert ist, werden die Änderungen auf das Laufwerk geschrieben.
- Das Erstellen eines Ordners zum Einhängen der Persistenz-Partition wäre technisch gesehen nicht unbedingt notwendig. Ich würde aber dennoch empfehlen, sich das anzugewöhnen, da es Problemen vorbeugt, wenn man mehr als eine Partition temporär einhängen will. Ohne Nutzung spezieller Konzepte ist es nämlich nicht ohne weiteres möglich, zwei Partitionen gleichzeitig im selben Pfad zu mounten (LVM ist eins davon).
- Dieses Verhalten könnte man durchaus weiter anhand unterschiedlicher Pfade separieren und verschiedene Optionen nutzen. Ubuntu's Manpage hierzu (Englisch) ist tatsächlich mal eine gute Anlaufstelle für weitere Infos.
