« Archives in April, 2012

Neuer Dockstar Kernel für Debian (3.0.30)

Heute wurde ein neuer longterm Kernel freigegeben, es handelt sich um 3.0.30. Ihr findet ihn wie immer unter “Dockstar Kernel“. Dort gibt es die Installationsanleitung, Downloadlinks und md5sums usw.

Falls ihr von 2.6.32.x kommt, lesen bitte die Anmerkungen im 3.0.23 Kernel Post oder auf der Dockstar Kernel Seite.

Wie immer: Falls eure Dockstar brennt, kaputt geht, in die Luft fliegt oder sonstiges, übernehme ich keine Verantwortung dafür.

Danke an Jeff für seine Konfig und seine fantastische Arbeit mit der Dockstar. Besucht sein Forum, es ist die beste Anlaufstelle für Dockstarnutzer.

Wie sichert man LVM Metadaten und LUKS Header? (Wie stellt man sie wieder her?)

Da ich euch ja neulich meine kleine Datenrettungsgeschichte erzählt habe, wollte ich noch kurz erwähnen wie man sich vor fehlenden Headern, Metadaten usw. schützen kann, indem man vorher ein Backup davon erstellt.

Für das Beispiel nehmen wir an, dass /dev/sda1 ein LUKSdevice ist, auf bzw. in dem ein LVM2 ist, dessen Volumegroup bla hießt.

Fangen wir mit den LUKS Headern an:

cryptsetup luksHeaderBackup /dev/sda1 --header-backup-file Backup_der_LUKS_Header.backup

Keine Sorge, diese Dateien beinhalten nichts sicherheitskritisches, man kann mit ihnen nichts anfangen, wenn man das Passwort nicht kennt. Man kann diese Daten auch jederzeit aus einem verschlüsselten Container/Device auslesen. Wer trotzdem noch Bedenken hat, kann die Datei ja mit gpg oder ähnliches verschlüsseln.

Dann sichern wir noch die LVM/LVM2 Metadaten:

sudo vgcfgbackup -f Backup_LVM_Metadaten.backup bla

bla ist der Name der Volumegroup, wer ihn nicht weiß, kann sich mit sudo vgdisplay alle Volumegroups und deren Namen anzeigen lassen. Diese Metdaten enthalten auch alle Infos über die physikalischen Volumes usw. .. sprich es ist alles über das LVM gesichert. Auch hier gilt wieder: Nichts davon ist bedenklich in Sachen Sicherheit.

Somit haben wir nun im Falle eines Falles eine wichtige Hilfe für eine Restaurierung, darum ist auch eine (verschlüsselte) Speicherung auf Dropbox (oder sowas) empfehlenswert.

Wie man diese Sicherungen dann im Notfall benutzt habe ich ja bereits im oben verlinkten Post erklärt, aber hier nochmal kurz die Zusammenfassung:

cryptsetup luksHeaderRestore --header-backup-file Backup_der_LUKS_Header.backup /dev/sda1
sudo cryptsetup luksOpen /dev/sda1 blubb
sudo pvcreate --uuid "some_long_string" --restorefile Backup_LVM_Metadaten.backup /dev/mapper/blubb
sudo vgcfgrestore -f Backup_LVM_Metadaten.backup bla
sudo pvscan
sudo vgscan
sudo vgchange -ay bla
sudo mount /dev/mapper/bla-bla1 /mnt/bla1 
... (usw. eben die Partitionen mounten)

Nicht verwechseln: bla ist die VolumeGroup, blubb ist der benutzte Name für das LUKSdevice. Die UUID some_long_string muss natürlich die gleiche sein, die in Backup_LVM_Metadaten.backup steht (die UUID des physikalischen Volumes (PV).)

So, ich hoffe ihr konntet damit was anfangen. Wie immer kein Anspruch auf Vollständigkeit oder Richtigkeit.

Quellen: Ubuntu Wiki TechRepublic Man Page von vgcfgbackup und ansonsten die gleichen Quellen aus dem Datenrettungspost.

Neuer Dockstar Kernel für Debian (3.0.29)

Heute wurde ein neuer longterm Kernel freigegeben, es handelt sich um 3.0.29. Ihr findet ihn wie immer unter “Dockstar Kernel“. Dort gibt es die Installationsanleitung, Downloadlinks und md5sums usw.

Falls ihr von 2.6.32.x kommt, lesen bitte die Anmerkungen im 3.0.23 Kernel Post oder auf der Dockstar Kernel Seite.

Wie immer: Falls eure Dockstar brennt, kaputt geht, in die Luft fliegt oder sonstiges, übernehme ich keine Verantwortung dafür.

