fc18 : mounting encrypted intel bios raid partition hangs

[Carrot Cruncher]

i decided to rebuild my main server using fc18 (was running fc17). i've done a fresh install on the primary hard drive (using all the default settings) and applied all the latest updates. all the data is on an intel bios raid array. before updating the various config files i thought i'd just check i can mount the partition. so i do :

cryptsetup luksOpen /dev/md126p1 data

i provide the password and this completes successfully. i then do :

mount /dev/mapper/data /data (i've pre-created the /data directory)

this just hangs and there are no errors in any logs.

if i boot the same server to the fc18 live cd and do the same thing, the partition mounts successfully.

anyone know what the problem is, or how i can diagnose it further ? cheers.

[sea]

Once you have localy unlocked the luks partition, whats the output of:

ls /dev/mapper
# OR
lsblk

No need to post the result if you feel unconfortable with it.
But i assume to error to be a non existent entry in /dev/mapper, as my luks inside the lvm, is listed as /dev/mapper/$(hostname)-PARTNAME.
Maybe thats your issue.

hth

[Carrot Cruncher]

hi. /dev/mapper/data exists ok. there is no lvm on this raid array, it's just an encrypted partition. i thought i'd reinstall specifying the raid array during the installation, but this hits the anaconda/luks bug that has been reported on bugzilla many times. so i did a new installation on just the primary disk and didn't update any packages. following this i could mount the encrypted raid array fine. i then applied the updates and immediately the problem returned. so the problem is being caused by one of the following updates :

http://pastebin.com/uwk5tQg5

rather annoyingly there are a lot of them. so far i've tried downgrading the following :

dmraid
systemd
mdadm

as the most likely culprits but this hasn't resolved the problem. i'm going to work through the rest until it starts working again. this is going to be a painful process so if anyone has any suggestions as to which one (or more) it could be, it would be much appreciated.

[pnelsonsr]

Having much the same issue. A lot of times I can get it to boot by rebooting after the hang. Sometimes this takes a couple of tries. It is frustrating, but fedora is cutting edge... Arg!

[Carrot Cruncher]

after literally hours of testing i can confirm that, on my server, updating to any of the following :

mdadm-3.2.6-12.fc18

or (not and) :

libgudev1-197-1.fc18.x86_64
systemd-197-1.fc18.x86_64
systemd-libs-197-1.fc18.x86_64
systemd-sysv-197-1.fc18.x86_64

causes mounting the encrypted raid array to hang. i currently have all updates applied apart from :

mdadm-3.2.6-1.fc18.x86_64

libgudev1-195-15.fc18.x86_64
systemd-195-15.fc18.x86_64
systemd-libs-195-15.fc18.x86_64
systemd-sysv-195-15.fc18.x86_64

and everything is mounted ok.

i'll see if any further updates to these packages get released over the next few days, if not i'll raise a bug.

[pnelsonsr]

How did you do this downgrading?

[Carrot Cruncher]

yum downgrade {package}

[pnelsonsr]

And are you saying that downgrading just mdadm-3.2.6-1.fc18 was good enough even with the others installed?

...meaning -> any single one of those files installed will cause the same?

[Carrot Cruncher]

i've had to leave all the following packages at the lower level :

mdadm-3.2.6-1.fc18.x86_64

libgudev1-195-15.fc18.x86_64
systemd-195-15.fc18.x86_64
systemd-libs-195-15.fc18.x86_64
systemd-sysv-195-15.fc18.x86_64

if i update any of them i get the problem.

[pnelsonsr]

I'm glad you said that... I tried just mdadm... And things stayed about the same.

So I will downgrade all of them and hopefully that will make things more stable on an intel raid!

---------- Post added at 04:39 PM ---------- Previous post was at 04:05 PM ----------

Here is my downgraded package list

[me] rpm -qa | egrep 'mdadm|libgudev1|systemd-.*'|sort
libgudev1-195-15.fc18.i686
mdadm-3.2.6-1.fc18.i686
systemd-195-15.fc18.i686
systemd-libs-195-15.fc18.i686
systemd-sysv-195-15.fc18.i686

[chrismurphy]

What do you get for

mdadm -D /dev/md126

And do you get any messages at the time of the hang in dmesg? If nothing, it might be worth while to move to a debug kernel to find out what's happening.

You are dual booting Windows? Or this is only linux?

[Carrot Cruncher]

i've raised the following bugs :

https://bugzilla.redhat.com/show_bug.cgi?id=907149 (mdadm)
https://bugzilla.redhat.com/show_bug.cgi?id=907151 (systemd)

@chrismurphy. sorry, i missed your post (didn't get a notification). mdadm info is in the bugs. there are no errors displayed or in any logs. this is purely a linux server, no other operating systems.

[chrismurphy]

this is purely a linux server, no other operating systems.

I would not use IMSM (Intel BIOS RAID). There's no advantage to doing so if you aren't dual-booting.

From your /etc/fstab

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

Why are you setting x-systemd.device-timeout to zero seconds? This tells systemd to wait zero seconds before giving up on finding this entry. It sounds like the encrypted volume isn't yet available at the time systemd is ready to mount it either ro or rw; but I can't tell when your oops occurs. What happens when you remove this from the fstab?

Also, does your grub.cfg menu entry contain a kernel parameter using rd.luks.uuid=<uuid>?

[Carrot Cruncher]

@chrismurphy thanks again. following your comments i did some reading up on bios raid vs software raid and decided to take your advice and switch to software raid. having switched and recovered all my data i can confirm that i have been able to update both the mdadm and systemd packages without having the same problem.

@pnelsonsr as i've reconfigured my system i can't assist with the bug diagnostics for the original problem. if you want to get this working i'd suggest you work with the bug owners, they have requested some info.

[chrismurphy]

@chrismurphy thanks again. following your comments i did some reading up on bios raid vs software raid and decided to take your advice and switch to software raid. having switched and recovered all my data i can confirm that i have been able to update both the mdadm and systemd packages without having the same problem.

In effect BIOS RAID is software RAID, it's just that the BIOS can create/modify/destroy the metadata on disk, and help Windows along with the boot process in the early stage. But for linux, the md driver is what implements it using IMSM metadata on disk, instead of mdadm's metadata format. So in any case it's still md raid on Linux. It should work, as it's part of the release criteria for Fedora so it'd be kinda nice to know what actually solved the problem in case a bug needs to be filed.