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... :)
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 02:39 PM.|