Installation auf SSD

[photor]

Hallo Forum,

wie schon angekündigt ung natürlich in Vorfreude auf den Lappy, der da hoffentlich möglicht bald hier einschlägt lese ich mich langsam in das Thema SSD ein. Dabei stolpert man über viele - zum Teil sich widersprechende - Informationen.

Der Rechner kommt (nur) mit einer SSD (256GB), so dass da sowohl das System, die Daten als auch einige "flüchtige" Systemdaten drauf müssen.

Meine bisherigen Rechner haben etwa das folgende Partitionsschema:

• /boot: 200 MB
• LVM mit:
  • SWAP
  • / (=ROOT): 20 GB
  • /home (~180 GB) mit LUKS verschlüsselt

Damit sind etwa 200 GB belegt und es bleibt noch genügend freier Platz für das Wear leveling, denke ich. Mit dem LVM habe ich ja die Flexibilität, zur Not einzelne Partitionen zu vergrößern oder vielleicht doch eine eigene /var-Partition einzuschieben.

Die HOME-Partition würde ich gerne verschlüsseln. Allerdings habe ich gelesen, dass durch das Wear Leveling Daten aus dem LUKS-Container unverschlüsselt außerhalb des Containers landen können. Dann hat eigentlich die Verschlüsselung keinen Sinn, oder? Mir geht es allerdings nicht um die absolute Datensicherheit z.B.gegen die NSA, sonder eher darum, dass, falls der Lappy mal geklaut wird, nicht meine privaten Daten, Bilder etc in der Welt rumgondeln.

Ob SWAP wirklich noch gebraucht wird (der Rechner kommt mit 8GB RAM), weiß mich auch nicht.

Zu diesen Punkten oben (LVM, LUKS-Verschlüsselung und SWAP) habe ich zum Teil widersprüchliches gefunden, teils auch schon (zu?) alt. Daher wollte ich hier nach Eurer Meinung fragen, bevor ich anfange zu installieren.

Dass man einige schreibintensive Verzeichnisse besser als tmpfs ins RAM packt, ist mir klar; auch, wie das gemacht wird.

Wie immer, sehr dankbar für jeden Input.

Ciao,

Photor

[dirk11]

Allerdings habe ich gelesen, dass durch das Wear Leveling Daten aus dem LUKS-Container unverschlüsselt außerhalb des Containers landen können. Dann hat eigentlich die Verschlüsselung keinen Sinn, oder?

Interessante Frage. Ich widerum habe vor kurzem irgendwo gelesen, dass bei einem vollverschlüsseltem System (also mit einem separaten, unverschlüsselten /boot) Daten grundsätzlich nur _verschlüsselt_ auf dem Datenträger landen, sprich entschlüsselt nur im RAM/Cache liegen. Vielleicht wäre das dann empfehlenswert(er)?

Ob SWAP wirklich noch gebraucht wird (der Rechner kommt mit 8GB RAM), weiß mich auch nicht.

Für Suspend_to_disk. Ich frage mich eher, wozu Mensch LVM benötigt. Hast du es wirklich jemals aktiv genutzt? Ebenso die Partitionierung. Hast du jemals irgendeinen Nutzen dadurch gehabt, dass du irgendwelche getrennten Partitionen für /var/, /opt, /home oder /wasweissich gehabt hast? Ich persönlich habe das nur als lästig empfunden, weil immer gerade die Partition zu klein ist, wo man es am wenigsten brauchen kann. Und so lange Rechner nicht von zig verschiedenen (nicht vertrauenswürdigen Personen wie z.B. Mitarbeitern, denen man per se nicht so vertrauen kann wie Familienmitgliedern) Personen benutzt werden, habe ich für mich entschieden, dass sowohl LVM als auch kleinteilige Partitionierung unnütz sind. Im Gegenteil: eine Partition = nur ein Luks-Container. Erheblich einfacher. KISS.

Dass man einige schreibintensive Verzeichnisse besser als tmpfs ins RAM packt, ist mir klar; auch, wie das gemacht wird.

Interessant, mir nicht. Welche, wie, warum? Gibt es dazu ein deutschsprachiges Howto? Wie garantiert man, dass die Daten aus diesen tmpfs doch irgendwann auf der Platte landen, man will nicht immer die logs beim reboot verlieren (nur mal so als Beispiel).
Mich interessiert die Thematik, weil das vielleicht eine Möglichkeit wäre, die beiden Platten meines Homeserver auch im Betrieb ruhig "schlafen" zu legen. Die sind letztlich doch mit die größten Stromverbraucher, auch und gerade im idle.

