DescriptionDmitry Guryanov
2013-02-14 22:05:35 UTC
Created attachment 697430[details]
dmesg
Description of problem:
I have intel's raid array on my system, which works as md device. I have following line in /etc/fstab for it:
/dev/md/Volume0_0p2 /home ext4 defaults 0 0
All worked fine until I've updated fedora on 27 Jan - system hang on boot for several minutes and then suggested to enter root password and resolve problems with mounting /home.
So here is what's happening, if I disable that line in /etc/fstab and try to mount /dev/md/Volume0_0p2 by hands:
1. here is /proc/mdstat:
[root@hex ~]# cat /proc/mdstat
Personalities : [raid1]
md126 : active (auto-read-only) raid1 sda[1] sdb[0]
1953511424 blocks super external:/md127/0 [2/2] [UU]
md127 : inactive sdb[1](S) sda[0](S)
6056 blocks super external:imsm
unused devices: <none>
md126 in auto-read-only state
2. try to mount:
[root@hex ~]# mount /dev/md126p2 /mnt
... hangs forever
[root@hex ~]# ps -C mount -o pid,state
PID S
2839 D
mount process hangs in D state, check its stack:
[root@hex ~]# cat /proc/2839/stack
[<ffffffff814b9c45>] md_write_start+0xa5/0x1c0
[<ffffffffa0163ab8>] make_request+0x48/0xc70 [raid1]
[<ffffffff814b24f3>] md_make_request+0xc3/0x200
[<ffffffff812c8432>] generic_make_request+0xc2/0x110
[<ffffffff812c84f9>] submit_bio+0x79/0x160
[<ffffffff811c4e74>] submit_bh+0x114/0x1e0
[<ffffffff811c66e7>] __sync_dirty_buffer+0x57/0xd0
[<ffffffff811c6773>] sync_dirty_buffer+0x13/0x20
[<ffffffff81236d38>] ext4_commit_super+0x1d8/0x250
[<ffffffff812390e9>] ext4_setup_super+0x129/0x1a0
[<ffffffff8123c50b>] ext4_fill_super+0x277b/0x2fa0
[<ffffffff811980d5>] mount_bdev+0x1c5/0x210
[<ffffffff81228725>] ext4_mount+0x15/0x20
[<ffffffff81198dc3>] mount_fs+0x43/0x1b0
[<ffffffff811b209f>] vfs_kern_mount+0x6f/0x100
[<ffffffff811b2b14>] do_kern_mount+0x54/0x110
[<ffffffff811b4675>] do_mount+0x315/0x8e0
[<ffffffff811b4cce>] sys_mount+0x8e/0xe0
[<ffffffff8163f2d9>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
process hangs on line
wait_event(mddev->sb_wait,
!test_bit(MD_CHANGE_PENDING, &mddev->flags));
in drivers/md/md.c
Then if I write active to /sys/devices/virtual/block/md126/md/array_state
[root@hex ~]# echo active > /sys/devices/virtual/block/md126/md/array_state
md126 will become active and mount will succesfully finish:
[root@hex ~]# cat /proc/mdstat
Personalities : [raid1]
md126 : active raid1 sda[1] sdb[0]
1953511424 blocks super external:/md127/0 [2/2] [UU]
md127 : inactive sdb[1](S) sda[0](S)
6056 blocks super external:imsm
unused devices: <none>
Just after that update I've tried to boot the older kernel (which was before update) and got the same problem, that I tried vanilla kernel 3.8 mount hang as with fedora kernel. So I decided that this is a problem with systemd.
Version-Release number of selected component (if applicable):
Seems appeared in systemd-197-1.fc18.1.x86_64, but not shure
How reproducible:
always on my system (10/10)
Actual results:
system boot hangs and mount fails
Expected results:
system boots successfully and md array mounted after boot.
Additional info:
Created attachment 697430 [details] dmesg Description of problem: I have intel's raid array on my system, which works as md device. I have following line in /etc/fstab for it: /dev/md/Volume0_0p2 /home ext4 defaults 0 0 All worked fine until I've updated fedora on 27 Jan - system hang on boot for several minutes and then suggested to enter root password and resolve problems with mounting /home. So here is what's happening, if I disable that line in /etc/fstab and try to mount /dev/md/Volume0_0p2 by hands: 1. here is /proc/mdstat: [root@hex ~]# cat /proc/mdstat Personalities : [raid1] md126 : active (auto-read-only) raid1 sda[1] sdb[0] 1953511424 blocks super external:/md127/0 [2/2] [UU] md127 : inactive sdb[1](S) sda[0](S) 6056 blocks super external:imsm unused devices: <none> md126 in auto-read-only state 2. try to mount: [root@hex ~]# mount /dev/md126p2 /mnt ... hangs forever [root@hex ~]# ps -C mount -o pid,state PID S 2839 D mount process hangs in D state, check its stack: [root@hex ~]# cat /proc/2839/stack [<ffffffff814b9c45>] md_write_start+0xa5/0x1c0 [<ffffffffa0163ab8>] make_request+0x48/0xc70 [raid1] [<ffffffff814b24f3>] md_make_request+0xc3/0x200 [<ffffffff812c8432>] generic_make_request+0xc2/0x110 [<ffffffff812c84f9>] submit_bio+0x79/0x160 [<ffffffff811c4e74>] submit_bh+0x114/0x1e0 [<ffffffff811c66e7>] __sync_dirty_buffer+0x57/0xd0 [<ffffffff811c6773>] sync_dirty_buffer+0x13/0x20 [<ffffffff81236d38>] ext4_commit_super+0x1d8/0x250 [<ffffffff812390e9>] ext4_setup_super+0x129/0x1a0 [<ffffffff8123c50b>] ext4_fill_super+0x277b/0x2fa0 [<ffffffff811980d5>] mount_bdev+0x1c5/0x210 [<ffffffff81228725>] ext4_mount+0x15/0x20 [<ffffffff81198dc3>] mount_fs+0x43/0x1b0 [<ffffffff811b209f>] vfs_kern_mount+0x6f/0x100 [<ffffffff811b2b14>] do_kern_mount+0x54/0x110 [<ffffffff811b4675>] do_mount+0x315/0x8e0 [<ffffffff811b4cce>] sys_mount+0x8e/0xe0 [<ffffffff8163f2d9>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff process hangs on line wait_event(mddev->sb_wait, !test_bit(MD_CHANGE_PENDING, &mddev->flags)); in drivers/md/md.c Then if I write active to /sys/devices/virtual/block/md126/md/array_state [root@hex ~]# echo active > /sys/devices/virtual/block/md126/md/array_state md126 will become active and mount will succesfully finish: [root@hex ~]# cat /proc/mdstat Personalities : [raid1] md126 : active raid1 sda[1] sdb[0] 1953511424 blocks super external:/md127/0 [2/2] [UU] md127 : inactive sdb[1](S) sda[0](S) 6056 blocks super external:imsm unused devices: <none> Just after that update I've tried to boot the older kernel (which was before update) and got the same problem, that I tried vanilla kernel 3.8 mount hang as with fedora kernel. So I decided that this is a problem with systemd. Version-Release number of selected component (if applicable): Seems appeared in systemd-197-1.fc18.1.x86_64, but not shure How reproducible: always on my system (10/10) Actual results: system boot hangs and mount fails Expected results: system boots successfully and md array mounted after boot. Additional info: