Am Donnerstag, 28. März 2013, 13:08:29 schrieb Norbert Zawodsky:
nach 12.2->12.3 kann LUKS hd nicht mehr ansprechen Von: Norbert Zawodsky
An: opensuse-de@opensuse.org Datum: Heute 13:08:29 Spam-Status: Spamassassin 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
-- 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
Hi, versuche doch mal ein mauelles fsck auf das /dev/mapper/cr_md126 Gerät. Gruß Uwe Eggert -- 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