[peschmae]

Die HOME-Partition würde ich gerne verschlüsseln. Allerdings habe ich gelesen, dass durch das Wear Leveling Daten aus dem LUKS-Container unverschlüsselt außerhalb des Containers landen können.

Kann ich mir nicht vorstellen, wie das funktionieren sollte. Es werden ja alle Blocks der Partition die jemals geschrieben werden verschlüsselt, bevor die SSD die überhaupt sieht. Was natürlich passieren kann und auch wird, ist dass via dein unverschlüsseltes Swap etwas rausleckt... - ich würde wennschon das ganze LVM verschlüsseln, und gut ist.

Ob SWAP wirklich noch gebraucht wird (der Rechner kommt mit 8GB RAM), weiß mich auch nicht.

Für Suspend to Disk halt. Sonst im normalen Betrieb sicher nicht, kommt halt drauf an ob du zwischendurch mal was machst was so richtig Ram braucht...

Dass man einige schreibintensive Verzeichnisse besser als tmpfs ins RAM packt, ist mir klar; auch, wie das gemacht wird.

Naja, das wird meiner Meinung nach von ein paar Leuten deutlich übertrieben - dafür macht die SSD ja ihren ganzen Wear-Leveling Kram. Insbesondere da viele Leute ja das Gegenteil machen (SSD als Caches für die Lese/Schreibintensiven Sachen) und das bestens taugt, würde ich das "Problem" jetzt einfach mal ignorieren...

MfG Peschmä

[photor]

Interessante Frage. Ich widerum habe vor kurzem irgendwo gelesen, dass bei einem vollverschlüsseltem System (also mit einem separaten, unverschlüsselten /boot) Daten grundsätzlich nur _verschlüsselt_ auf dem Datenträger landen, sprich entschlüsselt nur im RAM/Cache liegen. Vielleicht wäre das dann empfehlenswert(er)?

Das (LVM im LUKS) habe ich letztens mal versucht und hatte Probleme (war aber Arch Linux und ich habe es nicht weiter verfolgt). Bin dann wieder auf diese Konfiguration (LUKS in LVM) zurück.

Für Suspend_to_disk.

Stimmt. Aber ich frage mich, ob man das überhaupt macht, wenn man mit SSD genauso schnell rebootet. Dann sollte SWAP auch min. gleich RAM sein (=8GB)

Ich frage mich eher, wozu Mensch LVM benötigt. Hast du es wirklich jemals aktiv genutzt?

Siehe oben. Das ist so meine übliche Aufteilung. Und ja. Ich habe auch schon mit LVM Partitionen vergrößert (immer mit einem mulmigen Gefühl im Bauch - aber es geht )

Ebenso die Partitionierung. Hast du jemals irgendeinen Nutzen dadurch gehabt, dass du irgendwelche getrennten Partitionen für /var/, /opt, /home oder /wasweissich gehabt hast? Ich persönlich habe das nur als lästig empfunden, weil immer gerade die Partition zu klein ist, wo man es am wenigsten brauchen kann.

Wahrscheinlich ist es noch alte Tradition. Der Gedanke dahinter war mal, eine Trennung von System und Daten. So kann dir eine unendlich wachsende Datei nicht die ganze Platte vollschreiben (Log-Datei in /var, Daten in /home etc) und das System selbst bleibt unberührt und arbeitsfähig. Aber bei der Größe der Platten heute ... das überdenke ich nochmal.

Und so lange Rechner nicht von zig verschiedenen (nicht vertrauenswürdigen Personen wie z.B. Mitarbeitern, denen man per se nicht so vertrauen kann wie Familienmitgliedern) Personen benutzt werden, habe ich für mich entschieden, dass sowohl LVM als auch kleinteilige Partitionierung unnütz sind. Im Gegenteil: eine Partition = nur ein Luks-Container. Erheblich einfacher. KISS.

Ist ein Aspekt. Wahrscheinlich hast Du recht. Wobei, so wie oben beschrieben, sind ja nur /boot (weil unverschlüsselt), SWAP, / (verschlüsseltes System) und /home (verschlüsselte Daten) eigene Partitionen. Zusammenlegen kann man / und /home.

Interessant, mir nicht. Welche, wie, warum? Gibt es dazu ein deutschsprachiges Howto? Wie garantiert man, dass die Daten aus diesen tmpfs doch irgendwann auf der Platte landen, man will nicht immer die logs beim reboot verlieren (nur mal so als Beispiel).

Klar. Alles was im RAM steht geht im Notfall (=unkoordinierter Shutdown) verloren. Garantiert hat man sie nach einem Reboot nicht. D.h. bei den Logs würde ich mir überlegen, was man mal brauchen könnte. Aber auch die könnte man in regelmäßigen Abständen auf Platte kopieren; dann verliert man im worst case nur die Infos der letzten Periode.

Aber irgendwelche Cache-Daten von Firefox etc. brauchen einen Reboot nicht unbedingt zu überleben. Gleiches gilt z.B. für /var/run oder /var/lock.

Ciao,

Photor

[Cae]

Sobald der Swap-Speicher nicht verschluesselt ist, kann jederzeit Klartextinhalt (der einst aus der verschluesselten Partition gelesen wurde) aus dem RAM eben doch auf die Platte geschrieben werden. Die Klartextdaten leben noch nach laengerer Laufzeit und auch nach dem Shutdown. Daher sollte Swap unbedingt verschluesselt sein, sobald man irgendwelche groesseren [1] verschluesselten Datenbereiche auf der Maschine hat.

Ich frage mich eher, wozu Mensch LVM benötigt. Hast du es wirklich jemals aktiv genutzt?

Die Snapshot-Funktion von LVM ist sehr praktisch, weil man damit inkonsistente Backups vermeiden kann. Man kann mittels LVM die Partitionierung innerhalb des dm_crypt-Containers anpassen, ohne sich mit n Containern und unterschiedlichen Keyfiles herumzuaergern, die man bei separaten Partitionen zwangslaeufig braeuchte. Auch kann man bei Bedarf gemountete Dateisysteme physikalisch auf andere Platten schieben, oder bei Platzmangel weitere Laufwerke als JBOD dazuhaengen. Ich find' viele Aspekte von LVM praktisch, wobei der durchschnittliche Privatanwender mit vielen Features eher nichts anfangen kann. Die ersten beiden genannten Punkte (Snapshot und Partitionierung) gehoeren aber definitiv nicht dazu.

Gruss Cae

[1] "groessere" deswegen, weil Anwendungen einige wenige KB an RAM als "nie swapbar" markieren koennen (Stichwort mlock(2)). So verhindert zum Beispiel gpg, dass ein entschluesselter Schluessel ungewollt weggeswappt wird.

[photor]

Kann ich mir nicht vorstellen, wie das funktionieren sollte. Es werden ja alle Blocks der Partition die jemals geschrieben werden verschlüsselt, bevor die SSD die überhaupt sieht. Was natürlich passieren kann und auch wird, ist dass via dein unverschlüsseltes Swap etwas rausleckt... - ich würde wennschon das ganze LVM verschlüsseln, und gut ist.

Ich habe das auch nur gelesen und noch nicht verstanden, wieso das so ist (oder auch nicht). Siehe mein vorheriges Post: ich denke es läuft darauf hinaus, eine /boot-Partition unverschlüsselt und eine LVM-Partition, die Verschlüsselt wird und SWAP, und den Rest enthält (also LUKS in LVM).

Naja, das wird meiner Meinung nach von ein paar Leuten deutlich übertrieben - dafür macht die SSD ja ihren ganzen Wear-Leveling Kram. Insbesondere da viele Leute ja das Gegenteil machen (SSD als Caches für die Lese/Schreibintensiven Sachen) und das bestens taugt, würde ich das "Problem" jetzt einfach mal ignorieren...

Wahrscheinlich hast Du recht. Ich habe eben gelesen, dass SSDs mittlerweile praktisch (= im Alltagsbetrieb) die gleiche Lebensdauer haben, wie normale HDDs. Aber trotzdem kann man ja Cache-Directories in ein tmpfs packen. Schaden wird es nicht.

Ciao,

Photor

[dirk11]

Interessante Frage. Ich widerum habe vor kurzem irgendwo gelesen, dass bei einem vollverschlüsseltem System (also mit einem separaten, unverschlüsselten /boot) Daten grundsätzlich nur _verschlüsselt_ auf dem Datenträger landen, sprich entschlüsselt nur im RAM/Cache liegen. Vielleicht wäre das dann empfehlenswert(er)?

Das (LVM im LUKS) habe ich letztens mal versucht und hatte Probleme (war aber Arch Linux und ich habe es nicht weiter verfolgt). Bin dann wieder auf diese Konfiguration (LUKS in LVM) zurück.

Ich meinte keine Änderung der Reihenfolge, sondern Verschlüsselung des kompletten System.

Das ist so meine übliche Aufteilung. Und ja. Ich habe auch schon mit LVM Partitionen vergrößert (immer mit einem mulmigen Gefühl im Bauch - aber es geht )

Hmm. Wenn man das nur "auch schon" gemacht hat, stellt sich mir die Frage, ob man das Verfahren nicht verbessert, in dem man LVM weglässt. Eine Sorge weniger, weil ein Teil weniger Probleme bereiten kann - wenn man nicht so Features wie eben noch genannt benötigt.

Wahrscheinlich ist es noch alte Tradition. Der Gedanke dahinter war mal, eine Trennung von System und Daten. So kann dir eine unendlich wachsende Datei nicht die ganze Platte vollschreiben (Log-Datei in /var, Daten in /home etc) und das System selbst bleibt unberührt und arbeitsfähig.

Das Argument kenne ich. Ist mir in 13 Jahren Linux nie passiert. Aber das ist ja nur meine persönliche Erfahrung.

Zusammenlegen kann man / und /home.

Das meine ich. Dann lässte noch LVM weg (weil man eine vollständig genutzte SSD sowieso nicht verändern kann), und schon ist der Wartungsaufwand geringer und es gibt eine potentielle Problemquelle weniger. My 2cent.

bei den Logs würde ich mir überlegen, was man mal brauchen könnte. Aber auch die könnte man in regelmäßigen Abständen auf Platte kopieren; dann verliert man im worst case nur die Infos der letzten Periode.

Jo. Und das sind dann ausgerechnet die, die man braucht...

Aber irgendwelche Cache-Daten von Firefox etc. brauchen einen Reboot nicht unbedingt zu überleben. Gleiches gilt z.B. für /var/run oder /var/lock.

Stimmt, aber die gibt es bei mir sowieso nicht. Die Frage stellte sich für mich, um auch die Systemplatte in meinem Heimserver schlafenlegen zu können.

[photor]

Hallo dirk11,

Ich meinte keine Änderung der Reihenfolge, sondern Verschlüsselung des kompletten System.

Wie schon oben erwähnt; ich überlege gerade, neben der unverschlüsselten /boot-Partition einen LUKS-Container mit (fast) dem Rest des freien Speichers anzulegen. Ob ich den Platz dann komplett als / (ROOT) einbaue oder mittels LVM verwalte, weiß ich noch nicht.

BTW: wieviel Platz sollte man dem Wear Leveling geben?

Das Argument kenne ich. Ist mir in 13 Jahren Linux nie passiert. Aber das ist ja nur meine persönliche Erfahrung.

Wie gesagt, ich habe das Feature, nachträglich Partitionen zu vergrößern, schon genutzt und war froh es nutzen zu können. Aber ich versuche immer noch, eine Entscheidung zu finden.

Ciao,

Photor

[maledora4]

Keinesfalls möchte ich dem oben gesagten widersprechen...

Ich finde jedoch Du sattelst das Pferd bereits von hinten. Zweifellos ist doch viel interessanter, was ist denn für eine SSD eingebaut?
Viele, der von Dir erwähnten Beiträge im Netz sind doch mit "aufkommen der SSD's" entstanden, wo die Leute sich erst einmal klar werden wollten, was sie da in der Hand haben und wie das funktioniert.

In der Zwischenzeit ist die Entwicklung weiter fortgeschritten!
Deshalb, wenn das Ding da ist

Code: Alles auswählen

hdparm -I /dev/sd(X)
und hier der Abschnitt
Commands/features:
	Enabled	Supported:

Dann weißt Du, was SIE kann.

[dirk11]

Wie gesagt, ich habe das Feature, nachträglich Partitionen zu vergrößern, schon genutzt und war froh es nutzen zu können. Aber ich versuche immer noch, eine Entscheidung zu finden.

