please note that updating mdadm causes the same problem, see bug :
https://bugzilla.redhat.com/show_bug.cgi?id=907149

also, as per this thread :
http://forums.fedoraforum.org/showthread.php?t=288148
at least one other user is having the same problem.

From what I can tell from your post, the mdadm device appears to be working normally.  It's just the mount program that is hanging (and we don't really know why).  Can you run strace on the mount command and see where it hangs?

*** Bug 907149 has been marked as a duplicate of this bug. ***

Given that this happens both with updating systemd and mdadm, I think it
likely to be a problem outside of mdadm

Are you able to mount the encrypted file system on the command line post boot,
or is it your root file system?

Could you post the output of /proc/mounts on a system that is fully mounted
please?

Thanks,
Jes

following a suggestion in the forums i've rebuilt the array using software raid and i'm no longer having the problem after updating both the mdadm and systemd packages. having done this i've realised that i can no longer assist with any diagnostics. i've asked in the forums if someone else having the problem can provide the info you have requested.

(In reply to comment #5)
> following a suggestion in the forums i've rebuilt the array using software
> raid and i'm no longer having the problem after updating both the mdadm and
> systemd packages. having done this i've realised that i can no longer assist
> with any diagnostics. i've asked in the forums if someone else having the
> problem can provide the info you have requested.

Can you elaborate a little please? I will try to recreate the problem on one
of my test systems, but I will need more information.

You now have a system using regular md software raid, and this is encrypted
too?

Was the original BIOS raid causing the problem used for the / partition, or
was it only used for say /home?

Thanks,
Jes

originally the raid array was being presented by imsm bios raid from the motherboard. i disabled this, so i just got 4 normal disks presented by the bios, and them created a new software raid array using mdadm :

mdadm --create --verbose /dev/md0 --level=5 --raid-devices=4 /dev/sdb /dev/sdc /dev/sdd /dev/sde

i then encrypted the device, as i had before, using :

cryptsetup luksFormat /dev/md0

and finally, created an ext4 filesystem using  :

mkfs.ext4 /dev/mapper/luks-`cryptsetup luksUUID /dev/md0

the filesystem doesn't contain any of the base os, it's just a load of data which i mount on /data.

hope that helps.

I have what appear to be the same issue (Intel bios raid not mounting after update), with the variation that my filesystem is not encrypted.

Rolling back the packages described allowed me to mount the file system again (as /run/media/osmestad/dataRAID) using root password.

A clean install of FC18 gave one SELinux error that might be related (though it complains for /dev/md127 my RAID should be /dev/md126).

If I can be of any help, I'll try my best :)

Cheers
Øyvind


***********************************************************
Raid info (now mounted successfully):
$ su -c 'mdadm -D /dev/md127'
/dev/md127:
        Version : imsm
     Raid Level : container
  Total Devices : 2

Working Devices : 2


           UUID : 3f2be617:6ab3d000:3aa4cdcc:ef1d4ec2
  Member Arrays : /dev/md/DataRaid_0

    Number   Major   Minor   RaidDevice

       0       8       16        -        /dev/sdb
       1       8       32        -        /dev/sdc


$ su -c 'mdadm -D /dev/md126'
/dev/md126:
      Container : /dev/md/imsm0, member 0
     Raid Level : raid1
     Array Size : 1953511424 (1863.01 GiB 2000.40 GB)
  Used Dev Size : 1953511556 (1863.01 GiB 2000.40 GB)
   Raid Devices : 2
  Total Devices : 2

          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0


           UUID : f5f0553f:8da9c2fd:c5ded372:b64fa38f
    Number   Major   Minor   RaidDevice State
       1       8       16        0      active sync   /dev/sdb
       0       8       32        1      active sync   /dev/sdc


***********************************************************************

SELinux errror:

SELinux is preventing /usr/sbin/setfiles from 'read, write' accesses on the blk_file /dev/md127.

*****  Plugin leaks (86.2 confidence) suggests  ******************************

If you want to ignore setfiles trying to read write access the md127 blk_file, because you believe it should not need this access.
Then you should report this as a bug.  
You can generate a local policy module to dontaudit this access.
Do
# grep /usr/sbin/setfiles /var/log/audit/audit.log | audit2allow -D -M mypol
# semodule -i mypol.pp

*****  Plugin catchall (14.7 confidence) suggests  ***************************

If you believe that setfiles should be allowed read write access on the md127 blk_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep restorecon /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c102
                             3
Target Context                system_u:object_r:fixed_disk_device_t:s0
Target Objects                /dev/md127 [ blk_file ]
Source                        restorecon
Source Path                   /usr/sbin/setfiles
Port                          <Unknown>
Host                          localhost
Source RPM Packages           policycoreutils-2.1.13-44.fc18.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.11.1-66.fc18.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     localhost.localdomain
Platform                      Linux localhost.localdomain 3.6.10-4.fc18.x86_64
                             #1 SMP Tue Dec 11 18:01:27 UTC 2012 x86_64 x86_64
Alert Count                   1
First Seen                    2013-02-07 13:31:31 EST
Last Seen                     2013-02-07 13:31:31 EST
Local ID                      df056e16-1aef-4154-bc86-037e25fabe20

Raw Audit Messages
type=AVC msg=audit(1360261891.129:350): avc:  denied  { read write } for  pid=11630 comm="restorecon" path="/dev/md127" dev="devtmpfs" ino=16439 scontext=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file


type=SYSCALL msg=audit(1360261891.129:350): arch=x86_64 syscall=execve success=yes exit=0 a0=11a18d0 a1=11a1970 a2=11a2260 a3=7fffe1662850 items=0 ppid=11629 pid=11630 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm=restorecon exe=/usr/sbin/setfiles subj=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023 key=(null)

Hash: restorecon,setfiles_t,fixed_disk_device_t,blk_file,read,write

audit2allow
audit2allow -R

Øyvind,

Can you elaborate a bit on your setup, please?

If I understand correctly, the BIOS RAID is not used as your / partition, just
for data? Can you provide /proc/mounts from a booted system?

Also exactly which mdadm/dracut package did you install? Could you check with
the latest packages listed here:

https://admin.fedoraproject.org/updates/dracut-024-25.git20130205.fc18,mdadm-3.2.6-14.fc18

Thanks,
Jes

Hi Jes,

When installing the linked versions of dracut and mdadm from updates-testing it worked for me! (installing the systemd updates from 'updates' afterwards did not break mounting either)

If you are still interested, here is the info about my system:

My system has a small SSD (30GB) for OS/programs and two normal drives (2TB) setup in RAID 1 for storing data (the data drives are not listed in my /etc/fstab).

[osmestad@localhost ~]$ lsblk
NAME                   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                      8:0    0 29.8G  0 disk
├─sda1                   8:1    0  500M  0 part /boot
└─sda2                   8:2    0 29.3G  0 part
 ├─fedora-swap (dm-0) 253:0    0  5.8G  0 lvm  [SWAP]
 └─fedora-root (dm-1) 253:1    0 23.5G  0 lvm  /
sdb                      8:16   0  1.8T  0 disk
└─sdb1                   8:17   0  1.8T  0 part
sdc                      8:32   0  1.8T  0 disk
└─sdc1                   8:33   0  1.8T  0 part
sr0                     11:0    1 1024M  0 rom


My /proc/mounts reads as follows:

[osmestad@localhost ~]$ cat /proc/mounts
rootfs / rootfs rw 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devtmpfs /dev devtmpfs rw,seclabel,nosuid,size=3034272k,nr_inodes=758568,mode=755 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0
tmpfs /dev/shm tmpfs rw,seclabel,nosuid,nodev 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,seclabel,nosuid,nodev,mode=755 0 0
tmpfs /sys/fs/cgroup tmpfs rw,seclabel,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpuacct,cpu 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/net_cls cgroup rw,nosuid,nodev,noexec,relatime,net_cls 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0
/dev/mapper/fedora-root / ext4 rw,seclabel,relatime,data=ordered 0 0
rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=29,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
mqueue /dev/mqueue mqueue rw,seclabel,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,seclabel,relatime 0 0
configfs /sys/kernel/config configfs rw,relatime 0 0
tmpfs /tmp tmpfs rw,seclabel 0 0
/dev/sda1 /boot ext4 rw,seclabel,relatime,data=ordered 0 0
gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
/dev/md126p1 /run/media/osmestad/dataRAID ext4 rw,seclabel,nosuid,nodev,relatime,data=ordered 0 0

Cheers
Øyvind

Øyvind,

Thanks for the info, I am happy it is working for you now. I am going to
try out on a test machine here when I have some time, but it sounds like the
problem might be resolved.

Cheers,
Jes

I have the exact same problem but for an unecrypted volume. I'm using Intel hardware raid and my /data mountpoint which was working fine in Fedora 17 causes mount to hang with no errors in Fedora 18. I've been able to get /data to mount on Fedora 18 by downgrading the packages recommended in http://forums.fedoraforum.org/showthread.php?t=288148 

Some system info:
[root@localhost ~]# mdadm /dev/md126
/dev/md126: 931.51GiB raid1 2 devices, 0 spares. Use mdadm --detail for more detail.

[root@localhost ~]# pvscan
  PV /dev/sda5      VG fedora    lvm2 [65.75 GiB / 0    free]
  PV /dev/md126p2   VG vg_data   lvm2 [804.82 GiB / 4.82 GiB free]
  Total: 2 [870.57 GiB] / in use: 2 [870.57 GiB] / in no VG: 0 [0   ]

[root@localhost ~]# vgdisplay vg_data
  --- Volume group ---
  VG Name               vg_data
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  2
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               804.82 GiB
  PE Size               4.00 MiB
  Total PE              206035
  Alloc PE / Size       204800 / 800.00 GiB
  Free  PE / Size       1235 / 4.82 GiB
  VG UUID               9i0466-rUTb-PpEw-UMiU-fhaf-z9uj-kisg15

----
Mount command that hangs (before packages downgraded):
mount /dev/vg_data/data /data

---

[root@localhost ~]# lspci|grep RAID
00:1f.2 RAID bus controller: Intel Corporation 82801 SATA Controller [RAID mode] (rev 05)
08:00.0 IDE interface: Marvell Technology Group Ltd. 88SE9172 SATA III 6Gb/s RAID Controller (rev 11)

---
[geoff@localhost ~]$ cat /proc/mounts
rootfs / rootfs rw 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devtmpfs /dev devtmpfs rw,seclabel,nosuid,size=8191540k,nr_inodes=2047885,mode=755 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0
tmpfs /dev/shm tmpfs rw,seclabel,nosuid,nodev 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,seclabel,nosuid,nodev,mode=755 0 0
tmpfs /sys/fs/cgroup tmpfs rw,seclabel,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpuacct,cpu 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/net_cls cgroup rw,nosuid,nodev,noexec,relatime,net_cls 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0
/dev/mapper/fedora-root / ext4 rw,seclabel,relatime,data=ordered 0 0
rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=31,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
mqueue /dev/mqueue mqueue rw,seclabel,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,seclabel,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
tmpfs /tmp tmpfs rw,seclabel 0 0
configfs /sys/kernel/config configfs rw,relatime 0 0
/dev/sda3 /boot ext4 rw,seclabel,relatime,data=ordered 0 0
/dev/mapper/fedora-home /home ext4 rw,seclabel,relatime,data=ordered 0 0
----- Offending mount that hangs -----
/dev/mapper/vg_data-data /data ext4 rw,seclabel,relatime,data=ordered 0 0
----
gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0

I have tried reproducing your setup, but I am not seeing the same problem
here. Basically I did a fresh Fedora 18 install onto LVM on a regular
disk, then adding an encrypted partition from an IMSM BIOS RAID array as
/data. If comes up as expected

ps aux|grep dmon
root        539  0.0  0.1  15040 10940 ?        SLsl 11:58   0:00 @sbin/mdmon --foreground md127
root       1319  0.0  0.0 109152   632 ttyS0    D+   11:58   0:00 grep --color=auto dmon
[root@noisybay ~]# cat /proc/mdstat
Personalities : [raid1] 
md126 : active raid1 sda[1] sdb[0]
      31457280 blocks super external:/md127/0 [2/2] [UU]
      
md127 : inactive sdb[1](S) sda[0](S)
      6306 blocks super external:imsm
       
unused devices: <none>
[root@noisybay ~]# rpm -q mdadm systemd
mdadm-3.2.6-14.fc18.x86_64
systemd-197-1.fc18.2.x86_64

Those of you having problems, could you try and run 'ps aux |grep dmon'
when you end up in the shell where things aren't working?

Thanks,
Jes

30 days and no replies to my request - I assume the problem is solved then....

Still happens for me. If you haven't made any fixes then the issue still stands.

Because I've rolled back the packages, I can't reproduce the problem. And as I depend on this server I can't roll the packages forward until the problem is fixed. I can assist by doing a hardware dump etc.  

Here is a 'lspci' of my system which has the problem for starters:
[geoff@system~]$ lspci
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b5)
00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 (rev b5)
00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b5)
00:1c.5 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 6 (rev b5)
00:1c.6 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 7 (rev b5)
00:1c.7 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 8 (rev b5)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a5)
00:1f.0 ISA bridge: Intel Corporation Z68 Express Chipset Family LPC Controller (rev 05)
00:1f.2 RAID bus controller: Intel Corporation 82801 SATA Controller [RAID mode] (rev 05)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05)
01:00.0 VGA compatible controller: NVIDIA Corporation GF116 [GeForce GTX 550 Ti] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GF116 High Definition Audio Controller (rev a1)
03:00.0 PCI bridge: Integrated Technology Express, Inc. Device 8892 (rev 10)
04:00.0 Multimedia audio controller: C-Media Electronics Inc CMI8788 [Oxygen HD Audio]
04:02.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0)
05:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01)
06:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01)
07:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
08:00.0 IDE interface: Marvell Technology Group Ltd. 88SE9172 SATA III 6Gb/s RAID Controller (rev 11)
[geoff@gnuell ~]$ lspci
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b5)
00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 (rev b5)
00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b5)
00:1c.5 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 6 (rev b5)
00:1c.6 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 7 (rev b5)
00:1c.7 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 8 (rev b5)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a5)
00:1f.0 ISA bridge: Intel Corporation Z68 Express Chipset Family LPC Controller (rev 05)
00:1f.2 RAID bus controller: Intel Corporation 82801 SATA Controller [RAID mode] (rev 05)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05)
01:00.0 VGA compatible controller: NVIDIA Corporation GF116 [GeForce GTX 550 Ti] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GF116 High Definition Audio Controller (rev a1)
03:00.0 PCI bridge: Integrated Technology Express, Inc. Device 8892 (rev 10)
04:00.0 Multimedia audio controller: C-Media Electronics Inc CMI8788 [Oxygen HD Audio]
04:02.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0)
05:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01)
06:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01)
07:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
08:00.0 IDE interface: Marvell Technology Group Ltd. 88SE9172 SATA III 6Gb/s RAID Controller (rev 11)

Given I haven't been able to reproduce the bug, it's rather hard for me to do
something without testing. That said, I spot a Marvell SATA controller in the
above config - how are your disks in the raid arrays wired in?

Are they sitting on the Marvell, on the onboard or on both?

I have been playing more with this, trying to reproduce the problem you guys
are seeing, however I still can't reproduce it here.

I dug out a spare Marvell controller I had in the pile of test devices, though
not the same model as Geoff's. I created a RAID5 across disks on the Marvell
and on a drive sitting on the AHCI controller and mount this device on boot.

I also added the mounting of a partition sitting on top of LVM which is again
sitting on the IMSM RAID.

Everything behaves as expected:

[root@noisybay ~]# df -h
Filesystem                          Size  Used Avail Use% Mounted on
devtmpfs                            3.8G     0  3.8G   0% /dev
tmpfs                               3.8G     0  3.8G   0% /dev/shm
tmpfs                               3.8G  4.9M  3.8G   1% /run
tmpfs                               3.8G     0  3.8G   0% /sys/fs/cgroup
/dev/sdc7                            50G  4.1G   43G   9% /
tmpfs                               3.8G     0  3.8G   0% /tmp
/dev/sdc6                           477M   69M  383M  16% /boot
/dev/sdc9                           489G   33M  489G   1% /home
/dev/md125                           55G   52M   52G   1% /mnt2
/dev/mapper/fedora_noisybay00-root   22G  6.5G   15G  32% /mnt

[root@noisybay ~]# ls -al /dev/mapper/fedora_noisybay00-root 
lrwxrwxrwx. 1 root root 7 Apr 18 11:06 /dev/mapper/fedora_noisybay00-root -> ../dm-2

[root@noisybay ~]# cat /proc/mdstat 
Personalities : [raid1] [raid6] [raid5] [raid4] 
md125 : active raid5 sdc10[0] sde1[2] sdd1[1] sdf1[4]
      58529280 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      
md126 : active (auto-read-only) raid1 sda[1] sdb[0]
      31457280 blocks super external:/md127/0 [2/2] [UU]
      
md127 : inactive sda[1](S) sdb[0](S)
      6306 blocks super external:imsm

sdc is a drive sitting on the internal AHCI
sd[def] are attached to the marvell

[root@noisybay ~]# pvdisplay 
  --- Physical volume ---
  PV Name               /dev/sdc3
  VG Name               fedora_noisybay
  PV Size               39.07 GiB / not usable 3.00 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              10001
  Free PE               1
  Allocated PE          10000
  PV UUID               DxUr3o-32zb-SGRf-oLFK-VJFR-ef1k-O6QHC6
   
  --- Physical volume ---
  PV Name               /dev/md126p2
  VG Name               fedora_noisybay00
  PV Size               29.51 GiB / not usable 3.00 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              7554
  Free PE               0
  Allocated PE          7554
  PV UUID               NrK0En-c0rB-GyiO-4Ffl-vrpy-rnPU-wRDSJL

[root@noisybay ~]# rpm -q mdadm dracut systemd
mdadm-3.2.6-14.fc18.x86_64
dracut-024-25.git20130205.fc18.x86_64
systemd-197-1.fc18.2.x86_64

So the question is, what is different on your systems compared to mine?

Hi,

I have been running more tests on this, doing fresh Fedora 18 (and 19) installs
with all the latest updates onto an encrypted LUKS device sitting on top of LVM
on top of IMSM BIOS RAID.

I am seeing nothing unexpected, the devices come up as expected.

If anyone is still seeing this problem with the latest updates applied, please
hollor. Otherwise I will close this BZ shortly.

Thanks,
Jes

Closing per comment #18

Please close ths bug