Danke an Jeff für seine Konfig und seine fantastische Arbeit mit der Dockstar. Besucht sein Forum, es ist die beste Anlaufstelle für Dockstarnutzer.

Eine kleine Geschichte zur Datenrettung bei LVM2 und LUKS.

Nachdem ich es heute geschafft habe, meine “Ersatz” Festplatte (Ersatz während die SSD gerade auf Garantie getauscht wird) versehentlich teilweise zu löschen, in dem ich auf dem falschen Gerät – nämlich auf der HDD – ein Secure Erase gemacht habe, dachte ich, ich erzähl euch mal kurz wie die anschließende Datenrettung ablief.

Nachdem ich den Secure Erase gestartet hatte, bemerkte ich den Fehler natürlich innerhalb einiger Sekunden und brach den Secure Erase (der auf der HDD ca. 45 Minuten dauert) ab (durch Stecker ziehen, anders ging es nicht), aber natürlich war erst mal alles kaputt … LVM (eigentlich LVM2) kaputt, LUKS Verschlüsselung kaputt, kurz: nichts ging mehr.

Hab mich natürlich riesig gefreut, kann sich ja jeder vorstellen. An für sich ist es kein so großes Problem, ich hatte ja ein Backup (welches wenige Tage alt war), somit war nicht sooo viel verloren. Allerdings lagen im Homeverzeichniss ein paar Bilder, die ich seitdem geschossen habe und gerne wieder hätte.

Was stand also zur Auswahl?
a) Recovery der CF Karte der Kamera(da liegen irgendwo verstreut normalerweise auch die Dateien nach dem Löschen)
b) Recovery der HDD

Eigentlich wäre a) schneller gegangen, hat aber zwei Nachteile: Oft sind die Dateien danach teilweise korrupt und fast immer fehlen die Dateinamen. Bei der Menge an Bildern wird es ein riesen Spaß sie zuzuordnen.
Also probierte ich erstmal b), denn die Daten dürften wohl noch da sein, da der secure erase wohl erstmal die vorderen Partitionen (/boot usw.) killt. Nimmt man sich die 45 Minuten Dauer (sagt hdparm -I) zu Herzen, so kann also nicht viel mehr als 1/45 fehlen. Innerlich habe ich schon extundelete (ein super Tool zur Datenrettung auf ext2/3/4 Laufwerken) bereit gestellt, aber dann fiel mir auf: Ups, du nutzt ja Luks und LVM2.

Also ist der erste Schritt das Lukslaufwerk zu reparieren, kein Problem, ich fertige ja immer Headerbackups an.
Problem: Das Laufwerk wird gar nicht mehr erkannt. Mhhpf! Weder fdisk noch sonst ein Programm findet es, lsusb zeigt es aber als angesteckt.
Nach längerer Denkpause fiel mir ein, dass es vermutlich noch “locked” ist, weil der Secure Erase ja nur unterbrochen wurde.
Also wieder “unlocken” und das Sicherheitsgedöhns abschalten mit hdparm:

sudo hdparm -I /dev/xyz
sudo hdparm --user-master u --security-unlock Eins /dev/xyz
sudo hdparm --user-master u --security-disable Eins /dev/xyz
sudo hdparm -I /dev/xyz

Nach einmal kurz an- und abstecken wurde sie dann wieder korrekt erkannt.
Ausgefüht hatte ich den Secure Erase übrigens mit diesem Tutorial, daher auch das Passwort “Eins”. Die Manpage von hdparm gibt ebenfalls eine gute Übersicht der Befehle. hdparm -I dient übrigens nur zur Infoanzeige.

Noch ein Problem: Der MBR ist weg .. naja ich wusste noch ziemlich genau wieviel MB meine Partitionen hatten, daher konnte ich einfach einen neuen mit fdisk erzeugen, welcher genau die gleichen Partitionen anlegte. Nochmal kurz an- und abstecken, Schwupps waren sie wieder da. Die Bootpartition war natürlich schon Hopps, da sie ganz vorne lag und recht klein war :(
Gut, die war ja eh “gebackupt” und vom Backup aus längst auf das neue Gerät gespielt.

Also können wir jetzt den Luksheader zurück schreiben:

sudo cryptsetup luksHeaderRestore --header-backup-file <file> <device>

Nachdem dies geklappt hat, können wir das Luksdevice öffnen:

sudo cryptsetup luksOpen <device> bla

Soweit war mir das ja noch alles bekannt, aber natürlich wurde das LVM auf dem LUKS Laufwerk von pvscan und co. nun auch nicht mehr gefunden. Somit durfte ich mich in die ganze LVM Sache einlesen .. juhu…
Innerlich hatte ich ja gehofft, dass der Secure Erase so langsam ist, dass er den LVM Teil noch nicht erreicht hat.
Natürlich hab ich KEIN Backup der LVM Metadaten .. und ich weiß auch nur noch grob wieviel MB da was hatte.

Nach längerem googeln fand ich heraus, dass die meisten Distris unter /etc/lvm/backup und /etc/lvm/archive immer mal wieder Metadaten von LVMs speichern bzw. “backupen”. Natürlich überall an jedem PC (an dem die HDD mit dem LVM mal steckte) gesucht, nirgendwo auf Anhieb etwas gefunden.
An dem Zweitpc, der damals nach dem Ausfall der SSD (welche die HDD ersetzt hat zur Überbrückung) das LVM auf der HDD erzeugt hat fand ich in /etc/lvm/archive aber dann doch 2,3 Backupfiles der Metadaten des gesuchten LVMs. Leider fehlte in den Backupfiles ein logisches Volume, weil LVM wohl immer nur vor den Befehlen ein Backup anlegt (warum auch immer), weswegen ein Backup nach dem letzten Befehl (der das letzte logische Volume anlegte) fehlt. Wie diese Dateien aussehen sieht man z.B. hier.
Es gibt ja auch so einen Befehl, mit dem man angeblich diese Daten aus dem LVM extrahieren kann:

dd if=/dev/xyz bs=512 count=255 skip=1 of=/tmp/blubb.txt

Trotz richtiger Ausführung und korrekter Partitionen war bei mir da nur Datenmüll drin (auch in den Datenmüll war nirgends eine Konfig zu sehen). Geht das nur mit LVM1?.

Zum Glück konnte ich das letzte logische Volume von Hand in die Datei einfügen, die ID ist egal, sie muss nicht die originale sein. Die Extends konnte ich ausrechnen: “pe_count” des bzw. aller physikalischen Volume(s) (pv) – extent_count jedes logischen Volumes(lv) = extent_count des fehlenden logischen Volumes. Dabei ist die 0 von “”pv0″, 0” immer die extent_count Zahl des vorigen Volumes. Ich muss dazu sagen: Ich hatte aber nur ein physikalisches Volume im LVM drin, deswegen war es so einfach.

Also “recovern” wir jetzt das LVM:

Zuerst das physikalische Volume … wie das geht, sagt uns tldp.org:

sudo pvcreate --uuid "some_long_string" --restorefile blubb.txt <PhysicalVolume>

Hierbei muss die uuid aber in der Backupdatei blubb.txt (für das pv) vorkommen, sonst gibts Fehlermeldungen oder Abstürze*.

Jetzt ist die VolumeGroup (und damit die logischen Volumes) dran:

sudo vgcfgrestore -f blubb.txt VolGroup01

Auch hier wieder: VolGroup01 muss in der blubb.txt vorkommen, sonst gibt es Fehler oder Abstürze*.

Ein Wunder … es hat gepklappt :D
Jetzt noch einmal folgendes:

sudo pvscan
sudo vgscan
sudo vgchange -ay VolGroup01

Parititonen mounten:

sudo mount /dev/mapper/VolGroup01-bla1 /mnt/bla1
sudo mount /dev/mapper/VolGroup01-bla2 /mnt/bla2
...

Sobald sowas wie ein “Sie müssen den Dateisystemtyp angeben” kommt ist die Partition bzw. das Dateisystem auf dem logischen Volume hinüber .. eine der ersteren hatte der Secure Erase leider schon erwischt, der Rest war aber vollständig vorhanden. Ich konnte also die gewünschten Daten retten und rauskopieren.
Ob man das kaputte Dateisystem auf dem vorderen logischen Volume auch wiederherstellen könnte weiß ich nicht, mit extundelete hätte man bestimmt einige der Dateien wiederherstellen können, …, für mich war das aber erstmal nicht wichtig, die Daten, die ich wollte, waren ja da. Super! Das hätte ich so nicht erwartet. :)

Das hier soll nur ein kleiner Bericht sein, der keinerlei Anspruch auf Vollständigkeit und Korrektheit erhebt, ich wollte euch nur erzählen, wie meine Datenrettung in der Realität abgelaufen ist. Es ging hier nur um ein paar wenige Dateien, welche zwischen dem letzten Backup und dem Tag des versehentlichen Erases lagen. Bei dem Ausfall meiner SSD (den die HDD ersetzt hat), war dies nicht mehr möglich, was ärgerlich war, da das Backup weiter zurück lag, allerdings gab es damals keine wichtigen Daten welche nur auf der SSD lagen. Ein weitere Vorteil war auch, dass ein großer Teil der betroffenen Daten sowieso in der Dropbox lagen.

