Linux-Crypto-Dateisystem – völlige Verwirrung
Candid Dauth
- software
Heißa, alle,
langsam verzweifle ich völlig mit dem komischen Konzept des Verschlüsselns von Partitionen unter Linux. Vorweg: ich benutze Gentoo Linux, aber das dürfte eigentlich nichts zur Sache tun.
Also, was ich eigentlich will: Eine Partition mit meinem normalen achtstelligen Passwort verschlüsseln, die ich ganz einfach mounten kann, ganz normal mit -o encryption=blabla, egal an welchem Rechner meine Platte hängt.
Was mir stattdessen passiert:
Vor etwa einem halben Jahr habe ich mal eine Partition auf meiner Festplatte verschlüsselt, unter welcher Linuxdistribution ich das gemacht habe, weiß ich nicht mehr, und ob mein Linux mittlerweile neu installiert wurde, habe ich auch keine Ahnung. Ich verwandte damals den twofish-Algorithmus und verschlüsselte meine Partition gemäß einer Anleitung, an die ich mich nicht mehr erinnern kann. Ich kann mich aber erinnern, dass ich die Partition ganz normal mounten konnte, wie oben beschrieben.
Gestern ist mir eingefallen, dass Daten, die ich vermisse, auf dieser Partition herumliegen könnten. Also versuchte ich, die Partition wie bisher zu mounten, jedoch heißt es nun, nachdem ich das Passwort eingegeben habe:
Error: Password must be at least 20 characters.
So, darauf kann ich schonmal nicht zugreifen.
Dann passiert mir das:
Ich habe eine neue externe USB-Festplatte und wollte diese sogleich in Betrieb nehmen, also erstellte ich darauf gemäß einer Anleitung zwei Partitionen, beide so verschlüsselt, wie es in der Anleitung steht (aes-256). Das Mounten hat ganz normal funktioniert, mit -o encryption=aes-256, da ich ein Passwort mit 20 Stellen gewählt hatte, gab das auch keine Probleme. Also habe ich meine Daten draufgezogen, nachdem ich festgestellt hatte, dass die Partitionen auch nach dem Neustart und nach dem Umounten normal funktionierten.
Gerade eben umounte ich die beiden Partitionen wieder, und muss mit Entsetzen feststellen, dass ich sie nicht wieder erneut mounten kann.
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
Jetzt ist das reinste Chaos entstanden. Die erste Partition kann ich auf einmal doch wieder mounten, aber nur, wenn ich dies über -o encryption=aes-256 mache, das loop-Device kann ich nicht direkt einhängen, da erhalte ich wieder obige Fehlermeldung mit dem superblock.
Bei der zweiten Partition ist es genau andersherum, wenn ich sie versuche, direkt zu mounten, kommt obige Fehlermeldung, mal mit loop0, mal mit loop2. In Wirklichkeit ist es aber loop1, und wenn ich das einhänge, kann ich auch auf die zweite Partition zugreifen. Allerdings brauche ich kein Passwort einzugeben, wenn ich loop1 einhänge, und das kann es ja wohl auch nicht sein.
Ich verstehe irgendwie nicht, was da jetzt eigentlich passiert. Kann mir jemand das ganze Konzept genauer erläutern, oder mir einen Link auf eine anständige Anleitung schicken?
Gautera!
Grüße aus Biberach Riss,
Candid Dauth
Hallo Candid,
langsam verzweifle ich völlig mit dem komischen Konzept des Verschlüsselns von Partitionen unter Linux. Vorweg: ich benutze Gentoo Linux, aber das dürfte eigentlich nichts zur Sache tun.
Das erinnert mich doch an etwas - ja, ich bin in den letzten Monaten auch oft genau deswegen ausgerastet, mit so einer komischen Fehlermeldung (die ich gestern aber endlich unter Kubuntu beheben konnte).
Also, was ich eigentlich will: Eine Partition mit meinem normalen achtstelligen Passwort verschlüsseln, die ich ganz einfach mounten kann, ganz normal mit -o encryption=blabla, egal an welchem Rechner meine Platte hängt.
Da wirst du schon mal Probleme bekommen, die Programme verlangen heute mindestens 20 Zeichen.
Was mir stattdessen passiert:
Vor etwa einem halben Jahr habe ich mal eine Partition auf meiner Festplatte verschlüsselt, unter welcher Linuxdistribution ich das gemacht habe, weiß ich nicht mehr, und ob mein Linux mittlerweile neu installiert wurde, habe ich auch keine Ahnung. Ich verwandte damals den twofish-Algorithmus und verschlüsselte meine Partition gemäß einer Anleitung, an die ich mich nicht mehr erinnern kann. Ich kann mich aber erinnern, dass ich die Partition ganz normal mounten konnte, wie oben beschrieben.
Wenn du SUSE verwendet hattest, könntest du dich eventuell noch an diese Anleitung erinnern. Das Problem bei SUSE: Sie verwenden einen eigenen Twofish-Algorithmus. Die beste Lösung, um an eine solche Partition ranzukommen, ist es, eine Live-CD/DVD von SUSE selbst zu verwenden, dort mit modprobe die entsprechenden Module (s.u.) zu laden, die Partition zu mounten und die Daten woanders unverschlüsselt zu sichern.
Gestern ist mir eingefallen, dass Daten, die ich vermisse, auf dieser Partition herumliegen könnten. Also versuchte ich, die Partition wie bisher zu mounten, jedoch heißt es nun, nachdem ich das Passwort eingegeben habe:
<code>Error: Password must be at least 20 characters.</code>
So, darauf kann ich schonmal nicht zugreifen.
Wie gesagt: Wenn es eine SUSE war, könntest du mit einer alten Live-CD Erfolg haben.
[...]
Jetzt ist das reinste Chaos entstanden. [...]
Ich verstehe irgendwie nicht, was da jetzt eigentlich passiert. Kann mir jemand das ganze Konzept genauer erläutern, oder mir einen Link auf eine anständige Anleitung schicken?
So, dann will ich mal an dieser Stelle eine gute Anleitung schreiben, die dir eventuell weiterhelfen kann. Da ich selbst schon viele Probleme mit losetup und dem Kryptofilesystem unter Linux hatte, umso ausführlicher.
1. Das Prinzip:
Es wird eine beliebige Datei oder Partition ausgesucht, die als Träger der verschlüsselten Information dient. Da die bisherigen Daten in dieser Datei oder Partition verloren gehen, ist es sinnvoll, eine neue Datei anzulegen (z.B. mit "dd if=/dev/urandom of=datei bs=1024 count=5120" für eine 5 MB große Datei) bzw. eine leere Partition zu verwenden.
Mit dem Programm "losetup" wird dann ein loopback-Gerät für diesen Träger eingerichtet. Das loopback-Gerät dient also zum Ver- und Entschlüsseln der Daten. Schematisch dargestellt:
+-------------------------------+ +-----------------+ +-------------+
| Träger (Datei oder Partition) | --> | Loopback-Device | --> | Mount-Punkt |
+-------------------------------+ +-----------------+ +-------------+
Als Beispiel:
+-----------+ +------------+ +-----------+
| /dev/hdb1 | --> | /dev/loop0 | --> | /mnt/hdb1 |
+-----------+ +------------+ +-----------+
Das kann sich natürlich je nach Fall unterscheiden, bei mir unter Kubuntu habe ich z.B. kein /dev/loop0, dafür aber ein /dev/loop/0.
Gewissermaßen kann man sich das Loopback-Gerät also als eine Partition vorstellen, die unverschlüsselten Daten enthält. Man greift genauso darauf zu als würde man eine unverschlüsselte Partition mounten.
2. Die Voraussetzungen
Dieser Punkt hat mich am meisten ausrasten lassen. Man benötigt auf jeden Fall einen gepatchten Kernel (mit den für verschlüsseltes losetup getrimmten util-linux). Dieser ist ziemlich oft schon vorhanden, wie z.B. bei Gentoo (gentoo-sources), (K)Ubuntu und SUSE.
Als nächstes braucht man die beiden Kernel-Module "aes" (für AES-Verschlüsselung, für andere Verschlüsselungen braucht man andere Module) und "cryptoloop". Ohne die beiden ging es bei mir nie. Weiterhin musste ich gestern unter Kubuntu noch das Paket "loop-aes-utils" mit apt-get nachinstallieren (ist Bestandteil von "universe"!).
Diese müssen entweder in den Kernel einkompiliert sein oder mit "modprobe aes" bzw. "modprobe cryptoloop" als root nachgeladen werden.
3. Die Anleitung
3.1 Träger vorbereiten bzw. erstellen
Als erstes sucht man sich eine freie Partition aus (im Beispiel: "/dev/hdb1") oder wählt einen freien Dateinamen (im Beispiel: "datei").
Die freie Datei sollte man zunächst noch erstellen (Achtung: falls "datei" existiert, wird diese überschrieben!):
dd if=/dev/urandom of=datei bs=1024 count=5120
Im Beispiel wird eine 5 MB große Datei erzeugt (1024 Bytes * 5120).
3.2 Verschlüsseltes loopback-Gerät einrichten
WARNUNG: Mit dem folgenden Befehl werden alle Daten auf dem gewählten Träger gelöscht!
losetup -e aes256 /dev/loop0 <Träger>
Dabei ist <Träger> durch den gewählten Träger zu ersetzen, also in unserem Beispiel /dev/hdb1 bzw. datei.
/dev/loop0 muss hierbei ein freies loopback-Gerät sein. Um alle benutzten loopback-Geräte herauszufinden, kann man "losetup -a" verwenden.
Bei einigen Distributionen wie etwa (K)Ubuntu kann es auch /dev/loop/0 sein (da hier für die loopback-Geräte ein eigener Ordner existiert).
Das Passwort, dass man mit diesem Befehl vergibt, muss mindestens 20 Stellen lang sein, und es wird ohne Wiederholung eingegeben (also nicht vertippen!).
3.3 Dateisystem erstellen
Im Beispiel wird auf das nun existierende loopback-Gerät /dev/loop0 ein ext3-Dateisystem angelegt (es kann natürlich ein beliebiges Dateisystem verwendet werden):
mkfs.ext3 /dev/loop0
3.4 loopback-Gerät freigeben
Um sicherzugehen, dass das oben eingetippte Passwort richtig eingegeben wurde, und um gleich einen richtigen Mountpunkt für das verschlüsselte Dateisystem anzulegen, wird das loopback-Gerät nun freigegeben:
losetup -d /dev/loop0
3.5 Mountpunkt erstellen
Wir legen nun in der /etc/fstab einen neuen Eintrag an, der das verschlüsselte Dateisystem beschreibt:
<Träger> <Mountpunkt> ext3 defaults,user,noauto,loop=/dev/loop0,encryption=aes256 0 0
<Träger> und <Mountpunkt> könnten in unserem Beispiel /dev/hdb1 und /mnt/hdb1 sein.
WICHTIG: Verwendet man mehrere verschlüsselte Dateisysteme, so muss stets ein anderes loopback-Gerät verwendet werden (also /dev/loop1, /dev/loop2 usw.).
Die beiden Einträge "user" und "noauto" in den Optionen sind wichtig, wenn man die Partition als normaler User (und nicht als root) mounten möchte, und wenn man verhindern möchte dass beim Booten des PCs das Passwort eingegeben werden muss (insbesondere für einen Server, für den man nur einen SSH-Zugriff hat, wäre das fatal, da der SSH-Dienst erst danach startet).
3.6 Verschlüsselte Partition mounten und umounten
Das geht jetzt ganz einfach über mount und umount:
mount <Mountpunkt>
umount <Mountpunkt>
Bei "mount" muss man stets das Passwort eingeben, das man für die verschlüsselte Partition gewählt hat.
So, ich hoffe, dass dies dein Problem geklärt hat, und einigen Anfängern in diesem Bereich helfen könnte.
Mein Tipp für deine beiden neueren Kryptodateisysteme: Hast du bei denen auch garantiert ein freies loopback-Gerät gewählt? Wenn das eine Dateisystem /dev/loop0 benutzt, kann das andere dieses natürlich nicht mehr verwenden...
Eine weitere kleine Anleitung gibt es übrigens auch auf Pro-Linux.
Falls jemand noch Fehler findet oder etwas nicht ganz versteht: Einfach nochmals nachfragen! :-)
Freundliche Grüße & in Hoffnung, geholfen zu haben
Marc Reichelt || http://www.marcreichelt.de/
Heißa, Marc,
Vielen Dank für deine ausführliche Anleitung. Mir hat nicht viel gefehlt, aber jetzt habe ich das doch besser verstanden.
Das kann sich natürlich je nach Fall unterscheiden, bei mir unter Kubuntu habe ich z.B. kein /dev/loop0, dafür aber ein /dev/loop/0.
Bei mir gibt es zwar /dev/loop0, aber das ist letztendlich ein Link auf /dev/loop/0. ;-)
Das Passwort, dass man mit diesem Befehl vergibt, muss mindestens 20 Stellen lang sein, und es wird ohne Wiederholung eingegeben (also nicht vertippen!).
Anmerkung: Wenn man für losetup noch die Option -T verwendet, wird man zweimal nach dem Passwort gefragt.
3.4 loopback-Gerät freigeben
Um sicherzugehen, dass das oben eingetippte Passwort richtig eingegeben wurde, und um gleich einen richtigen Mountpunkt für das verschlüsselte Dateisystem anzulegen, wird das loopback-Gerät nun freigegeben:
losetup -d /dev/loop0
Das hier verstehe ich nicht so ganz. Bedeutet das, dass ich nun beim nächsten Mounten das Passwort wieder eintippen muss? Muss ich das dann nach jedem Umounten ausführen, oder macht der das automatisch?
<Träger> <Mountpunkt> ext3 defaults,user,noauto,loop=/dev/loop0,encryption=aes256 0 0
Ahja, letztendlich war es diese loop-Option, die mir gefehlt hat.
Aber was ich jetzt noch nicht verstehe: Wenn ich jetzt meine Platte an einen anderen Computer dranhänge, wie gehe ich dort vor, um sie zu mounten? Oder ist das gar nicht möglich?
Gautera!
Grüße aus Biberach Riss,
Candid Dauth
Hallo Candid,
Vielen Dank für deine ausführliche Anleitung. Mir hat nicht viel gefehlt, aber jetzt habe ich das doch besser verstanden.
Das kann sich natürlich je nach Fall unterscheiden, bei mir unter Kubuntu habe ich z.B. kein /dev/loop0, dafür aber ein /dev/loop/0.
Bei mir gibt es zwar /dev/loop0, aber das ist letztendlich ein Link auf /dev/loop/0. ;-)
Hehe, das wird wohl damals bei mir auf Gentoo genauso gewesen sein... :-)
Das Passwort, dass man mit diesem Befehl vergibt, muss mindestens 20 Stellen lang sein, und es wird ohne Wiederholung eingegeben (also nicht vertippen!).
Anmerkung: Wenn man für losetup noch die Option -T verwendet, wird man zweimal nach dem Passwort gefragt.
Danke! Habe die Option selbst irgendwann benutzt, aber mittlerweile vergessen gehabt.
3.4 loopback-Gerät freigeben
Um sicherzugehen, dass das oben eingetippte Passwort richtig eingegeben wurde, und um gleich einen richtigen Mountpunkt für das verschlüsselte Dateisystem anzulegen, wird das loopback-Gerät nun freigegeben:
losetup -d /dev/loop0Das hier verstehe ich nicht so ganz. Bedeutet das, dass ich nun beim nächsten Mounten das Passwort wieder eintippen muss? Muss ich das dann nach jedem Umounten ausführen, oder macht der das automatisch?
Das Programm "losetup" brauchst du nach dem Erstellen der verschlüsselten Partition nie wieder. Alle Dinge werden ab nun "mount" überlassen.
Und natürlich musst du bei jedem mount dein Passwort eingeben - sonst wäre es ja nicht wirksam verschlüsselt... ;-)
<Träger> <Mountpunkt> ext3 defaults,user,noauto,loop=/dev/loop0,encryption=aes256 0 0
Ahja, letztendlich war es diese loop-Option, die mir gefehlt hat.
...und schon löst sich das Problem in Luft auf. :-)
Aber was ich jetzt noch nicht verstehe: Wenn ich jetzt meine Platte an einen anderen Computer dranhänge, wie gehe ich dort vor, um sie zu mounten? Oder ist das gar nicht möglich?
Ganz einfach: Du trägst dort auch in die fstab diese Zeile ein, bzw. gibst die Optionen als Parameter an mount weiter. Mehr macht die fstab ja auch nicht.
Wie gesagt: losetup braucht man nur zum Erstellen des verschlüsselten Dateisystems - und mehr nicht.
Grüße
Marc Reichelt || http://www.marcreichelt.de/
Heißa, Marc,
Hehe, das wird wohl damals bei mir auf Gentoo genauso gewesen sein... :-)
Du bist also von Gentoo auf Kubuntu umgestiegen? Warum das denn?
Aber was ich jetzt noch nicht verstehe: Wenn ich jetzt meine Platte an einen anderen Computer dranhänge, wie gehe ich dort vor, um sie zu mounten? Oder ist das gar nicht möglich?
Ganz einfach: Du trägst dort auch in die fstab diese Zeile ein, bzw. gibst die Optionen als Parameter an mount weiter. Mehr macht die fstab ja auch nicht.
Und die loop-Devices? Werden die automatisch angelegt, oder wie ist das? Weil die braucht der doch, um das zu mounten, oder nicht?
Gautera!
Grüße aus Biberach Riss,
Candid Dauth
Hallo Candid,
Hehe, das wird wohl damals bei mir auf Gentoo genauso gewesen sein... :-)
Du bist also von Gentoo auf Kubuntu umgestiegen? Warum das denn?
Nicht ganz. Bei Linux gilt für mich der Grundsatz: Die Mischung macht's. Gentoo ist bei mir sehr wohl noch im Einsatz - allerdings als Server.
Kubuntu hat sich bei mir mehr als Desktop-Distribution etablieren können. Und zwar aus einem ganz einfachen Grund: Für mein Desktop-System gefiel mir apt-get besser als emerge. Es war einfach weniger zu tun.
Nach rund 7-8 Gentoo-Installationen weiß ich, wovon ich rede.
Aber was ich jetzt noch nicht verstehe: Wenn ich jetzt meine Platte an einen anderen Computer dranhänge, wie gehe ich dort vor, um sie zu mounten? Oder ist das gar nicht möglich?
Ganz einfach: Du trägst dort auch in die fstab diese Zeile ein, bzw. gibst die Optionen als Parameter an mount weiter. Mehr macht die fstab ja auch nicht.Und die loop-Devices? Werden die automatisch angelegt, oder wie ist das? Weil die braucht der doch, um das zu mounten, oder nicht?
Die werden von mount automatisch angelegt, darum brauchst du dich später also nicht mehr zu kümmern.
Mir ging es damals übrigens ähnlich - ich dachte immer, losetup nochmals verwenden zu müssen...
Grüße
Marc Reichelt || http://www.marcreichelt.de/
hallo Marc,
Für mein Desktop-System gefiel mir apt-get besser als emerge. Es war einfach weniger zu tun.
Ups. Da bitte ich doch um Erläuterung. Ich halte apt-get für schwerfällig und wesentlich schwerer bedienbar als emerge. Genau aus diesem Grund sind Debian bzw. die *buntu-Abkömmlinge bei mir _nicht_ die Systeme, die ich als "default"-Desktop-Systeme einsetzen würde. Für den Server bleibt es dann aber bei *BSD.
Nach rund 7-8 Gentoo-Installationen weiß ich, wovon ich rede.
Ich könnte vermutlich ruhigen Gewissens noch ein Null anhängen und weiß auch, wovon ich rede ;-)
Grüße aus Berlin
Christoph S.
Moin!
Für mein Desktop-System gefiel mir apt-get besser als emerge. Es war einfach weniger zu tun.
Ups. Da bitte ich doch um Erläuterung. Ich halte apt-get für schwerfällig und wesentlich schwerer bedienbar als emerge. Genau aus diesem Grund sind Debian bzw. die *buntu-Abkömmlinge bei mir _nicht_ die Systeme, die ich als "default"-Desktop-Systeme einsetzen würde. Für den Server bleibt es dann aber bei *BSD.
Mit Gentoo wartet man (geduldig?) immer Ewigkeiten auf die Vollendung des Kompilationsprozesses. Das ist mitunter schon ein erheblicher Zeit- und Performancefaktor, insbesondere beim Neukompilieren von X.
apt-get holt dagegen Binärpakete. Einmal den Download erledigen, kurz entpacken - fertig einsatzbereit.
Der Pseudo-Vorteil, dass man mit Gentoo natürlich handoptimierte Kompilationsoptionen nutzen könnte, ist erstens nur sehr gering und wird durch die lange Kompilierungslaufzeit mit Sicherheit wieder aufgefressen - im Gegenzug steigt bei übermäßiger Optimierung (-O9 ;) ) die Gefahr, dass Unverträglichkeiten auftreten.
- Sven Rautenberg
hallo Sven,
Mit Gentoo wartet man (geduldig?) immer Ewigkeiten auf die Vollendung des Kompilationsprozesses. Das ist mitunter schon ein erheblicher Zeit- und Performancefaktor, insbesondere beim Neukompilieren von X.
Jaein. Das ist richtig, wenn es sich um die Ersteinrichtung des Systems handelt, die gerade für den X-Server schonmal leicht 4 bis 5 Stunden dauern kann. Ist er einmal vorhanden, kann man aber nach Belieben losarbeiten, Browser und Mail-Programm einrichten usw., während auf einer anderen Konsole gegebenenfalls noch Qt für KDE (was auch sehr lange braucht) vor sich hin kompiliert. X-Server, grafische Oberflächen (KDE, GNOME und XFCE übrigens nahezu gleichwerig im Zeitaufwand) sowie mozilla brauchen tatsächlich eine Menge Zeit.
apt-get holt dagegen Binärpakete. Einmal den Download erledigen, kurz entpacken - fertig einsatzbereit.
Nicht immer in der Form, in der man es eventuell haben möchte. Und zumindest bei Debian (für *buntu-Systeme kann ich das wegen noch mangelnder Kenntnis nicht wirklich aussagen) dauert es oftmals anderthalb Jahre oder noch länger, bis eine aktuelle Software-Version angeboten wird. Das geht bereits beim Kernel los. Debian ist außerordentlich konservativ.
Der Pseudo-Vorteil, dass man mit Gentoo natürlich handoptimierte Kompilationsoptionen nutzen könnte
ist relativ uninteressant. Allerdings gibt es ein paar Softwarepakete, bei denen ich solche Optionen durchaus einstellen möchte, Samba zum Beispiel, den Apache natürlich, und bei KDE brauche ich zum Beispiel kopete nicht, muß es aber mitnehmen, wenn ich nur knode haben will. Das ändert sich erst ab KDE 3.5.
Mit emerge --unmerge werde ich auch "große" Softwarepakete sehr leicht wieder los, wenn ich sie nicht mehr brauche, mit apt fällt das schwerer. Einen Neubau der gesamten "Welt" kriege ich mit Gentoo oder *BSD selbst bei noch laufendem System hin, wirksam wird es erst, wenn nach einem reboot der eventuell neugebaute Kernel arbeitet. Ist mir für Debian und seine Klone noch nicht in gleicher Weise gelungen, da ist portage bzw. das Ports-System wesentlich flexibler. Es mögen ja künftig andere Erfahrungen hinzukommen.
steigt bei übermäßiger Optimierung (-O9 ;) ) die Gefahr, dass Unverträglichkeiten auftreten.
Hm. Derlei "übermäßige Optimierung" kann also im Umkehrschluß bei einer "Paketinstallation" aus bereits vorkompilierten binaries ausgeschlossen werden?
Grüße aus Berlin
Christoph S.
Hallo Christoph,
Für mein Desktop-System gefiel mir apt-get besser als emerge. Es war einfach weniger zu tun.
Ups. Da bitte ich doch um Erläuterung. Ich halte apt-get für schwerfällig und wesentlich schwerer bedienbar als emerge. Genau aus diesem Grund sind Debian bzw. die *buntu-Abkömmlinge bei mir _nicht_ die Systeme, die ich als "default"-Desktop-Systeme einsetzen würde. Für den Server bleibt es dann aber bei *BSD.
Da sehen wir wieder ein Mal, warum es überhaupt so viele unterschiedliche Linux Distributionen gibt: Weil jeder Mensch seinen eigenen Geschmack und seine eigenen Bedürfnisse hat. Ich zum Beispiel finde apt-get nun wirklich nicht schwerfällig.
Nach rund 7-8 Gentoo-Installationen weiß ich, wovon ich rede.
Ich könnte vermutlich ruhigen Gewissens noch ein Null anhängen und weiß auch, wovon ich rede ;-)
Aber auch nur deshalb, weil du dir die anderen Distributionen angeschaut hast. Und genau das finde ich an Linux so toll: Jeder kann selbst wählen, was er haben möchte. Außerdem tut es immer gut, in der Gegend herumzuschnuppern - ich habe unter Gentoo ziemlich viel gelernt (aber auch unter SUSE, Debian, Knoppix und vielen anderen Distributionen).
Zu Gentoo mag ich nur noch eines sagen: Es war für kurze Zeit ein Hype, seine Programme selbst zu kompilieren - und es ist immer noch toll, keine Frage! Vielen Usern ist das dann aber doch zu aufwendig, weshalb Gentoo derzeit an Interesse verliert (auch auf Distrowatch zu sehen). Und genau das ist denke ich auch der Grund, warum ich mich von Gentoo - als Desktop-Distribution - abgewendet habe.
So, jetzt gehe ich erst mal schlafen... :-)
Grüße & gute Nacht
Marc Reichelt || http://www.marcreichelt.de/
Hallo nochmals,
auf ubuntuusers.de steht, das "cryptoloop" Verfahren sei veraltet, und man solle es nicht mehr verwenden. Nur zur Information. Ich selbst kann meine verschlüsselten Partitionen derzeit aber einfach nicht umändern, weshalb ich vorerst bei cryptoloop bleibe.
Grüße
Marc Reichelt || http://www.marcreichelt.de/