Kann keine verschlüsselte Partition erstellen

[wanne]

Aktuell hast du aber das Problem, dass du eine SSD hast, die defekte Sektoren meldet. Das bedeutet, sie ist kaputt. Man _sollte_ die SSD dazu bringen können, sich zu reparieren, indem man einen Speicherbereich explizit freigibt. Solange es nur 5 defekte Sektoren sind, ist das sinnvoll. Wenn es mehr sind oder mehr werden, ist die SSD eindeutig kaputt und du willst sie nicht mehr benutzen und vielleicht reklamieren.

Das muss nicht unbedingt sein. Folgt man diesem Beitrag:
http://forums.lenovo.com/t5/T400-T500-a ... 083/page/2
Scheint es leute zu geben, die die Erfahrung gemacht haben, das das Ding schlicht bei starker Belastung aufgibt, und dann behauptet, das die Sektoren nicht mehr beshreibbar seien. Lässt man das überschreibn mit Zufallszahlen weg ist es eher unwahrscheinlich, dass die Belastung für die SSD jemals wieder so hoch wird.
=> Vielleicht hört man nie wieder was davon.
Du kannst aber auch mal eine sehr Große Datei mit zufallswerten anlegen und die unter Windows kopieren.
Scheitert das auch regelmäßig kannst du das Ding vielleicht zurückgeben. Ohne dir anhören zu müssen, das das nur an Linux liegt.

[NAB]

Das muss nicht unbedingt sein. Folgt man diesem Beitrag:
http://forums.lenovo.com/t5/T400-T500-a ... 083/page/2

Und wenn man dem Beitrag nicht nur folgt, sondern ihn auch liest, entdeckt man doch ein paar interessante Details. Geholfen haben soll den Leuten dort:
* Mainboardwechsel im Laptop
* Das Ausschalten des Powermanagements der Controller im Kernel
* Eine Austausch-SSD von Samsung

Von "starker Belastung" steht da hingegen nichts.

Das mit dem Powermanagement könnte man noch mal ausprobieren. Dazu müsste man dem Kernel den Parameter "pcie_aspm=off" in Grub mitgeben. Außerdem soll in /sys/class/scsi_host/hostX/link_power_management_policy das aktuelle Sata Link Powermanagement stehen (und sich über /usr/lib/pm-utils/power.d/sata_alpm einstellen lassen), aber ich finde diesen Eintrag gar nicht im /sys-Verzeichnis - scheint, als ob Debian diese Option im Kernel eh ausschaltet.

Edit: Der Thread von wanne ist wirklich höchstinteressant. Anscheinend hat Lenovo an der Firmware rumgepfuscht, weswegen der Intel-Updater sie nicht mehr erkennt. Ein Firmware-Update von Lenovo gibt es hier:
http://support.lenovo.com/en_US/downloa ... D=HT076644
aber das scheint nicht zu helfen.

Außerdem gibt es dazu inzwischen einen Debian-Bugreport:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691427
bisher ohne Lösung. Dort findet sich ein kleines Programm, das durch singlethreaded random-writes den Fehler auslöst.

P.S.: JustAnotherNoob, falls das nicht klar geworden ist - deine SSD ist nicht "kaputt", sondern eine Fehlkonstruktion von Lenovo. Wenn die hier erwähnten Tricks nicht helfen, brauchst du wirklich eine neue SSD.

[wanne]

Das muss nicht unbedingt sein. Folgt man diesem Beitrag:
http://forums.lenovo.com/t5/T400-T500-a ... 083/page/2

Und wenn man dem Beitrag nicht nur folgt, sondern ihn auch liest, entdeckt man doch ein paar interessante Details. Geholfen haben soll den Leuten dort:
* Mainboardwechsel im Laptop
* Das Ausschalten des Powermanagements der Controller im Kernel
* Eine Austausch-SSD von Samsung

Muss zugebendas ich nach dem Beitrag von „madi“ nur noch überflogen habe. (Das war der mit der Austausch-SSD von Samsung.) Ab da war für mich geklärt, dass das ding nicht will und der rest wohl nicht schadhaft ist.

Von "starker Belastung" steht da hingegen nichts.