Daher ein abschließender Rat: immer regelmäßig ein Backup erstellen. Wenn ihr es schon regelmäßig macht, macht es in noch kürzeren Abständen (und benutzt sowas wie Dropbox).

Mir ist übrigens durchaus bewusst dass Ausdrücke wie “das LVM” totaler Schwachsinn sind, daher entschuldige ich mich gleich dafür, hat sich halt so eingebürgert ;)

*= Ich bin erstaunt das solche elementaren Tools einfach abstürzen sobald in den Backupdateien die PVs bzw. LVs nicht gefunden werden. Eigentlich sollte das nicht passieren.

Quellen:
softpanorama.org linuxjournal.com formann.de linux.about.com tldp.org techrepublic.com extundelete.sourceforge.net thomas-krenn.com linux.die.net linuxquestions.org linuxjournal.com

Kyocera FS-1020D unter Linux beschleunigen…

Jeder Besitzer eines Kyocera FS-1020D (und viele weitere) dürfte das Szenario kennen: Unter Windows druckt der Drucker super schnell, unter Linux mit dem offiziellen Treiber schnarch langsam, aber nicht unter allen Umständen, meist nur bei PDFs, selbst bei denen ohne Bilder.

Woran das genau liegt, weiß ich auch nicht, aber das Ubuntu Forum brachte mich auf den ljet4d Treiber. Diesen installiert und schwupps druckt der FS-1020D genauso schnell wie unter Windows. Minimale Änderungen bei Schattierungen habe ich bemerkt, insgesamt ist die Qualität aber auf gleichem Niveau wie mit dem original Treiber (Bilder habe ich nicht getestet, aber wer druckt schon S/W Bilder per Laser..).

Installation unter Archlinux ist denkbar einfach:

1.) Die foomatic Datenbank installieren

sudo pacman -S foomatic-db foomatic-filters foomatic-db-engine foomatic-db-nonfree

2.) Danach Cups neustarten

sudo rc.d restart cupsd

3.) Danach auf http://localhost:631 gehen und einen neuen Drucker hinzufügen, als Treiber folgendes wählen Kyocera -> Kyocera FS-1020D Foomatic/ljet4d. Unter Kyocera Mita findet ihr die offiziellen Treiber. Bitte nicht die falsche Kategorie wählen, es gibt “Kyocera” und “Kyocera Mita”.

Eine Übersicht der verfügbaren Treiber gibt es auf openprinting.org.

Für maximale Bildqualität sollte man Halftoning Algorithm: Well-Tampered Screening auswählen.

Edit(21.04.2012):
Ich nutze nun seit geraumer Zeit den Treiber hpijs-pcl5e, welcher meines Meinung nach genauso schnell ist wie der ljet4d, aber eine bessere Qualität liefert. Dieser Treiber stammt von HP, unter Archlinux muss man dafür hplip nachinstallieren.
Ich würde also eher den hpijs-pcl5e als den ljet4d nutzen, da letzterer doch manchmal nicht so schöne Graustufen/Schattierungen geliefert hat.

Neuer Dockstar Kernel für Debian (3.0.28)

Heute wurde ein neuer longterm Kernel freigegeben, es handelt sich um 3.0.28. Ihr findet ihn wie immer unter “Dockstar Kernel“. Dort gibt es die Installationsanleitung, Downloadlinks und md5sums usw.

Falls ihr von 2.6.32.x kommt, lesen bitte die Anmerkungen im 3.0.23 Kernel Post oder auf der Dockstar Kernel Seite.

Wie immer: Falls eure Dockstar brennt, kaputt geht, in die Luft fliegt oder sonstiges, übernehme ich keine Verantwortung dafür.

Danke an Jeff für seine Konfig und seine fantastische Arbeit mit der Dockstar. Besucht sein Forum, es ist die beste Anlaufstelle für Dockstarnutzer.

Neuer Dockstar Kernel für Debian (3.0.27)

Heute wurde ein neuer longterm Kernel freigegeben, es handelt sich um 3.0.27. Ihr findet ihn wie immer unter “Dockstar Kernel“. Dort gibt es die Installationsanleitung, Downloadlinks und md5sums usw.

Falls ihr von 2.6.32.x kommt, lesen bitte die Anmerkungen im 3.0.23 Kernel Post oder auf der Dockstar Kernel Seite.

Wie immer: Falls eure Dockstar brennt, kaputt geht, in die Luft fliegt oder sonstiges, übernehme ich keine Verantwortung dafür.

Danke an Jeff für seine Konfig und seine fantastische Arbeit mit der Dockstar. Besucht sein Forum, es ist die beste Anlaufstelle für Dockstarnutzer.