software-raid5 mit verschlüsselung, mount problem
Hallo Liste, habe hier ein ernstes problem: Ich bekomme mein raid5 nicht mehr gemountet. Alles lief vorher unter opensuse v10.2 normal. Dann habe ich den server hardwaremäßig umgebaut von amd athlon 2000 (32bit) nach amd athlon 3000 64bit. Anschließend noch opensuse v10.3 (x86_64) neu aufgespielt. Das raid wird erkannt, aber... wenn ich über yast versuche es einzuhängen mit verschlüsselung und mountpoint 1. versuch: ------------------------------------------------------- fehler verschlüsselung konnte nicht festgelegt werden. fehlercode des systems: -3016 möglicherweise wurde ein falsches passwort für die verschlüsselung angegeben. ------------------------------------------------------- beim 2. versuch funktionierts aber anscheinend! beim ausführen in yast kommt dann aber: ------------------------------------------------------- fehler bei der folgenden aktion ist ein fehler aufgetreten: /dev/md0 wird auf /local eingehängt systemfehlercode: -3003 mount -t auto -onoacl /dev/md0 /local: mount: you must specify the filesystem type ------------------------------------------------------- mit der hand auch versucht : mount -t xfs /dev/md0 /local kernel: xfs: bad magic number kernel: xfs: sb validate failed hier noch ein paar auszüge: workhorse:/home/abc # mdadm --detail /dev/md0 /dev/md0: Version : 01.00.03 Creation Time : Thu Feb 14 17:40:53 2008 Raid Level : raid5 Array Size : 976767488 (931.52 GiB 1000.21 GB) Used Dev Size : 976767488 (465.76 GiB 500.10 GB) Raid Devices : 3 Total Devices : 3 Preferred Minor: 0 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Thu Feb 21 13:15:10 2008 State : active Active Devices : 3 Working Devices : 3 Failed Devices : 0 Spare Devices : 0 Layout : left-symmetric Chunk Size : 128K Name : 0 UUID : dd2ead7a:d188590f:88e906c1:95f6ce6f Events : 8 Number Major Minor RaidDevice State 0 8 17 0 active sync /dev/sdb1 1 8 33 1 active sync /dev/sdc1 3 8 49 2 active sync /dev/sdd1 workhorse:/home/abc # cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md0 : active raid5 sdb1[0] sdd1[3] sdc1[1] 976767488 blocks super 1.0 level 5, 128k chunk, algorithm 2 [3/3] [UUU] bitmap: 0/466 pages [0KB], 512KB chunk unused devices: <none> Feb 24 17:36:11 workhorse kernel: RAID5 conf printout: Feb 24 17:36:11 workhorse kernel: --- rd:3 wd:3 Feb 24 17:36:11 workhorse kernel: disk 0, o:1, dev:sdb1 Feb 24 17:36:11 workhorse kernel: disk 1, o:1, dev:sdc1 Feb 24 17:36:11 workhorse kernel: disk 2, o:1, dev:sdd1 Feb 24 17:44:07 workhorse kernel: Filesystem "md0": Disabling barriers, not supported by the underlying device Feb 24 17:44:07 workhorse kernel: XFS mounting filesystem md0 Feb 24 17:44:08 workhorse kernel: XFS: Log inconsistent (didn't find previous header) Feb 24 17:44:08 workhorse kernel: XFS: failed to find log head Feb 24 17:44:08 workhorse kernel: XFS: log mount/recovery failed: error 5 Feb 24 17:44:08 workhorse kernel: XFS: log mount failed Weiß jetzt nicht mehr weiter. Ob mir jemand helfen kann? mfg thomas -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Sonntag, 24. Februar 2008 20:15:51 schrieb Thomas Lange:
Hallo Liste,
Hallo Thomas, Meine Tipp never change a winnig team, Hurra hilft nun auch nicht mehr. Die 500 GB auf dem Raid hast du nicht wirklich als Sicherung. Nein, nicht wirklich, sonst hättest du nicht gefragt. Den alten Server zusammen zustricken dann eine Sicherung und alles auf Anfang geht auch nicht, oder ?? War nur ne Idee Gruß Karl -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Sonntag, 24. Februar 2008 schrieb Karl Kehlenbrink:
Am Sonntag, 24. Februar 2008 20:15:51 schrieb Thomas Lange:
Hallo Liste,
Hallo Thomas,
Meine Tipp never change a winnig team, Hurra hilft nun auch nicht mehr.
Weiß ich, hilft aber ja doch nichts. Machmal muß man eben aufrüsten. Leider hat sich das handling von verschlüsselten partitionen irgendwie geändert. Vorher gab's die cryptotab, jetzt die crypttab. Auch das raid hat sich von v.0.90.3 nach v.1.00.3 geändert. Mir würde es vielleicht schon weiterhelfen, wenn mir jemand sagen könnte, wo ich eher suchen müßte, bei der verschlüsselung oder beim raid!? Auch möchte ich nicht alles über yast machen. Hab alle seiten von man 'mdadm' schon gelesen, komme damit aber auch nicht wirklich klar. Mit einem live-system 10.2 habe ich's auch schon probiert. Immer die gleiche fehlerausgabe (-3016 und -3003). Unter google nichts neues. Codes haben irgendwie mit dem mounten zu tun. Weiß noch nicht einmal, ob die daten vorhanden/ beschädigt sind oder nicht. Echt mist!
Die 500 GB auf dem Raid hast du nicht wirklich als Sicherung. Nein, nicht wirklich, sonst hättest du nicht gefragt.
Nein, kein backup...aber wer macht auch schon ein backup von 1 TByte im privaten bereich?
Den alten Server zusammen zustricken dann eine Sicherung und alles auf Anfang geht auch nicht, oder ??
Danke für die idee. Wäre zwar sehr viel aufwand, vielleicht aber noch der berühmte strohhalm.
War nur ne Idee
Gruß Karl
mfg thomas -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Weiß ich, hilft aber ja doch nichts. Machmal muß man eben aufrüsten. Leider hat sich das handling von verschlüsselten partitionen irgendwie geändert. Vorher gab's die cryptotab, jetzt die crypttab. Auch das raid hat sich von v.0.90.3 nach v.1.00.3 geändert. Mir würde es vielleicht schon weiterhelfen, wenn mir jemand sagen könnte, wo ich eher suchen müßte, bei der verschlüsselung oder beim raid!? Auch möchte ich nicht alles über yast machen. Hab alle seiten von man 'mdadm' schon gelesen, komme damit aber auch nicht wirklich klar. Mit einem live-system 10.2 habe ich's auch schon probiert. Immer die gleiche fehlerausgabe (-3016 und -3003). Unter google nichts neues. Codes haben irgendwie mit dem mounten zu tun. Weiß noch nicht einmal, ob die daten vorhanden/ beschädigt sind oder nicht. Echt mist!
Die 500 GB auf dem Raid hast du nicht wirklich als Sicherung. Nein, nicht wirklich, sonst hättest du nicht gefragt.
wenn mich nicht alles täuscht mußt Du eine 10.2 installieren das Filesystem entschlüsseln und dann die 10.3 "daufpappen" ? Dann geht die Verschlüsselung wieder ;). Glaube steht irgendwo im readme ;). -- mit freundlichen Grüßen / best Regards Günther J. Niederwimmer -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On Mon 25 Feb 2008 20:41:45 NZDT +1300, Thomas Lange wrote:
Weiß ich, hilft aber ja doch nichts. Machmal muß man eben aufrüsten. Leider hat sich das handling von verschlüsselten partitionen irgendwie geändert. Vorher gab's die cryptotab, jetzt die crypttab.
Genau. Statt cryptoloop ist's jetzt dm-crypt. Wäre aber echt faul, wenn man nach dem Aufrüsten die alten Verschlüsselten Partitionen nicht mehr ansprechen könnte. So dumm sollte ein Linux-Lieferant nicht sein dürfen. Bei mir war es so, daß die 10.3 das entsprechende Modul nicht automatisch lädt. modprobe cryptoloop Wenn Du den Modulnamen zur Variablen MODULES_LOADED_ON_BOOT in /etc/sysconfig/kernel hinzufügst, wird das Modul beim booten geladen.
Auch das raid hat sich von v.0.90.3 nach v.1.00.3 geändert. Mir würde es vielleicht schon weiterhelfen, wenn mir jemand sagen könnte, wo ich eher suchen müßte, bei der verschlüsselung oder beim raid!?
Dein RAID läuft, das zeigt /proc/mdstat an.
Nein, kein backup...aber wer macht auch schon ein backup von 1 TByte im privaten bereich?
Lästig, aber nötig. Es gibt jetzt 1TB SATA Platten. Erschwinglich für wichtige Daten, aber nicht billig. Oder Du sagst, zu teuer, dann waren die Daten auch nicht so wichtig... ;) Dein RAID schützt Dich nur, wenn plötzlich eine Platte abraucht. Es schützt nicht gegen kaputten Speicher und davon hervorgerufene Harakiri Kernels (sh.. in, sh.. out), den Faktor zwischen Tastatur und Stuhl, oder das Netzteil, das morgen peng macht und alle Elektronik brät. Aber nur Du kannst entscheiden, was Dir Deine Daten wirklich wert sind. Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Montag, 25. Februar 2008 schrieb Volker Kuhlmann:
On Mon 25 Feb 2008 20:41:45 NZDT +1300, Thomas Lange wrote:
Weiß ich, hilft aber ja doch nichts. Machmal muß man eben aufrüsten. Leider hat sich das handling von verschlüsselten partitionen irgendwie geändert. Vorher gab's die cryptotab, jetzt die crypttab.
Genau. Statt cryptoloop ist's jetzt dm-crypt. Wäre aber echt faul, wenn man nach dem Aufrüsten die alten Verschlüsselten Partitionen nicht mehr ansprechen könnte. So dumm sollte ein Linux-Lieferant nicht sein dürfen. Bei mir war es so, daß die 10.3 das entsprechende Modul nicht automatisch lädt.
modprobe cryptoloop
Hab' ich gemacht. Hab' auch eine neue cryptotab angelegt. Beim hochfahren wird jetzt auch nach dem passwort gefragt, aber es wird nicht angenommen. War vorher auch schon. Später in yast ist das md als 'c' unter 'F' markiert und der mountpoint ist auch schon eingetragen. Früher habe ich dann immer eine einstellung unter 'optionen' hin- und hergestellt, dann passwortabfrage und gemounted und dann war alles klar. Jetzt bekomme ich leider die fehlermeldung: ---------------------- yast got signal 11 at ypc file storage.ypc.3672 /sbin/yast2: line 386: 5916 segmentation fault $ybindir/y2base $module "$e" selected_gui $y2_geometry $y2qt_args ---------------------- Scheint ein fehler von yast unter x zu sein, denn die meldung bekomme ich bei yast in runlevel 3 nicht. Alles läuft durch, aber es wird trotzdem nichts gemounted (immer noch das '*' hinter dem mountpoint). Was ist das bloß?
Wenn Du den Modulnamen zur Variablen MODULES_LOADED_ON_BOOT in /etc/sysconfig/kernel hinzufügst, wird das Modul beim booten geladen.
Auch das raid hat sich von v.0.90.3 nach v.1.00.3 geändert. Mir würde es vielleicht schon weiterhelfen, wenn mir jemand sagen könnte, wo ich eher suchen müßte, bei der verschlüsselung oder beim raid!?
Dein RAID läuft, das zeigt /proc/mdstat an.
Nein, kein backup...aber wer macht auch schon ein backup von 1 TByte im privaten bereich?
Lästig, aber nötig. Es gibt jetzt 1TB SATA Platten. Erschwinglich für wichtige Daten, aber nicht billig. Oder Du sagst, zu teuer, dann waren die Daten auch nicht so wichtig... ;)
Dein RAID schützt Dich nur, wenn plötzlich eine Platte abraucht. Es schützt nicht gegen kaputten Speicher und davon hervorgerufene Harakiri Kernels (sh.. in, sh.. out), den Faktor zwischen Tastatur und Stuhl, oder das Netzteil, das morgen peng macht und alle Elektronik brät.
Aber nur Du kannst entscheiden, was Dir Deine Daten wirklich wert sind.
wohl war.
Volker
-- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
mfg thomas -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On Tue 26 Feb 2008 00:25:50 NZDT +1300, Thomas Lange wrote:
Hab' ich gemacht. Hab' auch eine neue cryptotab angelegt. Beim hochfahren wird jetzt auch nach dem passwort gefragt, aber es wird nicht angenommen.
yast got signal 11 at ypc file storage.ypc.3672 /sbin/yast2: line 386: 5916 segmentation fault $ybindir/y2base $module "$e" selected_gui $y2_geometry $y2qt_args
Laß die Dekoration doch erst mal links liegen und gehe den Kern der Sache an. D.h. System booten, cryptoloop laden, dann von Hand mounten.
Dein RAID läuft, das zeigt /proc/mdstat an.
Das glaube ich nur teilweise, weil ich noch folgende fehlermeldung erhalte:
Feb 26 12:05:10 workhorse kernel: XFS mounting filesystem md0 Feb 26 12:05:10 workhorse kernel: XFS: Log inconsistent (didn't find previous header) Feb 26 12:05:10 workhorse kernel: XFS: failed to find log head Feb 26 12:05:10 workhorse kernel: XFS: log mount/recovery failed: error 5 Feb 26 12:05:10 workhorse kernel: XFS: log mount failed
Diese Meldungen sind alle von xfs! Es hat Schwierigkeiten, ein Dateisystem auf md0 zu finden. Möglichkeiten: Das Dateisystem ist kaputt. Die Entschlüsselung geht nicht (sieht dann für xfs wie Zahlensalat aus). Die Auszüge in Deiner ersten Email zeigen ein funktionierendes RAID ohne einen Hinweis auf Fehler. Ich würde mich auf die Verschlüsselung konzentrieren (und schreib bloß nix an xfs vorbei auf md0). Wenn Du mit dd ein paar Blöcke von md0 lesen kannst, läuft das RAID. Ich würde hier ansetzen: Welche Verschlüsselungsparameter wurden für losetup auf 10.2 genau verwendet? Da können etliche mount Optionen in der fstab gestanden haben. Man könnte mit losetup --read-only probieren, und dann sehen, ob das Resultat wie ein xfs-Dateisystem aussieht. Ist die Verschlüsselung auf dem md0 schon vor 10.2 angelegt worden? Da war was dabei was heute von SUSE nicht mehr direkt unterstützt wird. Die Module kann man sich noch beschaffen, aber ich weiß die Einzelheiten nicht mehr. Es ist zwingend erforderlich, genau dieselben Parameter für die Verschlüsselung zu nehmen wie bei 10.2. Sonst ist das ungefähr so, als hätte man das Paßwort vergessen. Hast Du Dein altes /etc/ von der 10.2 noch? Davon hat man immer ein Backup. Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Volker, Am Freitag, 29. Februar 2008 schrieb Volker Kuhlmann:
On Tue 26 Feb 2008 00:25:50 NZDT +1300, Thomas Lange wrote:
Hab' ich gemacht. Hab' auch eine neue cryptotab angelegt. Beim hochfahren wird jetzt auch nach dem passwort gefragt, aber es wird nicht angenommen.
yast got signal 11 at ypc file storage.ypc.3672 /sbin/yast2: line 386: 5916 segmentation fault $ybindir/y2base $module "$e" selected_gui $y2_geometry $y2qt_args
Laß die Dekoration doch erst mal links liegen und gehe den Kern der Sache an. D.h. System booten, cryptoloop laden, dann von Hand mounten.
Zum handmounten: soweit ich weiß muß ich einen eintrag in die fstab schreiben, wenn man ein loop einhängen will, das nicht beim hochfahren gemounted werden soll. Vorher hatte ich ja die cryptotab mit eintrag.
Dein RAID läuft, das zeigt /proc/mdstat an.
Das glaube ich nur teilweise, weil ich noch folgende fehlermeldung erhalte:
Feb 26 12:05:10 workhorse kernel: XFS mounting filesystem md0 Feb 26 12:05:10 workhorse kernel: XFS: Log inconsistent (didn't find previous header) Feb 26 12:05:10 workhorse kernel: XFS: failed to find log head Feb 26 12:05:10 workhorse kernel: XFS: log mount/recovery failed: error 5 Feb 26 12:05:10 workhorse kernel: XFS: log mount failed
Diese Meldungen sind alle von xfs! Es hat Schwierigkeiten, ein Dateisystem auf md0 zu finden. Möglichkeiten: Das Dateisystem ist kaputt. Die Entschlüsselung geht nicht (sieht dann für xfs wie Zahlensalat aus). Die Auszüge in Deiner ersten Email zeigen ein funktionierendes RAID ohne einen Hinweis auf Fehler. Ich würde mich auf die Verschlüsselung konzentrieren (und schreib bloß nix an xfs vorbei auf md0). Wenn Du mit dd ein paar Blöcke von md0 lesen kannst, läuft das RAID.
Mit dd kenne ich mich nicht aus; hab' mal dd if=/dev/md0 eingegeben, kam jede menge datensalat auf den screen.
Ich würde hier ansetzen:
Welche Verschlüsselungsparameter wurden für losetup auf 10.2 genau verwendet? Da können etliche mount Optionen in der fstab gestanden haben. Man könnte mit losetup --read-only probieren, und dann sehen, ob das Resultat wie ein xfs-Dateisystem aussieht.
Kann ich nicht genau sagen, weil mit yast angelegt. Soweit ich weiß, hab' ich an den standard parametern in den yast dialogen nichts verändert. Allerdings trat auch seinerzeit schon ein problem auf: beim hochfahren kam zwar immer die passwortabfrage, es wurde aber nichts gemounted. Das mußte ich immer händisch über yast machen, indem ich immer in den fstab-optionen 'keine zugriffszeit' an oder ausschaltete. Dann wurde das raid eingehängt, aber nie beim hochfahren.
Ist die Verschlüsselung auf dem md0 schon vor 10.2 angelegt worden? Da war was dabei was heute von SUSE nicht mehr direkt unterstützt wird. Die Module kann man sich noch beschaffen, aber ich weiß die Einzelheiten nicht mehr.
Nein, das war alles neu: platten neu, 10.2 (i586) ganz neu.
Es ist zwingend erforderlich, genau dieselben Parameter für die Verschlüsselung zu nehmen wie bei 10.2. Sonst ist das ungefähr so, als hätte man das Paßwort vergessen. Hast Du Dein altes /etc/ von der 10.2 noch? Davon hat man immer ein Backup.
Mein altes /etc/ hab' ich leider nicht mehr. Durch den hardwareumbau lief mein 10.2 (i586) nicht mehr hoch, so hab' ich dann gleich 10.3 auf die gleiche platte als neuinstallation draufgehauen (update geht ja nicht).
Volker
-- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
mfg thomas -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On Sat 01 Mar 2008 23:46:01 NZDT +1300, Thomas Lange wrote: Hallo Thomas, Weiß nicht, wie Deine Chancen stehen, aber ich versuche mal noch ein paar Tips.
Zum handmounten: soweit ich weiß muß ich einen eintrag in die fstab schreiben, wenn man ein loop einhängen will, das nicht beim hochfahren gemounted werden soll. Vorher hatte ich ja die cryptotab mit eintrag.
/etc/fstab existiert zu einem guten Teil für Deine Bequemlichkeit. Mit Ausnahme der letzten beiden Zahlenspalten sind das alles Angaben für den mount Befehl. Die kannst Du auch alle von Hand eingeben. Ein verschlüsseltes RAID Dateisystem zu mounten läuft in 3 Stufen ab, jede vorherige ist Voraussetzung für die nächste: RAID, verschlüsseln, mounten. RAID: In /proc/mdstat den Status nachsehen, die neu erzeugte "Platte" für den Anwender ist in /dev/mdX. Das geht bei Dir. Die kannst Du Dir als Binärsalat ansehen. Nebenbei, Binärsalat nicht in die Shell ausgeben, in eine root Shell schon gar nicht. Besser geht das zB mit od -tc < /dev/md0 | less Das gibt Dir lesbare Zeichen wenn sichtbar, sonst Oktalmüll. Aber es ist erkennbar (und gibt keine Befehle per ANSI-Escape-Sequenzen an die Shell aus). Verschlüsseln ist in Linux über das loop-Gerät implementiert. Loop verwandelt eine Datei in ein Gerät - man kann nur Geräte mounten, aber mit loop eben auch zB ein ISO9660 Dateisystem, welches man von CD auf Platte kopiert hat. Für die Verschlüsselung gibts Du loop eben /dev/md0, das ist zwar schon ein Gerät, aber wir wollen hier die Verschlüsselungsfunktion von loop nutzen. Das Ergebnis von loop ist immer(!) eins der Geräte /dev/loopN. Eingestellt wird das mit losetup (bitte man losetup lesen). Mounten mit mount /dev/loopN /mountpoint. Der mountpoint ist ein leeres Verzeichnis Deiner Wahl, zB /media/backupdisk oder /home. Zum Testen kannst Du irgendwas nehmen, /mnt ist nicht so schlecht. Hier gibt es jetzt eine Abkürzung: mount -oloop sucht automatisch ein noch unbenutztes /dev/loopN, ruft losetup auf (mit den Angaben, die in fstab hinter encryption= stehen), und mountet das Dateisystem mit den restlichen Angaben in fstab. Zum Testen alles per Hand eingeben, bei xfs ist erst mal nur mount -txfs erforderlich. losetup kann jetzt auch nach einem unbenutzten /dev/loopN suchen. Du mußt unbedingt herausfinden, ob bei Dir die Verschlüsselung nicht funktioniert oder das Dateisystem kaputt ist!!!!!! Reparaturversuche am Dateisystem ohne funktionierende Verschlüsselung machen Dir ganz sicher alles richtig kaputt. Zu der funktionierenden Verschlüsselung gehört auch ein richtiges Paßwort! Von hier an bitte alles als root. (KDE konsole starten, Maus unten links auf das Icon klicken und halten, vom Popup Root Shell auswählen.) losetup -a Zeigt der derzeigt angelegten loop Geräte an. losetup -d /dev/loopN Löst die loop-Verbindung zwischen loopN und der Datei(Gerät). Daten werden keine gelöscht. Versuchen wir das alles erst mal read-only: modprobe cryptoloop losetup -fsrv -e twofish256 /dev/md0 Wenn Du hier ioctl: LOOP_SET_STATUS: Invalid argument siehst, ist cryptoloop nicht geladen. Als Ausgabe erhälst Du das tatsächlich verwendete loop Gerät, zB /dev/loop5. Hinter -e gibst Du die auf md0 verwendete Verschlüsselung an. Du darfst ruhig experimentieren. Wenn es völlig falsch ist, bekommst Du einen Fehler, oder vielleicht auch rein gar nichts. Wichtig: falsche Paßwörter können hier nicht erkannt werden, aus der entschlüsselung kommt dann eben nur Datensalat. Von losetup bekommst Du dann nie einen Fehler, aber eben von mount. Wenn Du die default-Verschlüsselung von openSUSE 10.2 wissen mußt, hier fragen, oder auf einem 10.2 System mit yast auf einem USB-Flash-Ding anlegen und mit mount oder losetup -a nachsehen. Wenn Du nicht den Default genommen hast, bist Du auf Dein Gedächtnis und Probieren angewiesen. Wenn Du keinen Fehler bekommst, siehst Du nach, ob Du jetzt in /dev/loopN tatsächlich ein akzeptables XFS Dateisystem hast. Das machst Du wieder mit zB od -tc
beim hochfahren kam zwar immer die passwortabfrage, es wurde aber nichts gemounted. Das mußte ich immer händisch über yast machen, indem ich immer in den fstab-optionen 'keine zugriffszeit' an oder ausschaltete. Dann wurde das raid eingehängt, aber nie beim hochfahren.
Das hört sich nach atime an, dann mußt Du vielleicht noch mount -o noatime /dev/loopN /mnt angeben (oder -o atime). Wenn Du hier einen Fehler bekommst, gibt es entweder noch ein anderes Problem, oder das Dateisystem ist beschädigt. Hier darfst Du dann Reparaturversuche starten. Das Dateisystem ist hier auf /dev/loopN, und Du mußt erst noch losetup -d aufrufen und dann wieder neu mit losetup anfangen, dieses Mal ohne -r für read-only.
Mein altes /etc/ hab' ich leider nicht mehr. Durch den hardwareumbau lief mein 10.2 (i586) nicht mehr hoch, so hab' ich dann gleich 10.3 auf die gleiche platte als neuinstallation draufgehauen (update geht ja nicht).
Haben sich durch den Hardwareumbau die Plattengeräte /dev/sdX) verschoben? Wie beschrieben funktioniert es bei mir auf einer externen Platte von 10.2 auf 10.3, allerdings ohne RAID, aber das ist für die Verschlüsselung ohne Belang. Wenn Du mit od direkt auf md0 nachsiehst, solltest Du nur Zufallszahlen sehen, Regelmäßigkeiten dürfen keine auftreten. Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Volker, vielen dank für deine sehr ausführlichen erklärungen (zeitaufwand); mir wird das problem dadurch sehr viel klarer. Am Samstag, 1. März 2008 schrieb Volker Kuhlmann:
On Sat 01 Mar 2008 23:46:01 NZDT +1300, Thomas Lange wrote:
Hallo Thomas,
Weiß nicht, wie Deine Chancen stehen, aber ich versuche mal noch ein paar Tips.
Zum handmounten: soweit ich weiß muß ich einen eintrag in die fstab schreiben, wenn man ein loop einhängen will, das nicht beim hochfahren gemounted werden soll. Vorher hatte ich ja die cryptotab mit eintrag.
/etc/fstab existiert zu einem guten Teil für Deine Bequemlichkeit. Mit Ausnahme der letzten beiden Zahlenspalten sind das alles Angaben für den mount Befehl. Die kannst Du auch alle von Hand eingeben.
Dachte, das da was drinstehen muß sonst geht's gar nicht.
Ein verschlüsseltes RAID Dateisystem zu mounten läuft in 3 Stufen ab, jede vorherige ist Voraussetzung für die nächste: RAID, verschlüsseln, mounten.
RAID: In /proc/mdstat den Status nachsehen, die neu erzeugte "Platte" für den Anwender ist in /dev/mdX. Das geht bei Dir. Die kannst Du Dir als Binärsalat ansehen.
Ja, es läuft wirklich, allerdings wird mein raid nicht gleich beim booten gestartet, sondern ich muß das selbst tun im moment mit: mdadm --auto-detect
Nebenbei, Binärsalat nicht in die Shell ausgeben, in eine root Shell schon gar nicht. Besser geht das zB mit
od -tc < /dev/md0 | less
Ja, ist ein sicherheitsrisiko, sehe ich ein.
Das gibt Dir lesbare Zeichen wenn sichtbar, sonst Oktalmüll. Aber es ist erkennbar (und gibt keine Befehle per ANSI-Escape-Sequenzen an die Shell aus).
Verschlüsseln ist in Linux über das loop-Gerät implementiert. Loop verwandelt eine Datei in ein Gerät - man kann nur Geräte mounten, aber mit loop eben auch zB ein ISO9660 Dateisystem, welches man von CD auf Platte kopiert hat. Für die Verschlüsselung gibts Du loop eben /dev/md0, das ist zwar schon ein Gerät, aber wir wollen hier die Verschlüsselungsfunktion von loop nutzen. Das Ergebnis von loop ist immer(!) eins der Geräte /dev/loopN. Eingestellt wird das mit losetup (bitte man losetup lesen). Mounten mit mount /dev/loopN /mountpoint. Der
Hab' ich mitlerweile gelesen, ebenso man xfs_repair/ xfs_check.
mountpoint ist ein leeres Verzeichnis Deiner Wahl, zB /media/backupdisk oder /home. Zum Testen kannst Du irgendwas nehmen, /mnt ist nicht so schlecht. Hier gibt es jetzt eine Abkürzung: mount -oloop sucht automatisch ein noch unbenutztes /dev/loopN, ruft losetup auf (mit den Angaben, die in fstab hinter encryption= stehen), und mountet das Dateisystem mit den restlichen Angaben in fstab. Zum Testen alles per Hand eingeben, bei xfs ist erst mal nur mount -txfs erforderlich. losetup kann jetzt auch nach einem unbenutzten /dev/loopN suchen.
Du mußt unbedingt herausfinden, ob bei Dir die Verschlüsselung nicht funktioniert oder das Dateisystem kaputt ist!!!!!! Reparaturversuche am Dateisystem ohne funktionierende Verschlüsselung machen Dir ganz sicher alles richtig kaputt. Zu der funktionierenden Verschlüsselung gehört auch ein richtiges Paßwort!
Das passwort ist 100% korrekt, habe mich bei meinem sohn (kennt es auch) nochmals rück-versichert.
Von hier an bitte alles als root. (KDE konsole starten, Maus unten links auf das Icon klicken und halten, vom Popup Root Shell auswählen.)
losetup -a Zeigt der derzeigt angelegten loop Geräte an.
bei mir erstmal keine ausgabe.
losetup -d /dev/loopN Löst die loop-Verbindung zwischen loopN und der Datei(Gerät). Daten werden keine gelöscht.
Versuchen wir das alles erst mal read-only:
modprobe cryptoloop losetup -fsrv -e twofish256 /dev/md0
ergibt bei mir nach pw-abfrage und losetup -a dann: workhorse:~ # losetup -a /dev/loop0: [000f]:4433 (/dev/md0), encryption twofish (type 18), key length 32 Keine fehlermeldungen!
Wenn Du hier ioctl: LOOP_SET_STATUS: Invalid argument siehst, ist cryptoloop nicht geladen. Als Ausgabe erhälst Du das tatsächlich verwendete loop Gerät, zB /dev/loop5.
Hinter -e gibst Du die auf md0 verwendete Verschlüsselung an. Du darfst ruhig experimentieren. Wenn es völlig falsch ist, bekommst Du einen Fehler, oder vielleicht auch rein gar nichts. Wichtig: falsche Paßwörter können hier nicht erkannt werden, aus der entschlüsselung kommt dann eben nur Datensalat. Von losetup bekommst Du dann nie einen Fehler, aber eben von mount. Wenn Du die default-Verschlüsselung von openSUSE 10.2 wissen mußt, hier fragen, oder auf einem 10.2 System mit yast auf einem USB-Flash-Ding anlegen und mit mount oder losetup -a nachsehen. Wenn Du nicht den Default genommen hast, bist Du auf Dein Gedächtnis und Probieren angewiesen.
Wenn Du keinen Fehler bekommst, siehst Du nach, ob Du jetzt in /dev/loopN tatsächlich ein akzeptables XFS Dateisystem hast. Das machst Du wieder mit zB
od -tc
verschlüsselung und passwort scheinen korrekt zu sein. Ich sehe folgendes: 0000000 X F S B \0 \0 020 \0 \0 \0 \0 \0 016 216 022 300 0000020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 usw
Wie erkennst Du jetzt ein XFS Dateisystem? ;) Du vergleichst mit einem bekannten guten XFS.
Das legst Du Dir schnell in einer leeren 4GB großen Datei, die kein Platz auf der Platte beansprucht (das erkläre ich hier jetzt nicht, Tip sparse).
dd bs=4096 seek=1000000 if=/dev/zero of=/tmp/dateisystem mkfs -txfs /tmp/dateisystem
Die angelegte Datei einfach löschen, wenn Du fertig bist. Ansehen mit
od -tc
Als erste Zeile siehst Du sowas wie:
0000000 X F S B \0 \0 020 \0 \0 \0 \0 \0 \0 017 B @
Das 'XFS' ist eine Markierung. Die restlichen Zeilen sollten ähnlich aussehen. Wenn Du die siehst, darfst Du mounten:
mount /dev/loopN /mnt
beim hochfahren kam zwar immer die passwortabfrage, es wurde aber nichts gemounted. Das mußte ich immer händisch über yast machen, indem ich immer in den fstab-optionen 'keine zugriffszeit' an oder ausschaltete. Dann wurde das raid eingehängt, aber nie beim hochfahren.
Das hört sich nach atime an, dann mußt Du vielleicht noch
mount -o noatime /dev/loopN /mnt
angeben (oder -o atime). Wenn Du hier einen Fehler bekommst, gibt es entweder noch ein anderes Problem, oder das Dateisystem ist beschädigt. Hier darfst Du dann Reparaturversuche starten. Das Dateisystem ist hier auf /dev/loopN, und Du mußt erst noch losetup -d aufrufen und dann wieder neu mit losetup anfangen, dieses Mal ohne -r für read-only.
Mein altes /etc/ hab' ich leider nicht mehr. Durch den hardwareumbau lief mein 10.2 (i586) nicht mehr hoch, so hab' ich dann gleich 10.3 auf die gleiche platte als neuinstallation draufgehauen (update geht ja nicht).
Haben sich durch den Hardwareumbau die Plattengeräte /dev/sdX) verschoben?
Kann ich dir leider nicht sagen. Vorher hing alles an einem pci-sata-raid controller (4xsata, ohne raid activation betrieben). Jetzt direkt am mainboard, weil dort 4 sata-anschlüsse sind (2x2raid controller, aber ohne raid in betrieb). Nur immer software raid5.
Wie beschrieben funktioniert es bei mir auf einer externen Platte von 10.2 auf 10.3, allerdings ohne RAID, aber das ist für die Verschlüsselung ohne Belang. Wenn Du mit od direkt auf md0 nachsiehst, solltest Du nur Zufallszahlen sehen, Regelmäßigkeiten dürfen keine auftreten.
Volker
-- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
Hier noch ein paar auszüge vom screen, vielleicht sagt dir das mehr als mir: nach mount -o atime /dev/loop0 /mnt: oder nach mount -o noatime /dev/loop0 /mnt: fehlermeldung: xfs mounting filesystem loop0 xfs: failed to read root inode ein xfs_check /dev/loop0 gibt: xfs_check: out of memory (steht auch in der man page -> wg. großes dateisystem) ein xfs_repair -n /dev/loop0 läuft los und hält nach ca. 20 sec an mit problem with directory contents in inode 4140128138 would have cleared inode 4140128138 - agno = 31 No modify flag set, skipping phase 5 Inode allocation btrees are too corrupted, skipping phases 6 and 7 No modify flag set, skipping filesystem flush and exiting. Jede menge datein nach lost&found verschoben. Kann aber auch einträge meiner dateien sehen. Das sieht irgendwie nach sehr kaputt aus. meine drei hd's habe ich auch einzeln gecheckt: workhorse:~ # xfs_check /dev/sdb1 xfs_check: unexpected XFS SB magic number 0x9ea7f5c7 /usr/sbin/xfs_check: line 28: 5395 Floating point exceptionxfs_db$DBOPTS -i -p xfs_check -c "check$OPTS" $1 workhorse:~ # xfs_check /dev/sdc1 XFS: Log inconsistent or not a log (last==0, first!=1) XFS: empty log check failed ERROR: cannot find log head/tail, run xfs_repair workhorse:~ # xfs_check /dev/sdd1 xfs_check: unexpected XFS SB magic number 0xc6e1a685 /usr/sbin/xfs_check: line 28: 5399 Floating point exceptionxfs_db$DBOPTS -i -p xfs_check -c "check$OPTS" $1 Mit welchen optionen schaffe ich es bei xfs_repair einen kompletten durchlauf oder wie kann ich da noch was retten? Oder gibt's irgendwelche anderen rettungsmöglichkeiten? Bin ziemlich am ende mt meinem 'latain'. mfg thomas -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On Mon 03 Mar 2008 00:37:24 NZDT +1300, Thomas Lange wrote:
Ja, es läuft wirklich, allerdings wird mein raid nicht gleich beim booten gestartet, sondern ich muß das selbst tun im moment mit:
mdadm --auto-detect
Sowas in der Art wird beim booten einmal von einem Skript ausgeführt, aber nur, wenn das Skript auch eingeschaltet ist. Möglicherweise ist das nicht passiert, weil Du auf diesem System selbst mit yast kein RAID eingerichtet hast, sondern die Platten hinterher reingesteckt hast? Wie dem auch sei, Skript einschalten: chkconfig -a boot.md ausschalten chkconfig -d boot.md
ergibt bei mir nach pw-abfrage und losetup -a dann: workhorse:~ # losetup -a /dev/loop0: [000f]:4433 (/dev/md0), encryption twofish (type 18), key length 32 Keine fehlermeldungen!
Keine Fehlermeldungen ist notwendig, aber nicht hinreichend. Ein falsches Paßwort gibt auch keine Fehlermeldung.
verschlüsselung und passwort scheinen korrekt zu sein. Ich sehe folgendes:
0000000 X F S B \0 \0 020 \0 \0 \0 \0 \0 016 216 022 300 0000020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
Das sieht doch schon mal gut aus.
Haben sich durch den Hardwareumbau die Plattengeräte /dev/sdX) verschoben?
Kann ich dir leider nicht sagen. Vorher hing alles an einem pci-sata-raid controller (4xsata, ohne raid activation betrieben). Jetzt direkt am mainboard, weil dort 4 sata-anschlüsse sind (2x2raid controller, aber ohne raid in betrieb). Nur immer software raid5.
Es hängt davon ab, wie robust die Plattenerkennung ist, um die Teile wieder zusammenzusetzen. Angenommen, Du tauschst die Plattenstecker auf dem Brett mal alle gegeneinander aus. Würde die /dev/md0 noch richtig, und zuverlässig - nicht zufällig(!), hochfahren? Vielleicht weiß jemand anders die Antwort.
ein xfs_check /dev/loop0 gibt: xfs_check: out of memory (steht auch in der man page -> wg. großes dateisystem)
Ja, XFS ist dafür bekannt. Da hilft nur mehr Speicher.
ein xfs_repair -n /dev/loop0 läuft los und hält nach ca. 20 sec an mit
problem with directory contents in inode 4140128138 would have cleared inode 4140128138 - agno = 31 No modify flag set, skipping phase 5 Inode allocation btrees are too corrupted, skipping phases 6 and 7 No modify flag set, skipping filesystem flush and exiting.
Jede menge datein nach lost&found verschoben. Kann aber auch einträge meiner dateien sehen.
Das sieht irgendwie nach sehr kaputt aus.
Ja, leider. Wenn diese Programme etwas wiedererkennbares finden, dann funktioniert die Entschlüsselung.
meine drei hd's habe ich auch einzeln gecheckt:
Autsch, damit wäre ich SEHR vorsichtig, jeder Schreibvorgang sägt ein Stück vom Ast ab. Bei RAID5 ist jede der 3 Platten anders. Bei RAID1 kannst Du das zur Not machen, da sollten die Platten den gleichen Inhalt haben und Du kannst von der einen holen was auf der anderen kaputt ist.
workhorse:~ # xfs_check /dev/sdb1 xfs_check: unexpected XFS SB magic number 0x9ea7f5c7 /usr/sbin/xfs_check: line 28: 5395 Floating point exceptionxfs_db$DBOPTS -i -p xfs_check -c "check$OPTS" $1
workhorse:~ # xfs_check /dev/sdc1 XFS: Log inconsistent or not a log (last==0, first!=1) XFS: empty log check failed ERROR: cannot find log head/tail, run xfs_repair
workhorse:~ # xfs_check /dev/sdd1 xfs_check: unexpected XFS SB magic number 0xc6e1a685 /usr/sbin/xfs_check: line 28: 5399 Floating point exceptionxfs_db$DBOPTS -i -p xfs_check -c "check$OPTS" $1
Guter Gegentest, ob die Entschlüsselung funktioniert. Bei Binärsalat gibt xfs_check in 2 von 3 Fällen nicht nur eine Fehlermeldung, sondern gleich ganz den Löffel ab.
Mit welchen optionen schaffe ich es bei xfs_repair einen kompletten durchlauf oder wie kann ich da noch was retten? Oder gibt's irgendwelche anderen rettungsmöglichkeiten?
Ich habe mit XFS keine Erfahrung. Poste ruhig mit neuem Subject spezifisch auf XFS.Ich kann hier nicht weiter helfen. Das "No modify flag set" sieht mir danach aus, als könnte /dev/loop0 noch read-only laufen, da können dann natürlich keine Reparaturen durchgeführt werden und das Programm bricht ab. Viel Glück, Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo zusammen, Am Montag, den 03.03.2008, 18:27 +1300 schrieb Volker Kuhlmann:
On Mon 03 Mar 2008 00:37:24 NZDT +1300, Thomas Lange wrote:
verschlüsselung und passwort scheinen korrekt zu sein. Ich sehe folgendes:
0000000 X F S B \0 \0 020 \0 \0 \0 \0 \0 016 216 022 300 0000020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
Das sieht doch schon mal gut aus.
Haben sich durch den Hardwareumbau die Plattengeräte /dev/sdX) verschoben?
Kann ich dir leider nicht sagen. Vorher hing alles an einem pci-sata-raid controller (4xsata, ohne raid activation betrieben). Jetzt direkt am mainboard, weil dort 4 sata-anschlüsse sind (2x2raid controller, aber ohne raid in betrieb). Nur immer software raid5.
Es hängt davon ab, wie robust die Plattenerkennung ist, um die Teile wieder zusammenzusetzen. Angenommen, Du tauschst die Plattenstecker auf dem Brett mal alle gegeneinander aus. Würde die /dev/md0 noch richtig, und zuverlässig - nicht zufällig(!), hochfahren? Vielleicht weiß jemand anders die Antwort.
ist die erkannte Reihenfolge der einzelnen Platten nicht wichtig für's Zusammensetzen des Raids? Oder werden den einzelnen Platten eindeutige Merkmale mitgegeben anhand eine Logic erkennen kann welche Platte welches Stück vom Raid "besitzt". Wenn zwei von drei Platten reichen, kann an da nicht erst mit zwei Platten beginnen, da müßte man ja nur einmal tauschen. Ich frage, weil mich das interessiert aberich leider keine Ahnung habe und deshalb die Finger vom Raid gelassen habe.
Jede menge datein nach lost&found verschoben. Kann aber auch einträge meiner dateien sehen.
Das sieht irgendwie nach sehr kaputt aus.
Ja, leider. Wenn diese Programme etwas wiedererkennbares finden, dann funktioniert die Entschlüsselung.
meine drei hd's habe ich auch einzeln gecheckt:
Autsch, damit wäre ich SEHR vorsichtig, jeder Schreibvorgang sägt ein Stück vom Ast ab. Bei RAID5 ist jede der 3 Platten anders. Bei RAID1 kannst Du das zur Not machen, da sollten die Platten den gleichen Inhalt haben und Du kannst von der einen holen was auf der anderen kaputt ist.
Guter Gegentest, ob die Entschlüsselung funktioniert. Bei Binärsalat gibt xfs_check in 2 von 3 Fällen nicht nur eine Fehlermeldung, sondern gleich ganz den Löffel ab.
Mit welchen optionen schaffe ich es bei xfs_repair einen kompletten durchlauf oder wie kann ich da noch was retten? Oder gibt's irgendwelche anderen rettungsmöglichkeiten?
Ich habe mit XFS keine Erfahrung. Poste ruhig mit neuem Subject spezifisch auf XFS.Ich kann hier nicht weiter helfen.
Das "No modify flag set" sieht mir danach aus, als könnte /dev/loop0 noch read-only laufen, da können dann natürlich keine Reparaturen durchgeführt werden und das Programm bricht ab.
Gruß Johannes -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Volker, dankdir für all deine bemühungen bei meinem problem! Werde deinen rat bzgl. xfs-posting annehmen. gruß thomas -- Ein Mensch kann sich nicht frei nennen, wenn seine Freiheit auf der Unterdrückung anderer beruht. -- Juan Carlos I. Am Montag, 3. März 2008 schrieb Volker Kuhlmann:
On Mon 03 Mar 2008 00:37:24 NZDT +1300, Thomas Lange wrote:
Ja, es läuft wirklich, allerdings wird mein raid nicht gleich beim booten gestartet, sondern ich muß das selbst tun im moment mit:
mdadm --auto-detect
Sowas in der Art wird beim booten einmal von einem Skript ausgeführt, aber nur, wenn das Skript auch eingeschaltet ist. Möglicherweise ist das nicht passiert, weil Du auf diesem System selbst mit yast kein RAID eingerichtet hast, sondern die Platten hinterher reingesteckt hast?
Wie dem auch sei, Skript einschalten:
chkconfig -a boot.md
ausschalten
chkconfig -d boot.md
ergibt bei mir nach pw-abfrage und losetup -a dann: workhorse:~ # losetup -a /dev/loop0: [000f]:4433 (/dev/md0), encryption twofish (type 18), key length 32 Keine fehlermeldungen!
Keine Fehlermeldungen ist notwendig, aber nicht hinreichend. Ein falsches Paßwort gibt auch keine Fehlermeldung.
verschlüsselung und passwort scheinen korrekt zu sein. Ich sehe folgendes:
0000000 X F S B \0 \0 020 \0 \0 \0 \0 \0 016 216 022 300 0000020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
Das sieht doch schon mal gut aus.
Haben sich durch den Hardwareumbau die Plattengeräte /dev/sdX) verschoben?
Kann ich dir leider nicht sagen. Vorher hing alles an einem pci-sata-raid controller (4xsata, ohne raid activation betrieben). Jetzt direkt am mainboard, weil dort 4 sata-anschlüsse sind (2x2raid controller, aber ohne raid in betrieb). Nur immer software raid5.
Es hängt davon ab, wie robust die Plattenerkennung ist, um die Teile wieder zusammenzusetzen. Angenommen, Du tauschst die Plattenstecker auf dem Brett mal alle gegeneinander aus. Würde die /dev/md0 noch richtig, und zuverlässig - nicht zufällig(!), hochfahren? Vielleicht weiß jemand anders die Antwort.
ein xfs_check /dev/loop0 gibt: xfs_check: out of memory (steht auch in der man page -> wg. großes dateisystem)
Ja, XFS ist dafür bekannt. Da hilft nur mehr Speicher.
ein xfs_repair -n /dev/loop0 läuft los und hält nach ca. 20 sec an mit
problem with directory contents in inode 4140128138 would have cleared inode 4140128138 - agno = 31 No modify flag set, skipping phase 5 Inode allocation btrees are too corrupted, skipping phases 6 and 7 No modify flag set, skipping filesystem flush and exiting.
Jede menge datein nach lost&found verschoben. Kann aber auch einträge meiner dateien sehen.
Das sieht irgendwie nach sehr kaputt aus.
Ja, leider. Wenn diese Programme etwas wiedererkennbares finden, dann funktioniert die Entschlüsselung.
meine drei hd's habe ich auch einzeln gecheckt:
Autsch, damit wäre ich SEHR vorsichtig, jeder Schreibvorgang sägt ein Stück vom Ast ab. Bei RAID5 ist jede der 3 Platten anders. Bei RAID1 kannst Du das zur Not machen, da sollten die Platten den gleichen Inhalt haben und Du kannst von der einen holen was auf der anderen kaputt ist.
workhorse:~ # xfs_check /dev/sdb1 xfs_check: unexpected XFS SB magic number 0x9ea7f5c7 /usr/sbin/xfs_check: line 28: 5395 Floating point exceptionxfs_db$DBOPTS -i -p xfs_check -c "check$OPTS" $1
workhorse:~ # xfs_check /dev/sdc1 XFS: Log inconsistent or not a log (last==0, first!=1) XFS: empty log check failed ERROR: cannot find log head/tail, run xfs_repair
workhorse:~ # xfs_check /dev/sdd1 xfs_check: unexpected XFS SB magic number 0xc6e1a685 /usr/sbin/xfs_check: line 28: 5399 Floating point exceptionxfs_db$DBOPTS -i -p xfs_check -c "check$OPTS" $1
Guter Gegentest, ob die Entschlüsselung funktioniert. Bei Binärsalat gibt xfs_check in 2 von 3 Fällen nicht nur eine Fehlermeldung, sondern gleich ganz den Löffel ab.
Mit welchen optionen schaffe ich es bei xfs_repair einen kompletten durchlauf oder wie kann ich da noch was retten? Oder gibt's irgendwelche anderen rettungsmöglichkeiten?
Ich habe mit XFS keine Erfahrung. Poste ruhig mit neuem Subject spezifisch auf XFS.Ich kann hier nicht weiter helfen.
Das "No modify flag set" sieht mir danach aus, als könnte /dev/loop0 noch read-only laufen, da können dann natürlich keine Reparaturen durchgeführt werden und das Programm bricht ab.
Viel Glück,
Volker
-- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Montag, 25. Februar 2008 schrieb Volker Kuhlmann:
On Mon 25 Feb 2008 20:41:45 NZDT +1300, Thomas Lange wrote:
Weiß ich, hilft aber ja doch nichts. Machmal muß man eben aufrüsten. Leider hat sich das handling von verschlüsselten partitionen irgendwie geändert. Vorher gab's die cryptotab, jetzt die crypttab.
Genau. Statt cryptoloop ist's jetzt dm-crypt. Wäre aber echt faul, wenn man nach dem Aufrüsten die alten Verschlüsselten Partitionen nicht mehr ansprechen könnte. So dumm sollte ein Linux-Lieferant nicht sein dürfen. Bei mir war es so, daß die 10.3 das entsprechende Modul nicht automatisch lädt.
modprobe cryptoloop
Wenn Du den Modulnamen zur Variablen MODULES_LOADED_ON_BOOT in /etc/sysconfig/kernel hinzufügst, wird das Modul beim booten geladen.
kommentar siehe vorige mail.
Auch das raid hat sich von v.0.90.3 nach v.1.00.3 geändert. Mir würde es vielleicht schon weiterhelfen, wenn mir jemand sagen könnte, wo ich eher suchen müßte, bei der verschlüsselung oder beim raid!?
Dein RAID läuft, das zeigt /proc/mdstat an.
Das glaube ich nur teilweise, weil ich noch folgende fehlermeldung erhalte: --------------------------------------------------------------------------------- Feb 26 12:05:10 workhorse kernel: XFS mounting filesystem md0 Feb 26 12:05:10 workhorse kernel: XFS: Log inconsistent (didn't find previous header) Feb 26 12:05:10 workhorse kernel: XFS: failed to find log head Feb 26 12:05:10 workhorse kernel: XFS: log mount/recovery failed: error 5 Feb 26 12:05:10 workhorse kernel: XFS: log mount failed --------------------------------------------------------------------------------- Ist damit das filesystem kaputt? Kann ich das noch reparieren? Mittlerweile habe ich auf eine reserveplatte suse v.10.2 nochmals aufgespielt und von dort aus weiter versucht, negativ. workhorse:~ # losetup -a /dev/loop0: [000e]:2554(/dev/hda4)encryption=CryptoAPI/twofish-cbc /dev/loop1: [000e]:3024(/dev/md0)encryption=CryptoAPI/twofish-cbc workhorse:~ # dmesg|tail loop: registered Twofish encryption loop: unregistered Twofish encryption Bedeutet dies, daß die verschlüsselung für loop0 eingeschaltet, für loop1 aber ausgeschaltet ist?
Nein, kein backup...aber wer macht auch schon ein backup von 1 TByte im privaten bereich?
Lästig, aber nötig. Es gibt jetzt 1TB SATA Platten. Erschwinglich für wichtige Daten, aber nicht billig. Oder Du sagst, zu teuer, dann waren die Daten auch nicht so wichtig... ;)
Dein RAID schützt Dich nur, wenn plötzlich eine Platte abraucht. Es schützt nicht gegen kaputten Speicher und davon hervorgerufene Harakiri Kernels (sh.. in, sh.. out), den Faktor zwischen Tastatur und Stuhl, oder das Netzteil, das morgen peng macht und alle Elektronik brät.
Aber nur Du kannst entscheiden, was Dir Deine Daten wirklich wert sind.
Volker
-- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
mfg thomas -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (5)
-
Günther J. Niederwimmer -
Johannes Kapune -
Karl Kehlenbrink -
Thomas Lange -
Volker Kuhlmann