After launching a PHP CLI script that import thousands of database records into my local database (so there's probably a lot of disk writes), the computer begins to slow down, until the kernel output a "journal commit I/O error"

I have replaced my Intel HDD with a Samsung 830-series 256GB drive and the problems went away. In fact, it's running even faster than before. I'm using the original Intel SSD as a second drive in the ultrabay now, in place of the cd-rom drive, to store non-i/o-intensive stuff.

=> Für „non-i/o-intensive stuff“ scheit's zu funktionieren.

I can reproduce the issue by firing sql update queries to the local MySQL 5.5.

Klingt auch nach starker belastung.

Das mit dem Powermanagement könnte man noch mal ausprobieren. Dazu müsste man dem Kernel den Parameter "pcie_aspm=off" in Grub mitgeben. Außerdem soll in /sys/class/scsi_host/hostX/link_power_management_policy das aktuelle Sata Link Powermanagement stehen (und sich über /usr/lib/pm-utils/power.d/sata_alpm einstellen lassen), aber ich finde diesen Eintrag gar nicht im /sys-Verzeichnis - scheint, als ob Debian diese Option im Kernel eh ausschaltet.

Bei mir gibt's die Optionen. Komischerweise für hosts von denen ich keine ahnung habe welche das sind.

P.S.: JustAnotherNoob, falls das nicht klar geworden ist - deine SSD ist nicht "kaputt", sondern eine Fehlkonstruktion von Lenovo. Wenn die hier erwähnten Tricks nicht helfen, brauchst du wirklich eine neue SSD.

Also bis auf nicht kaputt stimme ich dir zu. Nur weil der Fehler reproduzierbar auf verschiedenen Laptops mit versciedenen SSDs ist, ist es doch ein Fehler.

[NAB]

Von "starker Belastung" steht da hingegen nichts.

After launching a PHP CLI script that import thousands of database records into my local database (so there's probably a lot of disk writes), the computer begins to slow down, until the kernel output a "journal commit I/O error"

Klingt nach singelthreaded und Datenimport über's Netzwerk, also vermutlich max. Gbit, wo sich die SSD die größere Zeit langweilt. Ausschlagebend dürften eher die random writes einer Datenbank sein.

Wer anders berichtete, dass er die SSD komplett durchgehend bei voller Geschwindigkeit lesen und schreiben konnte, aus Testzwecken, das dürfte ne höhere Last erzeugt haben, wenn auch mit linearem Zugriff.

I can reproduce the issue by firing sql update queries to the local MySQL 5.5.

Klingt auch nach starker belastung.

Klingt für mich eher nach einzelnen manuellen update queries, also wieder "random write".

Bei mir gibt's die Optionen. Komischerweise für hosts von denen ich keine ahnung habe welche das sind.

Hupps? Gut zu wissen! Welcher Kernel? Und hast du laptop-mode-tools oder sowas installiert?

]Also bis auf nicht kaputt stimme ich dir zu. Nur weil der Fehler reproduzierbar auf verschiedenen Laptops mit versciedenen SSDs ist, ist es doch ein Fehler.

Natürlich ist das ein Fehler, ein fetter Fehler sogar, aber ein Fehler im Sinne von "Fehlkonstruktion" und nicht "kaputt" im Sinne von "ging mal, lässt sich vielleicht wieder reparieren".

Wobei mir einiges unklar ist. Was JustAnotherNoob gemacht hat, hatte ja eben nichts mit "random writes" zu tun, das sollten lineare Schreibzugriffe gewesen sein. Und bei ihn lief es ja anscheinend mit der alten Linux-Installation mit Verschlüsselung auch.

Und warum Lenovo ne eigene Firmware auf ne SSD setzen muss und es dann (mit vermuteter Hilfe von Intel) nicht schafft, das zu reparieren, verstehe ich auch nicht.

[wanne]

Klingt für mich eher nach einzelnen manuellen update queries, also wieder "random write".
[…]
Wobei mir einiges unklar ist. Was JustAnotherNoob gemacht hat, hatte ja eben nichts mit "random writes" zu tun, das sollten lineare Schreibzugriffe gewesen sein. Und bei ihn lief es ja anscheinend mit der alten Linux-Installation mit Verschlüsselung auch.

Ja, Ich habe mir das so zusammengebastelt das das ding drauf geht wenn viele writes kommen. – Egal wie groß die sind. Deswegen habe ich auch einfach unbestimmt hohe last und nicht hoher durchsatz geschrieben.
Kann aber auch sein, das die Installation doch schon begonnen hat. Da gibt's dann viele Random writes. (Wobei das dann nicht zur beschreibung passt.)

Und warum Lenovo ne eigene Firmware auf ne SSD setzen muss und es dann (mit vermuteter Hilfe von Intel) nicht schafft, das zu reparieren, verstehe ich auch nicht.

Ja, sehr unverständlich zumal sich beide sonst eher darum bemüht sind das „Medion Image“ („Wir liefern mal was aus und der Kunde darf dann gucken ob's funktioniert“) eher zu meiden.

Natürlich ist das ein Fehler, ein fetter Fehler sogar, aber ein Fehler im Sinne von "Fehlkonstruktion" und nicht "kaputt" im Sinne von "ging mal, lässt sich vielleicht wieder reparieren".

Da müsste man jetzt genau nachforschen was kaputt bedeutet.
Du scheinst diese Definition zu nutzen:

ein vormals funktionierender Zustand ist funktionslos

Während mir eher die geläufig zu sein scheint:

in einem schadhaften oder funktionslosen Zustand

Leider finde ich „kaputt“ nicht im duden nur „kaputt machen“. (Was wohl auch interessanter weise älter als das alleinstehende Adjektiv „kaputt“ zu sein scheint.)

Allerdings ist schon im ersten Beitrag aus dem kontext heraus ersichtlich was gemeint ist.

[NAB]

Ja, Ich habe mir das so zusammengebastelt das das ding drauf geht wenn viele writes kommen. – Egal wie groß die sind. Deswegen habe ich auch einfach unbestimmt hohe last und nicht hoher durchsatz geschrieben.

Also irgendwie mit "schreiben" hat es garantiert zu tun ... ich hab keinen einzigen Bericht über Lesefehler gefunden. Die meisten Beispiele aus deinem Thread sahen mir aber nach "viel lesen, wenig schreiben" aus. Und es ging jeweils relativ schnell - nach wenigen Minuten.

Kann aber auch sein, das die Installation doch schon begonnen hat. Da gibt's dann viele Random writes.

hmmm ... gibt's die wirklich? Ich wüsste nicht, warum der Installer eine Datei, die er erstellt, für "random write" öffnen sollte ... der kopiert doch eigentlich nur, oder?

Aber wie auch immer ... die SSD sollte keine Schreibfehler produzieren - irgendwas ist da faul.

Leider finde ich „kaputt“ nicht im duden nur „kaputt machen“. (Was wohl auch interessanter weise älter als das alleinstehende Adjektiv „kaputt“ zu sein scheint.)

Das ist interessant - schau dir mal den Abschnitt über die Etymologie von "kaputt" in der Wikipedia an. Wenn der Begriff "kaputt machen" wirklich älter ist, dann dürfte Ursprung (b) der richtige sein, im Sinne von "jemanden kaputt machen". Aber ich glaub, ne germanistische Diskussion wird hier etwas offtopic.

Ich hab grad noch einen Recher mit standard Wheezy Kernel gefunden, der den link_power_management_policy-Eintrag anbietet - ein Desktop von Medion. Eventuell hängt das davon ab, was das BIOS bzw. ACPI anbieten. Inhalt war aber "max_power", also Stromsparen ist ausgeschaltet.

[wanne]

Also irgendwie mit "schreiben" hat es garantiert zu tun ... ich hab keinen einzigen Bericht über Lesefehler gefunden. Die meisten Beispiele aus deinem Thread sahen mir aber nach "viel lesen, wenig schreiben" aus.

Ja aber z.B. der erste hat viel schreiben wenig lesen. (SQL-Import)

Kann aber auch sein, das die Installation doch schon begonnen hat. Da gibt's dann viele Random writes.

hmmm ... gibt's die wirklich? Ich wüsste nicht, warum der Installer eine Datei, die er erstellt, für "random write" öffnen sollte ... der kopiert doch eigentlich nur, oder?

Ja aber die aller meisten Dateien dürften sehr klein sein (wahrscheinlich sogar unter der Blockgröße der SSD oder des FS.)

Und es ging jeweils relativ schnell - nach wenigen Minuten.

Ist hier doch auch so.

[JustAnotherNoob]

Ich geb hiermit offiziell auf, da ich meiner Festplatte nicht noch mehr gebastel zumuten will. Notgedrungen wird das nun auf dem festen PC versucht(mir wäre es auf dem Laptop zwar lieber gewesen, aber mittlerweile auch zu aufwändig).

Ich hab jetzt nur noch eine letzte Frage betreffend bootloader:
Ausgangslage: Leere Festplatte. Dann wird installiert:
sda windows bootloader
sda1 windows 7
sda2+ frei

Stufe 2 Debianinstallation:
sda windows bootloader
sda1 windows 7
sda2 100MB hier soll dann grub2 installiert werden anstatt in den mbr(sda)
sda3 150MB /boot
sda5 encryptet lvm /, /home, swap

Stufe 3: Windowssystempartition verschlüsselt mit Truecrypt, Truecrypt bootloader in den MBR
sda tc bootloader
sda1 windows 7
sda2 grub2
sda3 /boot
sda5 encryptet lvm /, /home, swap

Jetzt wenn ich richtig recherchiert habe sollte es jetzt möglich sein windows per passworteingabe zu starten und beim betätigen von esc würde grub2 geladen, da nach bootbaren partitionen gesucht wird.

Die Frage ist jetzt folgende, sollte das rot-markierte während der Debianinstallation möglich sein, oder dürften theoretisch Fehler zu erwarten sein?
(Um ehrlich zu sein, hab schon probiert grub2 dahin zu installieren und hab n'schwerwiegenden Fehler bekommen(Wortlauf der Fehlermeldung), habe danach aber auch die gleiche Fehlermeldung bekommen, als ihm anschliessend gesagt hab, dann nimm doch trotzdem MBR)

edit: Anmerkung: Dieses Mal handelt es sich um eine herkömmliche Festplatte(HDD) die korrekt arbeiten sollte[zumindest habe ich bis jetzt keine Fehlermeldungen erhalten, die ich auf die Festplatte zurückführen würde]

edit2: wäre natürlich auch für truecrypt alternativen offen, falls Probleme zu erwarten wären

[wanne]

Ich geb hiermit offiziell auf, da ich meiner Festplatte nicht noch mehr gebastel zumuten will. Notgedrungen wird das nun auf dem festen PC versucht(mir wäre es auf dem Laptop zwar lieber gewesen, aber mittlerweile auch zu aufwändig).

Mach dazu besser einen eigenen Tread auf. bzw. Kann das bitte ein admin/moderator abtrennen?

Ich hab jetzt nur noch eine letzte Frage betreffend bootloader:
Ausgangslage: Leere Festplatte. Dann wird installiert:
sda windows bootloader
sda1 windows 7
sda2+ frei

Stufe 2 Debianinstallation:
sda windows bootloader
sda1 windows 7
sda2 100MB hier soll dann grub2 installiert werden anstatt in den mbr(sda)
sda3 150MB /boot
sda5 encryptet lvm /, /home, swap

Stufe 3: Windowssystempartition verschlüsselt mit Truecrypt, Truecrypt bootloader in den MBR
sda tc bootloader
sda1 windows 7
sda2 grub2
sda3 /boot
sda5 encryptet lvm /, /home, swap

DU hast da was falsch verstanden. Grub liegt immer in /boot. Lediglich ein ganz kleiner Tei liegt in den ersten 512 der Festplatte oder einer Partition. Da da sonst keine Daten liegen kannst du das auf eine Beliebige andere Partition packen. Typischerweise auf sda3. Im prinzip ist das aber wurst wo. Du kannst den ach vorne auf die Windows oder Verschlüsselte Partition drauf packen ohne das Windows bzw. LUKS was davon merkt. => sda2 ist überflüssig wenn du dir das dann anschaust wird da nichts drauf sein.

Jetzt wenn ich richtig recherchiert habe sollte es jetzt möglich sein windows per passworteingabe zu starten und beim betätigen von esc würde grub2 geladen, da nach bootbaren partitionen gesucht wird.

Ich glaube irgend wie nicht, das das funktioniert. Ist aber nur ein Gefühl. Wenn du irgend wo gefunden hast, dass doch kannst du das Probieren. Ich würde einen einfachen Bootloader vorne dran setzen, der dann nach Wahl alles andere starten kann. (wie hier: https://wiki.archlinux.de/title/Dual_Bo ... einrichten)
Aber wie gesagt nur so ein Gefühl.

Die Frage ist jetzt folgende, sollte das rot-markierte während der Debianinstallation möglich sein, oder dürften theoretisch Fehler zu erwarten sein?
(Um ehrlich zu sein, hab schon probiert grub2 dahin zu installieren und hab n'schwerwiegenden Fehler bekommen(Wortlauf der Fehlermeldung), habe danach aber auch die gleiche Fehlermeldung bekommen, als ihm anschliessend gesagt hab, dann nimm doch trotzdem MBR)

Das ist prinzipell gar kein Problem Wenn er im MBR liegt kannst du ja einfach debian booten und dann einfach einmal grub-install /dev/sda3 ausführen (als root) und der grub liegt auch auf sda3. Danach solltest du den Windows Bootloader im MBR wiederherstellen könne. Allerdings währe die Fehlermeldung interessant. (Guter Hinweis auf irgendwelchen potenteillen anderen Fehler.)

edit2: wäre natürlich auch für truecrypt alternativen offen, falls Probleme zu erwarten wären

Lass es. Ist wesentlich komplizierter.

[NAB]

sda2 100MB hier soll dann grub2 installiert werden anstatt in den mbr(sda)
Die Frage ist jetzt folgende, sollte das rot-markierte während der Debianinstallation möglich sein, oder dürften theoretisch Fehler zu erwarten sein?
(Um ehrlich zu sein, hab schon probiert grub2 dahin zu installieren und hab n'schwerwiegenden Fehler bekommen(Wortlauf der Fehlermeldung), habe danach aber auch die gleiche Fehlermeldung bekommen, als ihm anschliessend gesagt hab, dann nimm doch trotzdem MBR)

Bist du eigentlich über die unterschiedlichen Partitionsarten "MBR" und "GPT" informiert?

Wenn du eine GPT wählst, dann ist die Idee mit der kleinen Partition gar nicht schlecht. Genauer gesagt wird die dann sogar schon vom Debian-Installer angelegt. ABER: TrueCrypt kann mit einer GPT nicht umgehen. Du musst also durch Vorpartitionierung sicherstellen, dass ein MBR verwendet wird. (Win7 tendiert meines Wissens noch zum MBR, solange keine alte GPT auf der Platte ist)

Bei einer MBR-Partitionierung macht die eigene Partition für Grub hingegen keinen Sinn. Du willst Grub nach sda3 /boot installieren (welches dann ja sda2 wäre). Dabei wird der Bootloader, der nur ein paar Byte groß ist, an den Anfang der Partition geschrieben, statt ihn in den Anfang des MBR zu schreiben.

Stimmt, Grub und der Debian-Installer beschweren sich heftig darüber ... der gesamte Bootvorgang ist auf diese Weise sehr fragil ... sobald die restlichen zu Grub gehörenden Dateien in /boot/ im Dateisystem verschoben werden (z.B. durch ein Update), zerbricht der gesamte Boot-Mechanismus. Darum ist nach jeder Änderung an /boot/ ein "update-grub" nötig. Und darum schimpft Grub so laut. Aber es geht nicht anders, also sag Grub einfach, dass du schon weißt, was du tust, und er seinen Bootloader nach /dev/sda3 installieren soll.

Du solltest dir unbedingt eine SuperGrubDisk bereithalten - eventuell bootet Debian danach nicht ohne.

Ob TrueCrypt den Grub-Bootloader am Anfang der /boot/-Partition erkennt und der Trick mit dem ESC klappt, kann ich dir nicht versprechen, immerhin wird TrueCrypt seit gut einem Jahr nicht mehr weiterentwickelt, aber du solltest es unbedingt versuchen, es wäre die einfachste Lösung.

Insbesondere solltest du dazu testweise neben der Windows-Partition auch mal der /boot/-Partition das "boot"-Flag verpassen.

edit2: wäre natürlich auch für truecrypt alternativen offen, falls Probleme zu erwarten wären

Sicher gibt es Alternativen,. aber TrueCrypt ist meiner Meinung nach die beste. Wichtiger ist, dass du über alle Alternativen mit TrueCrypt informiert bist. Die wären:
1) Mit TrueCrypt-Bootloader
* SuperGrubDisk
* Den Grub-Bootloader auf einen USB-Stick installieren (bedeutet, dass du dann per BIOS auswählen musst, von was du bootest)
* Grub über den Windows-Loader nachladen (bedeutet, du musst zwei Passwörter eingeben)
2) Mit Grub-Bootloader
* Den TrueCrypt-Bootloader aus einer Datei nachladen (ist so einfach, wie es klingt)
* TrueCrypt von der RescueCD starten

Eine Alternative gibt es, die du ernsthaft prüfen solltest:
Debian verschlüsselt installieren und Windows in einer virtuellen Maschine betreiben.