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 -- www.teddylinx.de -- 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