Am 28.03.2013 13:30, schrieb Joerg Thuemmler:

Am 28.03.2013 13:08, schrieb Norbert Zawodsky:

...

Hallo Leute!

jetzt habe ich ein massives, ernstes Problem...

Nachdem das update mittels "zypper dup" auf 2 Maschinen sowas von Problemlos funktioniert hat, habe ich es jetzt auch auf der 3. und wichtigsten maschine gemacht.

Das relevante Setup:

Für die besonders "wichtigen" Daten sind in diesem Rechner neben anderen Disks auch 2 "idente " Harddisks, die im mainborad-Bios als Hardware-RAID-1 definiert sind. (Diese disks scheinen auch als /dev/sdc und /dev/sdd auf). Die virtuelle Raid-Disk wird als /dev/md126 angelegt. Dann habe ich (vor langer Zeit, noch unter OS 12.1) auf diesem Raid eine LUKS-Verschlüsselte Partition angelegt.

crypttab: cr_md126 /dev/disk/by-id/md-uuid-2d148ec7:d19e3a3b:cc1a5ea2:3402050d none none

fstab: /dev/mapper/cr_md126 /CryptHD ext4 auto,acl,user_xattr,nofail 0 2

Soweit hat das immer bestens funktioniert. Auch damals nach dem Upgrade von 12.1 auf 12.2 mit "zypper dup".

Gestern also der Upgrade auf OS 12.3 Es lief scheinbar Problemlos durch. Beim reboot wurde ich wie immer nach der Passphrase für die verschlüsselte disk gefragt.

Beim 1. Login fiel mir dann auf dass die verschlüsselte disk scheinbar nicht gemountet ist. Ein "mount /CryptHD" retournierte "/CryptHD bereits gemounted oder /CryptHD ist busy"

Beim Durchsuchen der dmesg Ausgabe bringt folgenden Ablauf:

[ 2.827537] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.855528] ata3.00: ATA-8: ST500NM0011, SN02, max UDMA/133 [ 2.882480] ata3.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32) [ 2.910320] ata3.00: configured for UDMA/133 [ 2.937214] scsi 2:0:0:0: Direct-Access ATA ST500NM0011 SN02 PQ: 0 ANSI: 5 [ 2.964739] sd 2:0:0:0: [sdc] 976773168 512-byte logical blocks: (500 GB/465 GiB) [ 2.992585] sd 2:0:0:0: [sdc] Write Protect is off [ 3.019705] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 [ 3.019880] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 3.065627] *sdc: unknown partition table* [ 3.093816] sd 2:0:0:0: [sdc] Attached SCSI disk [ 3.475230] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 3.503449] ata4.00: ATA-8: ST500NM0011, SN02, max UDMA/133 [ 3.530672] ata4.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32) [ 3.558781] ata4.00: configured for UDMA/133 [ 3.585800] scsi 3:0:0:0: Direct-Access ATA ST500NM0011 SN02 PQ: 0 ANSI: 5 [ 3.613694] sd 3:0:0:0: [sdd] 976773168 512-byte logical blocks: (500 GB/465 GiB) [ 3.642372] sd 3:0:0:0: [sdd] Write Protect is off [ 3.670793] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 [ 3.670969] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 3.709238] *sdd: unknown partition table* [ 3.739382] sd 3:0:0:0: [sdd] Attached SCSI disk ... [ 19.245149] md: bind<sdc> ... [ 21.109707] md: bind<sdd> ... [ 21.663473] md: bind<sdd> [ 21.663524] md: bind<sdc> [ 21.771486] md: raid1 personality registered for level 1 [ 21.806423] md/raid1:md126: active with 2 out of 2 mirrors [ 21.840572] md126: detected capacity change from 0 to 500104691712 [ 21.875261] *md126: unknown partition table* [ 21.913352] md: md126 switched to read-write mode.

Dann habe ich mir gedacht, ich versuche ein reboot. Der shutdown blieb aber gegen Ende einfach hängen. Im log finden sich dazu folgende, sehr verdächtige Ausgaben die sich exakt alle 8 Minuten wiederholen:

[ 2879.392435] INFO: task kworker/2:1:58 blocked for more than 480 seconds. [ 2879.392439] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 2879.392442] kworker/2:1 D ffff88027fc53180 0 58 2 0x00000000 [ 2879.392446] ffff880272f4bbb8 0000000000000046 ffff880272f48140 ffff880272f4bfd8 [ 2879.392450] ffff880272f4bfd8 ffff880272f4bfd8 ffff880273116340 ffff880272f48140 [ 2879.392454] 0000000000000246 ffff88026dd0e400 0000000000001000 0000000000000001 [ 2879.392458] Call Trace: [ 2879.392471] [<ffffffff8140874d>] md_write_start+0x9d/0x1b0 [ 2879.392486] [<ffffffffa01bdb98>] make_request+0x38/0xbc0 [raid1] [ 2879.392501] [<ffffffff81402016>] md_make_request+0xc6/0x1e0 [ 2879.392508] [<ffffffff812907a2>] generic_make_request+0xb2/0x100 [ 2879.392515] [<ffffffffa023f3f5>] kcryptd_crypt+0x245/0x3b0 [dm_crypt] [ 2879.392529] [<ffffffff8105f1ed>] process_one_work+0x12d/0x4a0 [ 2879.392534] [<ffffffff81061bad>] worker_thread+0x15d/0x470 [ 2879.392540] [<ffffffff81066273>] kthread+0xb3/0xc0 [ 2879.392548] [<ffffffff8154f23c>] ret_from_fork+0x7c/0xb0 [ 2879.392559] INFO: task *fsck.ext4*:738 blocked for more than 480 seconds. [ 2879.392561] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 2879.392562] fsck.ext4 D ffff88027fc53180 0 738 737 0x00000000 [ 2879.392566] ffff88027336fd38 0000000000000086 ffff880273220880 ffff88027336ffd8 [ 2879.392569] ffff88027336ffd8 ffff88027336ffd8 ffff880273116340 ffff880273220880 [ 2879.392573] 000000000598006b ffff880273220880 ffff88027fc53a20 0000000000000002 [ 2879.392577] Call Trace: [ 2879.392584] [<ffffffff815467ba>] io_schedule+0x8a/0xd0 [ 2879.392591] [<ffffffff81109229>] sleep_on_page+0x9/0x10 [ 2879.392596] [<ffffffff8154508f>] __wait_on_bit+0x4f/0x80 [ 2879.392602] [<ffffffff81109340>] wait_on_page_bit+0x70/0x80 [ 2879.392607] [<ffffffff811096d8>] filemap_fdatawait_range+0xd8/0x160 [ 2879.392612] [<ffffffff8110a695>] filemap_write_and_wait_range+0x65/0x70 [ 2879.392619] [<ffffffff8119baad>] blkdev_fsync+0x1d/0x50 [ 2879.392626] [<ffffffff81193927>] do_fsync+0x57/0x90 [ 2879.392630] [<ffffffff81193b8b>] sys_fsync+0xb/0x20 [ 2879.392635] [<ffffffff8154f2ed>] system_call_fastpath+0x1a/0x1f [ 2879.392647] [<00007f64862547b0>] 0x7f64862547af

Es scheint, als würde ein fsck auf die verschlüsselte disk "hängen". Ein rebbot ändert (erwartungsgemäß) nichts.

Ich habe dann die /CryptHD Zeile aus der fstab "ausgeschaltet" Der boot läuft gefühlt schneller durch. Ein manuelles mount nach login bleibt dann aber endlos hängen. Auch ein Einstieg in Yast->Partitionierer bleibt "endlos hängen".

Hat jemand von Euch eine Idee wie ich dieses Problem angehen, oder vielleicht sogar lösen kann ?? Ich bin für den Moment mit meinem Latein am Ende...

Norbert

Hi,

bin mir nicht ganz im Klaren, was für eine Sorte RAID1 das ist, aber ich denke, wenn es im BIOS als RAID1 festgelegt ist, sollte die SuSE die Einzel-HDs sdc und sdd _nicht_ mehr sehen, geschweige denn mounten (wollen). Der SuSE sollte nur das RAID1 sichtbar sein. Jedenfalls ist das bei mir (ARECA-RAID) so. Ich kann die Platten zwar auch einzeln ansprechen (z.B. smartctl) aber mit einer RAID-spezifischen Notation, (hier -d areca,1 /dev/sg1), aber das System sieht von sich aus nur /dev/sda.

Ich denke, da bekommt die SuSE was von Deinem BIOS-RAID nicht mit. Kannst Du verhindern, dass sdc/sdd bei Booten gemountet werden? Wenn sie gemountet sind (s. messages), ist es klar, dass sie busy sind, wenn das RAID ranwill.

cu jth

Hi Jörg, das wäre auch mein empfinden, dass das OS die einzelnen HDs nichzt mehr sehen sollte. Aber es war immer so. Auch schon unter 12.1 und 12.2 und hat nie Probleme gemacht. Ich wüsste auch nicht wo ich das im BIOS einstellen könnte. Das BIOS-RAID ist dem OS aber sehr wohl bekannt. Es gibt (was das raid betrifft): /dev/sdc /dev/sdd /dev/md126 /dev/md/Raid1_01_0 -> /dev/md126 /dev/dm-0 *was mag das wohl sein ?? Ich glaube, das gabs unter 12.2 noch nicht */dev/disk/by-id/dm-name-cr_md126 -> /dev/dm-0 /dev/disk/by-id/dm-uuid-CRYPT-LUKS1-3f9c1399617e4944b9b7fdb0fc6ebc34-cr_md126 -> /dev/dm-0 /dev/disk/by-id/md-uuid-2d148ec7:d19e3a3b:cc1a5ea2:3402050d -> /dev/md126 Jetzt, wo ich das schreibe kommt mir das eigenartig vor. Wo kommt dieses /dev/dm-0 her? Vor allem zeigt die "cr_md126" disk aud /dev/dm-0 und *nicht* auf /dev/md126 Für mich fehlt da jetzt irgendwo die logische Verbindung von der crypt-md-126 auf die /dev/md126 Das widerspricht doch irgendwie der crypttab, oder? Laut crypttab "zeigt" cr_md126 auf /dev/disk/by-id/md-uuid-2d148ec7:d19e3a3b:cc1a5ea2:3402050d Ich blick da irgendwie nicht durch .... Norbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 28.03.2013 15:28, schrieb Ulrich Gehauf:

Am 28.03.2013 14:44, schrieb Norbert Zawodsky:

...

das wäre auch mein empfinden, dass das OS die einzelnen HDs nichzt mehr sehen sollte. Aber es war immer so. Auch schon unter 12.1 und 12.2 und hat nie Probleme gemacht. Ich wüsste auch nicht wo ich das im BIOS einstellen könnte.

So ist das in der Regel bei "hochwertigen" Raidcontrollern. Bei den einfachen, in den üblichen "Hausgebrauch-Wald-und-Wiesen-Mainboards" macht das allerdings mehr oder weniger nur der Treiber und nicht der Chip selber. Daher oft auch in der Produktbeschreibung, dass die Raidfunktionalität nur unter Windows existiert (weil der Hersteller halt nur für Win die entsprechenden Treiber hat)

...

Das BIOS-RAID ist dem OS aber sehr wohl bekannt. Es gibt (was das raid betrifft):

/dev/sdc /dev/sdd /dev/md126 /dev/md/Raid1_01_0 -> /dev/md126 /dev/dm-0 *was mag das wohl sein ?? Ich glaube, das gabs unter 12.2 noch nicht */dev/disk/by-id/dm-name-cr_md126 -> /dev/dm-0 /dev/disk/by-id/dm-uuid-CRYPT-LUKS1-3f9c1399617e4944b9b7fdb0fc6ebc34-cr_md126

-> /dev/dm-0 /dev/disk/by-id/md-uuid-2d148ec7:d19e3a3b:cc1a5ea2:3402050d -> /dev/md126

Das sieht alles ein wenig sehr chaotisch aus. Was ist eigentlich mit sda und sdb, wenn es sdc und sdd gibt?

Wie hast du md126 erzeugt? Über mdadm? Oder kommt das vom Raidcontroller?

Gruß Uli sda und sdb sind 2 physische disk. ohne Raid, ohne Verschlüsselung und funktionieren auch.

klingt jetzt vielleicht blöd, aber keine Ahnung wie md126 erzeugt wird/wurde. Es ist einfach da. Geht wohl irgendwie automatisch. Glaub ich.... Es ist ja kein vom Linux "simuliertes" software Raid sondern das macht schon das Bios vom disk-controller. (zumindest stelle ich mir das so vor). Sollte md126 doch von mir "erzeugt" worden sein, war das vor vielen vielen Monden und ich erinnere mich nicht mehr. Ich habe jetzt ausprobiert: rincewind:~ # cryptsetup -v luksOpen /dev/md126 blabla Geben Sie den Passsatz für /dev/md126 ein: Schlüsselfach 0 entsperrt. Befehl erfolgreich. rincewind:~ # fsck -nv /dev/mapper/blabla fsck von util-linux 2.21.2 e2fsck 1.42.6 (21-Sep-2012) Warnung: Überspringe Journal-Wiederherstellung, da das Dateisystem im Nur-Lesen-Modus ist. Und dann hängt es endlos.... Genau 8 Minuten später in /var/log/messages: Mar 28 15:34:23 rincewind kernel: [ 1919.847783] INFO: task fsck.ext4:4296 blocked for more than 480 seconds. Mar 28 15:34:23 rincewind kernel: [ 1919.847787] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Mar 28 15:34:23 rincewind kernel: [ 1919.847790] fsck.ext4 D ffff88027fc73180 0 4296 4295 0x00000004 Mar 28 15:34:23 rincewind kernel: [ 1919.847794] ffff88021bc21ca8 0000000000000082 ffff88020df742c0 ffff88021bc21fd8 Mar 28 15:34:23 rincewind kernel: [ 1919.847799] ffff88021bc21fd8 ffff88021bc21fd8 ffff88027311a380 ffff88020df742c0 Mar 28 15:34:23 rincewind kernel: [ 1919.847802] 0000000000000246 ffff880270be9000 0000000000000000 0000000000000001 Mar 28 15:34:23 rincewind kernel: [ 1919.847806] Call Trace: Mar 28 15:34:23 rincewind kernel: [ 1919.847819] [<ffffffff8140874d>] md_write_start+0x9d/0x1b0 Mar 28 15:34:23 rincewind kernel: [ 1919.847832] [<ffffffffa02eab98>] make_request+0x38/0xbc0 [raid1] Mar 28 15:34:23 rincewind kernel: [ 1919.847849] [<ffffffff81402016>] md_make_request+0xc6/0x1e0 Mar 28 15:34:23 rincewind kernel: [ 1919.847855] [<ffffffff812907a2>] generic_make_request+0xb2/0x100 Mar 28 15:34:23 rincewind kernel: [ 1919.847861] [<ffffffff81290851>] submit_bio+0x61/0x130 Mar 28 15:34:23 rincewind kernel: [ 1919.847866] [<ffffffff812938fe>] blkdev_issue_flush+0x8e/0xd0 Mar 28 15:34:23 rincewind kernel: [ 1919.847872] [<ffffffff8119bac6>] blkdev_fsync+0x36/0x50 Mar 28 15:34:23 rincewind kernel: [ 1919.847879] [<ffffffff81193927>] do_fsync+0x57/0x90 Mar 28 15:34:23 rincewind kernel: [ 1919.847884] [<ffffffff81193b8b>] sys_fsync+0xb/0x20 Mar 28 15:34:23 rincewind kernel: [ 1919.847891] [<ffffffff8154f2ed>] system_call_fastpath+0x1a/0x1f Mar 28 15:34:23 rincewind kernel: [ 1919.847906] [<00007f4af16a57b0>] 0x7f4af16a57af Hmmm..... Gruß, Norbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 28.03.2013 16:09, schrieb Ulrich Gehauf:

Am 28.03.2013 15:46, schrieb Norbert Zawodsky:

...

sda und sdb sind 2 physische disk. ohne Raid, ohne Verschlüsselung und funktionieren auch.

Und die sind auch noch da, wo sie sein sollen und ist auch das drauf, was erwartet wird?

...

klingt jetzt vielleicht blöd, aber keine Ahnung wie md126 erzeugt wird/wurde. Es ist einfach da. Geht wohl irgendwie automatisch. Glaub ich.... Es ist ja kein vom Linux "simuliertes" software Raid sondern das macht schon das Bios vom disk-controller. (zumindest stelle ich mir das so vor).

Sollte md126 doch von mir "erzeugt" worden sein, war das vor vielen vielen Monden und ich erinnere mich nicht mehr.

Das wäre aber schon irgendwie hilfreich zu wissen. Zumal dein Controler ja anscheinend die beiden Platten erst mal als "normale" Platten dem System meldet. Das deutet eigentlich eher auf ein Softraid hin.

Was sagt denn #> cat /proc/mdstat

...

Ich habe jetzt ausprobiert:

rincewind:~ # cryptsetup -v luksOpen /dev/md126 blabla Geben Sie den Passsatz für /dev/md126 ein: Schlüsselfach 0 entsperrt. Befehl erfolgreich.

Naja, zumindest der Container konnte schon mal gefunden und geöffnet werden. Ist ja schon mal was.

...

rincewind:~ # fsck -nv /dev/mapper/blabla

Was sagt ein #> cryptsetup status blabla

Was passiert mit einem fsck.[das verwendete Filesystem]?

Weitere Versuche: -------------------------------------------------------------------------------- rincewind:~ # mdadm --detail /dev/md126 /dev/md126: Container : /dev/md/imsm0, member 0 Raid Level : raid1 Array Size : 488383488 (465.76 GiB 500.10 GB) Used Dev Size : 488383620 (465.76 GiB 500.10 GB) Raid Devices : 2 Total Devices : 2 State : active Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 UUID : 2d148ec7:d19e3a3b:cc1a5ea2:3402050d Number Major Minor RaidDevice State 1 8 32 0 active sync /dev/sdc 0 8 48 1 active sync /dev/sdd -------------------------------------------------------------------------------- rincewind:~ # cat /proc/mdstat Personalities : [raid1] md126 : active raid1 sdc[1] sdd[0] 488383488 blocks super external:/md127/0 [2/2] [UU] md127 : inactive sdd[1](S) sdc[0](S) 5928 blocks super external:imsm unused devices: <none> -------------------------------------------------------------------------------- rincewind:~ # cryptsetup status blabla /dev/mapper/blabla is active and is in use. type: LUKS1 cipher: aes-cbc-essiv:sha256 keysize: 256 bits device: /dev/md126 offset: 4096 sectors size: 976762880 sectors mode: read/write -------------------------------------------------------------------------------- Ein fsck.ext4 /dev/blabla macht das selbe wie ein fsck. Es "hängt" endlos. (und nach 8 Minuten der oben erwähnte Eintrag in /var/log/messages) -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 28.03.2013 16:33, schrieb Ulrich Gehauf:

Am 28.03.2013 16:19, schrieb Norbert Zawodsky:

...

rincewind:~ # cat /proc/mdstat Personalities : [raid1] md126 : active raid1 sdc[1] sdd[0] 488383488 blocks super external:/md127/0 [2/2] [UU]

md127 : inactive sdd[1](S) sdc[0](S) 5928 blocks super external:imsm

unused devices: <none>

Sieht zumindest so aus, als wäre es tatsächlich ein Softraid, das soweit OK ist. md127 resultiert vermutlich noch aus einer Experimentierphase? Nein! Keine Experimentierphase.

Keine Ahnung wo md127 plötzlich herkommt. Ich bin sogar 99% sicher dass es md127 unter OS 12.2 noch nicht gab sondern dass das erst jetzt mit OS 12.3 "aufgetaucht" ist.

...

rincewind:~ # cryptsetup status blabla /dev/mapper/blabla is active and is in use. type: LUKS1 cipher: aes-cbc-essiv:sha256 keysize: 256 bits device: /dev/md126 offset: 4096 sectors size: 976762880 sectors mode: read/write

Cryptcontainer selber scheint auch OK zu sein... dann kann eigentlich nur noch das Filesystem einen Treffer haben.

Versuch doch mal, mit dd if=/dev/mapper/blabla of=[irgendwohin wo Platz ist].img erst mal ein Abbild zu sichern und dann darauf fsck mit repairoptionen los zu lassen

o.k. Haber auf einer Platte >500 GB frei gemacht sollte sich also ausgehen. Bitte kurze "Nachhilfe": Wie mache ich ein fsck auf eine Datei? Muss ich sie irgendwie loop mounten, oder was ähnliches ??? Danke für Deine Hilfe !!! -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 28.03.2013 18:24, schrieb Norbert Zawodsky:

Am 28.03.2013 16:33, schrieb Ulrich Gehauf:

...

Am 28.03.2013 16:19, schrieb Norbert Zawodsky:

...

rincewind:~ # cat /proc/mdstat Personalities : [raid1] md126 : active raid1 sdc[1] sdd[0] 488383488 blocks super external:/md127/0 [2/2] [UU]

md127 : inactive sdd[1](S) sdc[0](S) 5928 blocks super external:imsm

unused devices: <none>

Sieht zumindest so aus, als wäre es tatsächlich ein Softraid, das soweit OK ist. md127 resultiert vermutlich noch aus einer Experimentierphase?

...

rincewind:~ # cryptsetup status blabla /dev/mapper/blabla is active and is in use. type: LUKS1 cipher: aes-cbc-essiv:sha256 keysize: 256 bits device: /dev/md126 offset: 4096 sectors size: 976762880 sectors mode: read/write

Cryptcontainer selber scheint auch OK zu sein... dann kann eigentlich nur noch das Filesystem einen Treffer haben.

Versuch doch mal, mit dd if=/dev/mapper/blabla of=[irgendwohin wo Platz ist].img erst mal ein Abbild zu sichern und dann darauf fsck mit repairoptionen los zu lassen.

Nächste "Gute Nachricht":

Reines Lesen mittels dd hat funktioniert. Dann

rincewind:/srv/video # fsck.ext4 -vn ./blabla.img e2fsck 1.42.6 (21-Sep-2012) Warnung: Überspringe Journal-Wiederherstellung, da das Dateisystem im Nur-Lesen-Modus ist. ./blabla.img: sauber, 25947/30531584 Dateien, 3247967/122095360 Blöcke

das fs ist also scheinbar in Ordnung. Wieso hängt dann das disk-i/o auf das orginal device ???

ich glaube, irgendetwas hängt da noch vom boot prozess und blockiert das device für alles weitere ....

Also das fs ist offenbar wirklich sauber. Ich habe jetzt die Datei mit mount ./blabla.img /mnt -t ext4 -o loop=/dev/loop1 auf /mnt gemounted. Alle meine Daten sind vorhanden und vollkommen in Ordnung. Das bedeutet: * Der Cryptcontainer ist in Ordnung. * nach "manuellem" luksOpen kann man von /dev/mapper/xxxx offenbar problemlos lesen nur r/w mounten geht offenbar nicht. Jeder r/w Zugriff hängt endlos im kernel. Wie finde ich blos das Problem ...???...???... -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Hallo Norbert, hallo Leute, Am Donnerstag, 28. März 2013 schrieb Norbert Zawodsky:

Am 28.03.2013 16:09, schrieb Ulrich Gehauf:

...

Am 28.03.2013 15:46, schrieb Norbert Zawodsky:

rincewind:~ # mdadm --detail /dev/md126 /dev/md126: Container : /dev/md/imsm0, member 0

"imsm" oder "imsm raid" bringen per Google etwas Licht in die Sache, z. B. https://raid.wiki.kernel.org/index.php/RAID_setup (nach "imsm" suchen) und http://forums.gentoo.org/viewtopic-t-888520.html Ich habe das Ganze nur kurz überflogen (Du solltest die beiden Seiten etwas genauer lesen), jedenfalls scheint es sich um ein "fakeraid" zu handeln, das sich auch mit mdadm verträgt - aus Linux-Sicht also ein "fast normales" Soft-RAID, wenn auch mit anderem Format für die Metadaten. Auch http://www.spinics.net/lists/raid/msg41633.html dürfte einen Blick wert sein.

---------- rincewind:~ # cat /proc/mdstat Personalities : [raid1] md126 : active raid1 sdc[1] sdd[0] 488383488 blocks super external:/md127/0 [2/2] [UU]

md127 : inactive sdd[1](S) sdc[0](S) 5928 blocks super external:imsm

Wenn ich das richtig interpretiere, hat md126 externe Metadaten, die auf md127 liegen. Das komische ist nur, dass md126 und md127 jeweils die komplette sdc und sdd nutzen (was immerhin erklären könnte, warum die Devices "busy" sind), und dass md127 "inactive" ist. Falls Du nicht weiterkommst, mach bitte einen Bugreport auf, Assignee nfbrown@suse.com - Neil hat erfahrungsgemäß recht schnell eine Lösung für RAID-Probleme[1]. In den Bugreport bitte die Infos aus diesem Thread (/proc/mdstat, mdadm --detail usw.) und die Info, dass es mit 12.2 noch funktioniert hat, reinpacken. Ein Link zum Listenarchiv kann auch nicht schaden. Außerdem bitte den Bugzilla-Link hier posten ;-) Gruß Christian Boltz [1] ich habe wegen https://bugzilla.novell.com/show_bug.cgi?id=793954 derzeit ein Paket mit einem Test-Patch von ihm im Einsatz ;-) --

Womit erstellt ihr so eure Homepages? mit vim *g*. Wobei es Leute gibt, die tatsächlich behaupten, das soll auch mit diesem Betriebssystem - wie heißt es doch gleich - *äh* Emacs gehen. <SCNR> [> Bernd Stäglich und Philipp Zacharias in suse-linux]

-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Deine Anmerkungen sind beides, sehr interessant und sehr erschreckend.

Interessant, weil ich diesem Problem wahnsinnig gerne den Garaus machen möchte. Da würde ich nur eine Lösung in Betracht ziehen: Meiner Meinung nach haben Fakeraids im professionellen Umfeld rein gar nichts zu suchen, da nämlich Board kaputt - Raid kaputt - Daten kaputt, und es wundert mich schon sehr dass Du das offensichtlich nicht gewusst hast, was für ein Raid Du da hast. Aber nun ist die Sache nunmal

Am 29.03.2013 00:18, schrieb Norbert Zawodsky: [...] passiert. Was ich hier machen würde? Fakeraid in die Tonne treten, und die beiden Platten als Software-Raid mit mdadm konfigurieren. Das überlebt dann auch mal einen Boarddefekt. Somit: Problem erkannt, Problem gebannt! Warum da dann als Server noch ein LUKS verschlüsseltes FS drüber liegt, weißt Du bestimmt besser, wird schon seine Gründe haben. Jedoch als stationären Server sehe ich da keinen großen Sinn darin, ein FS zu verschlüsseln, wenn die Partition eh immer gemountet ist.

Erschreckend, weil diese Maschine ein wichtiger Server ist und ich sie so schnell wie nur irgendwie möglich wieder 100% einsatzbereit haben muss. Notfalls mit einem downgrade auf OS 12.2 (geht das genaus so problemlos mit "zypper dup" ?????) Ich hab mal versucht, ein 12.1 auf 11.4 downzuduppen, ging völlig in die Hose. Also verlassen würd mich mich da nicht drauf

Ich habe Deinen Bug #793954 ausführlich gelesen. Einige Teile kommen mir irgendwie bekannt vor ;-) Ich sage nur "EBUSY"

Dass ich hier ein "fakeraid" habe ist neu für mich, aber offenbar richtig. Und ich dachte, meine Hardware würde alles erledigen ...

s.o. Hätte dir aber auch schon seltsam vorkommen sollen, dass neben dem mdblabla Device die einzelnen Platten auch noch auftauchen. Naja, hinterher ist man immer schlauer

Jedenfalls komme ich hier definitiv nicht weiter. Ich weiß jetzt nur nicht was ich tun soll. Das wichtigste für mich ist dass die Maschine wieder voll einsatzfähig ist. Soll ich ein downgrade auf 12.2 andenken ????

Würde ich nicht zu raten. Da Du die Daten wie Du schriebst eh in einem Images bereits hast, würde ich ein Software-Raid empfehlen lg Manfred aber trotzdem schöne Feiertage -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 29.03.2013 01:37, schrieb Norbert Zawodsky:

Entschuldige bitte, .. Woher soll ich denn wissen dass es ein fakeraid ist ?? Ich habe ein Motherboard verbaut und dann im Handbuch gelesen dass der darauf befindliche SATA-Controller auch RAID "kann". Also bin ich davon ausgegangen dass das Ding sowas wie ein Hardware-Raid ist. Ja das ist schon richtig, die vollmundigen Aussagen der Boardhersteller können einen da schon ziemlich verwirren und in die Irre führen Dass der Controller in Wirklichkeit nur so tut als ob, und alles erst wieder vom OS erledigt wird kann ich ja nicht wissen. Jetzt weiß ich es ... Ja, wieder was gelernt

Interessante Nebenfrage: Woran erkenne ich einen "echten" Hardwarre-RAID-Controller ? Kurze Antwort: Am Preis, massiger lokaler Cache, entsprechende Management-Tools ... und man kann von OS-Seite die einzelnen Platten halt nicht sehen

Verschlüsselt habe ich diese Partition nur aus einem Grund: Falls doch einmal ein böser Bube einbrechen kommt und den Server klaut, dann möchte ich zumindest eine gewisse Sicherheit dass er nicht an meine Daten kommt. Ob das besonders sinnvoll ist weiß ich nicht. Ist ja auch nicht das Thema

Die Möglichkeit habe ich natürlich. Für diese 2 Platten im BIOS die RAID-Funktion ausschalten, mit Hilfe von mdadm ein "neues" Raid-1 definieren, dann ext4 formatieren und die Daten draufkopieren. Das wäre so der Ablauf, oder ...??? Ganz genau

Gruß Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 28.03.2013 21:41, schrieb Christian Boltz:

Falls Du nicht weiterkommst, mach bitte einen Bugreport auf, Assignee nfbrown@suse.com - Neil hat erfahrungsgemäß recht schnell eine Lösung für RAID-Probleme[1]. In den Bugreport bitte die Infos aus diesem Thread (/proc/mdstat, mdadm --detail usw.) und die Info, dass es mit 12.2 noch funktioniert hat, reinpacken. Ein Link zum Listenarchiv kann auch nicht schaden.

Außerdem bitte den Bugzilla-Link hier posten ;-) https://bugzilla.novell.com/show_bug.cgi?id=812422

-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 29.03.2013 13:41, schrieb David Haller:

Hallo,

Am Fri, 29 Mar 2013, Norbert Zawodsky schrieb:

...

Am 28.03.2013 21:41, schrieb Christian Boltz:

...

Falls Du nicht weiterkommst, mach bitte einen Bugreport auf, Assignee nfbrown@suse.com - Neil hat erfahrungsgemäß recht schnell eine Lösung für RAID-Probleme[1]. In den Bugreport bitte die Infos aus diesem Thread (/proc/mdstat, mdadm --detail usw.) und die Info, dass es mit 12.2 noch funktioniert hat, reinpacken. Ein Link zum Listenarchiv kann auch nicht schaden.

Außerdem bitte den Bugzilla-Link hier posten ;-) https://bugzilla.novell.com/show_bug.cgi?id=812422 Du solltest noch das ergänzen, was bzgl. /dev/dm* und /dev/mapper auftaucht... Ich hab zwar genau gar keine Ahnung davon, nur ein paar _sehr_ vage Grundlagen, aber mich dünkt es relevant, daß sich evtl. mdadm und device-mapper um das intel fakeraid kloppen könnten ... Taucht außer manuell per luksopen noch was in /dev/mapper auf? Was spuckt der device-mapper so aus? Wie gesagt: keine Ahnung von Details, aber es wäre nicht das erste Mal, daß sich alt und neu bzw. zwei Varianten etwas zu machen kloppen. Vgl. ide-scsi vs. ide-cd, sysvinit vs. systemd (aktuell), NetworkManager und alles andere, udisks / automount /..., etc.pp. Hi David,

GENAU DAS ist mein Gefühl von der ersten Minute an. Ich finde es irgendwie unlogisch dass ein Setup 2 Releases lang (OS 12.1 + 12.2) problemlosest funktioniert und dann plötzlich nicht mehr. Ich glaube auch dass sich da 2 um das raid streiten. Irgendwie entsteht da ein deadlock. Jeder blockiert den anderen, oder so .... Es ist jetzt schon ein Jahr her dass ich das Ganze eingerichtet habe, aber wenn ich mich richtig erinnere, dann: * ich hatte ein laufendes 12.1 * dann habe ich 2 identische Festplatten gekauft, reingeschraubt, angesteckt * im BIOS das RAID1 definiert * system gebootet, /dev/md126 war da * mit Yast -> Partitionierer auf dem neuen /dev/md126 eine luks-verschlüsselte ext4 Partition angelegt und formatiert * fertig Ich kann mich absolut nicht erinnern jemals mdadm oder sonst ein luks-tool "manuell" verwendet zu haben. Oder ich habs einfach vergessen. Genauso bin ich 99,9% sicher dass es das jetzt existierende /dev/md127 bis inkl. 12.2 nicht gab. Das ist plötzlich mit 12.3 aufgetaucht. Auch ein Hinweis für mich dass da jetzt etwas am Werken ist, was bis 12.2 noch nicht da war. Leider blicke ich immer noch viel zu wenig durch, was genau hinter den Kulissen beim boot abläuft. Wer sagt dem device mapper dass er überhaupt etwas tun soll? Ich denke, udev spielt da auch mit. Was meinst Du mit "was spuckt der device-mapper so aus" ? Wo kann/soll ich was nachschauen? Wo/wie wird der device-mapper eigentlich konfiguriert ? Oder passiert das alles "automagically" ?? Norbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org