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: