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