-   Linux - Newbie (
-   -   Attempts to work around a mdadm bug/ mdadm cannot get exclusive access to /dev/md127 (

Sereph 08-15-2011 06:28 AM

Attempts to work around a mdadm bug/ mdadm cannot get exclusive access to /dev/md127
Greetings and salutations. First and foremost, assume I know absolutely nothing about linux. I've been a Windows user all my life, having been hooked while watching my father upgrade Windows 3.1.

I have worked with Windows 95, 98, 98SE, 2000, XP, Vista, Server 2008, and now Windows 7. Last night I took the plunge into insanity, purging my OS to start from scratch. My plan is a Windows 7 Professional installation dual-booting with Fedora 15.

*edit: Just realized I mentioned Windows in my post, and thus this post should have gone into General. My sincere apologies...

The first part of my plan was easy. I created a RAID 0 array in my BIOS, 3 drives. I created a NTFS partition on the array, leaving half the space unallocated, and installed Windows, knowing that GRUB would take over from the Windows boot-loader during my linux installation. All was well and good, then I installed Fedora 15 on the array's unallocated space, and after getting slightly confused, I worked my way through the installation. GRUB did exactly what I anticipated, defaulting to Fedora with the option of entering Windows. However, this is where everything went down the tube. Instead of taking me into Linux goodness where I could rest comfortably in the safety of a GUI, I got dumped into a Dracut debug prompt.

After feeling confused, and doing some searches, I muddled about, injecting random commands to get a feel for what I was dealing with. After booting from my USB drive, I discovered that my installation could not find my root. Further poking revealed that I was dealing with the following problem:

dracut: mdadm (IMSM): Unsupported attributes: 40000000
dracut: mdadm IMSM metadata load not allowed due to attribute incompatibility

Which apparently is a known problem...just my luck.

The solution given is as follows: "You would need to boot up a
live cd or rescue image, use mdadm -E to get the exact info for your array,then recreate the array with the exact same options as it currently uses but passing in the --assume-clean option, then reboot to your arrays with the trouble causing bit cleared."

Not really knowing what I was doing, and coming from an MS-DOS command line background, I managed to isolate my array details with the following: # mdadm --examine /dev/md0
After painstakingly writing down EVERYTHING, just in case, I then attempted to create a new array per the following:
# mdadm --create /dev/md0 --chunk=128 --level=0 --raid-devices=3 /dev/sda /dev/sda1 /dev/sda2 --assume-clean

This however lead to some message about the array being in use or some such nonsense. I'm assuming at this point that was due to the fact that when I booted from the USB, I had performed the following: # chroot /mnt/sysimage

So logically, if I can unmount or somehow stop the array, I can proceed with my workaround. However, # mdadm --stop /dev/md0 informs me thusly: mdadm: Cannot stop container /dev/md0: member md127 still active

So from there I tried # mdadm --stop /dev/md127, but that lead to a message stating that mdadm: Cannot get exclusive access to /dev/md127: possibly it is still in use.

So from here I'm stumped... I want to keep my hardware-based array for Windows' sake, but I also want to get this miserable workaround in order. It is a legitimate bug that I'm dealing with, but it would be nice if I could do something that does not involve waiting on a new mdadm release.

Any help or suggestions for my predicament would be appreciated. Thus far my first linux experience has been less than productive... :)

Sereph 08-16-2011 03:21 AM

Just an update. I didn't manage to employ the workaround, so I scrapped Fedora and went with Ubuntu. It works, I'm happy.

All times are GMT -5. The time now is 01:41 PM.