In einem Desktop mag das sinnvoll erscheinen. Aber bei einem Laptop, dem man wohl kaum eine zweite Platte auf den Rücken schnallt, eher nicht. Da musst du die SSD sowieso austauschen.

[photor]

In der Zwischenzeit ist die Entwicklung weiter fortgeschritten!
Deshalb, wenn das Ding da ist

Code: Alles auswählen

hdparm -I /dev/sd(X)
und hier der Abschnitt
Commands/features:
	Enabled	Supported:

Dann weißt Du, was SIE kann.

Ich warte ja schon aller-ungeduldigst auf das Ding Wenn's denn endlich da ist, melde ich mich wieder und teile meine Begeisterung - hoffe ich jedenfalls.

Danke an alle, die mir hier mit ihrer Meinung geholfen haben.

Ciao,

Photor

[cosmac]

hi,

Die HOME-Partition würde ich gerne verschlüsseln. Allerdings habe ich gelesen, dass durch das Wear Leveling Daten aus dem LUKS-Container unverschlüsselt außerhalb des Containers landen können.

das ist vielleicht ein Missverständnis aus der Ecke "Tools zum sicher löschen". Die überschreiben ja (unverschlüsselte) Dateien mit Zufallsdaten. Das funktioniert mit SSDs nicht zuverlässig, weil der ursprüngliche Datenblock zwecks Wear Leveling eben nicht überschrieben wird. Je nach SSD-Controller bewirkt so ein Tool im ungünstigsten Fall garnichts, im schwierigsten Fall muss man zum Auslesen ein paar Drähte an die SSD-Chips löten.

Bei 8GB RAM würde ich sagen: wenn du Zweifel hast, brauchst du kein swap. Wenn du eine Anwendung benutzt, für die swap sinnvoll ist, dann weißt du auch wie viel du brauchst.

Viele, der von Dir erwähnten Beiträge im Netz sind doch mit "aufkommen der SSD's" entstanden, wo die Leute sich erst einmal klar werden wollten, was sie da in der Hand haben und wie das funktioniert.

In der Zwischenzeit ist die Entwicklung weiter fortgeschritten!

Ja, leider. Man weiß inzwischen, wie man noch mehr Bits in noch kleinere Flash-Chips presst und wie man die resultierenden Fehler mit aufwendigerem ECC vertuschen kann. Mit SSDs aus dem Kaufhaus gelten die alten Vorsichtsmaßnahmen heute noch genauso.

[photor]

Hallo Forum,

der Neue ist da! Es ist ein ThinkPad T440s!

Nach ein paar Versuchen habe ich es auch geschafft, in's BIOS-Setup zu kommen, Legacy BOOT zu erlauben und vom externen USB-DVD-Rom eine Knoppix 7.1 zu booten.

Viel Zeit habe ich leider heute Abend nicht mehr. Aber die Partitionstabelle der SSD habe ich noch kurz rausgeschrieben:

Code: Alles auswählen

Device    Filesystem Mounted on   Bezeichnung  Größe     Markierung
/dev/sda1 ntfs       /media/sda1  WINRE_DRV   1000MiB     hidden, diag
/dev/sda2 fat32      /media/sda2  SYSTEM_DRV   260MiB     boot
/dev/sda3 unbekannt  /media/sda3                28MiB     msftres
/dev/sda4 ntfs       /media/sda4  Windows8_OS  212.89GiB
/dev/sda5 ntfs       /media/sda5  Lenovo_Recovery 17.22GiB  hidden, diag
/dev/sda6 unbekannt  /media/sda6                 7GiB     hidden

Gibt es da etwas, was ich sichern sollte, bevor ich mit gparted die Platte platt mache?

• Weiß jemand, was es mit sda6 (spare für wear leveling?) und sda3 auf sich hat?
• Gleiches für sda1?
• sda2 bietet sich ja gerade zu als /boot an
• sda4 ist dem Tode geweiht und würde ja eigentlich als Linux-System-Platte für ein LVM (min. SWAP und /) bzw. LUKS-Container reichen.

Ansonsten bin ich gespannt, was der Rechner so kann. Bei Knoppix wurde der VESA-Treiber geladen; da geht bestimmt noch was. Hab hier einen Stick mit dem Debian 7.2 AMD64 NetInstall ISO liegen. Der wird dann als nächstes gebootet Vielleicht berichte ich ja weiter.

Ciao,

Photor