Bug 907151 - update to systemd causes mounting of encrypted intel bios raid array to hang [NEEDINFO]
update to systemd causes mounting of encrypted intel bios raid array to hang
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: mdadm (Show other bugs)
18
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Jes Sorensen
Fedora Extras Quality Assurance
:
: 907149 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-03 08:15 EST by Tibbs Brookside
Modified: 2013-11-06 10:28 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-06 10:28:35 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Jes.Sorensen: needinfo? (geoffnewell)


Attachments (Terms of Use)

  None (edit)
Description Tibbs Brookside 2013-02-03 08:15:06 EST
Description of problem:
mounting an encrypted intel bios raid array hangs after the following updates :
libgudev1-195-15.fc18.x86_64 to libgudev1-197-1.fc18.x86_64
systemd-195-15.fc18.x86_64 to systemd-197-1.fc18.x86_64
systemd-libs-195-15.fc18.x86_64 to systemd-libs-197-1.fc18.x86_64
systemd-sysv-195-15.fc18.x86_64 to systemd-sysv-197-1.fc18.x86_64

Version-Release number of selected component (if applicable):
see above

How reproducible:
100%

Steps to Reproduce:
1. install fc18 on server with existing array (that was running fc17).
2. update the systemd package (and it's dependencies)
3. try to mount filesystem
  
Actual results:
mount command hangs. no errors in any logs.

Expected results:
filesystem should mount

Additional info:
i can opens the luks device ok. other info that may be useful :

mdadm -D /dev/md127
/dev/md127:
        Version : imsm
     Raid Level : container
  Total Devices : 4

Working Devices : 4


           UUID : 3936b762:57f0fc35:dcb179b9:f5bb1675
  Member Arrays : /dev/md/Volume0_0

    Number   Major   Minor   RaidDevice

       0       8       32        -        /dev/sdc
       1       8       48        -        /dev/sdd
       2       8       64        -        /dev/sde
       3       8       16        -        /dev/sdb

mdadm -D /dev/md126
/dev/md126:
      Container : /dev/md/imsm0, member 0
     Raid Level : raid5
     Array Size : 2930280448 (2794.53 GiB 3000.61 GB)
  Used Dev Size : 976760320 (931.51 GiB 1000.20 GB)
   Raid Devices : 4
  Total Devices : 4

          State : active 
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-asymmetric
     Chunk Size : 64K


           UUID : 67651b3e:5d9144be:c79d629e:f907af03
    Number   Major   Minor   RaidDevice State
       3       8       16        0      active sync   /dev/sdb
       2       8       32        1      active sync   /dev/sdc
       1       8       48        2      active sync   /dev/sdd
       0       8       64        3      active sync   /dev/sde

/etc/crypttab 
luks-7425e393-21ac-4f25-be4a-458eb968aaaf UUID=7425e393-21ac-4f25-be4a-458eb968aaaf none

/etc/fstab
/dev/mapper/luks-7425e393-21ac-4f25-be4a-458eb968aaaf  /data      ext4    defaults,x-systemd.device-timeout=0 1 2

dumpe2fs -h /dev/dm-4
dumpe2fs 1.42.5 (29-Jul-2012)
Filesystem volume name:   <none>
Last mounted on:          /data
Filesystem UUID:          6c305a06-927c-438c-ad4d-9ba5e84acaec
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              183148544
Block count:              732569563
Reserved block count:     36628478
Free blocks:              404976428
Free inodes:              182924049
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      849
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
RAID stride:              16
RAID stripe width:        48
Flex block group size:    16
Filesystem created:       Sat Jan 28 05:03:11 2012
Last mount time:          Sun Feb  3 12:50:06 2013
Last write time:          Sun Feb  3 12:50:06 2013
Mount count:              15
Maximum mount count:      23
Last checked:             Mon Jan 28 20:14:15 2013
Check interval:           15552000 (6 months)
Next check after:         Sat Jul 27 21:14:15 2013
Lifetime writes:          5224 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:	          256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      13f95ee5-1ba6-4574-8351-c305c5e32a53
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Journal size:             128M
Journal length:           32768
Journal sequence:         0x007ae9d8
Journal start:            1
Comment 1 Tibbs Brookside 2013-02-03 08:17:27 EST
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.
Comment 2 Doug Ledford 2013-02-04 13:27:57 EST
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?
Comment 3 Doug Ledford 2013-02-04 13:31:50 EST
*** Bug 907149 has been marked as a duplicate of this bug. ***
Comment 4 Jes Sorensen 2013-02-05 03:31:48 EST
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
Comment 5 Tibbs Brookside 2013-02-05 04:36:28 EST
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.
Comment 6 Jes Sorensen 2013-02-05 05:06:39 EST
(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
Comment 7 Tibbs Brookside 2013-02-05 05:16:06 EST
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.
Comment 8 Øyvind Smestad 2013-02-10 15:57:25 EST
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
Comment 9 Jes Sorensen 2013-02-11 04:54:52 EST
Ø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
Comment 10 Øyvind Smestad 2013-02-11 15:56:45 EST
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
Comment 11 Jes Sorensen 2013-02-13 06:03:31 EST
Ø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
Comment 12 geoffnewell 2013-02-17 07:52:49 EST
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
Comment 13 Jes Sorensen 2013-03-11 12:01:00 EDT
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
Comment 14 Jes Sorensen 2013-04-10 10:57:50 EDT
30 days and no replies to my request - I assume the problem is solved then....
Comment 15 geoffnewell 2013-04-10 13:46:48 EDT
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)
Comment 16 Jes Sorensen 2013-04-11 07:58:14 EDT
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?
Comment 17 Jes Sorensen 2013-04-18 05:12:20 EDT
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?
Comment 18 Jes Sorensen 2013-10-11 08:09:33 EDT
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
Comment 19 Jes Sorensen 2013-11-06 10:28:35 EST
Closing per comment #18

Note You need to log in before you can comment on or make changes to this bug.