Hallo zusammen, Norbert Zawodsky meinte am Donnerstag, den 28.03.2013 um 13:08 Uhr wegen:nach 12.2->12.3 kann LUKS hd nicht mehr ansprechen
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...
Ich hatte mit einer Luks-Partition nach Installation von OS 12.3 das Problem, das diese nicht durch pam_mount eingehängt werden konnte. Bei nachträglich mounten mit mount.crypt ga es auch Fehlermeldungen. Das Einhängen mit dem yast-paritionierer ebenfalls, der konnte aber die Partition einhängen. Beim Zugriff auf die Dann eingehängte Partition waren dann die meisten Verzeichnisse leer und wurden im mc rot markiert. Ich habe die Partition ausgehängt, mit luskopen geöffnet und fsck drauf losgelassen. Es wurden unzählige Fehler gefunden und automatisch repariert. Danach konnte ich alle Daten auf eine neue Partition kopieren. Wenn Du gar keinen Zugriff mehr hast, geht auch keine Datensicherung mehr. Nicht mal mit dd. Dann würde ich zunächst prüfen, ob Du mit cryptsetup luksopen die Partition mappen kann und dann fsck laufen lassen. -- Beste Grüße Christian Gut, das Audacious gerade von 1 - Alanah Miles - Black Velvet-One Hit Wonders Of The 90's - spielt :music: -- 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