Hi, Got the problems solved. I couldn't solve the problem by using the rescue disk, as it wouldn't let me stop the raid array. What I did was drop into the maintenance mode: mdadm --assemble /dev/md1 /dev/sdd1 /dev/sde1 //This should recreate the array mdadm --detail --scan >> /etc/mdadm/mdadm.conf
//edit the file to remove duplicates dpkg-reconfigure linux-image-$(uname -r) then reboot. Huge amount of thanks go to Bob Proulx for all the help along the way, James On 7 July 2013 21:53, James Allsopp <jamesaalls...@googlemail.com> wrote: > Hello, > I've been too nervous to reboot, so I've left it in the rescue mode at the > point where I assembled the raid arrays and went into boot at the \ > partition. > Tried to run: > mdadm --stop /dev/md127 > but got a mdadm: failed to stop array /dev/md127: Device or resource busy. > Perhaps a running process, mounted filesustem or active volume group? > > I tried unmounting /home which stretches onto this disk via LVM, but this > made no difference. Any idea how I should proceed? > Thanks, > James > > > > On 5 July 2013 01:10, Bob Proulx <b...@proulx.com> wrote: > >> James Allsopp wrote: >> > I'd like to hear about the optimisations, but I think I'll wait till I >> get >> > the system rebuilt! >> >> Basically I had expected you to use either rescue mode of the d-i or a >> livecd or other to assemble the arrays. You did. But neither array >> came up completely correct. One came up with one disk degraded. The >> split brain clone came up on md127 instead of md0. The other one came >> up on md126. So you should fix those using the discussed >> instructions. I was thinking you would do that from the same system >> boot that you had posted that information from. >> >> But your recent mail implies that you shut the system down and went >> away for a while. So now it appears you need to "rescue" the system >> again by the same method you used to get that information you posted. >> >> All of that is fine. Except now we already know the information you >> posted. And so now we know how those arrays are supposed to go >> together. But that is okay. You can go through rescue mode and >> assemble the arrays exactly as you did before. And then --stop the >> arrays and assemble them correctly. >> >> But since we know how they are supposed to be assembled now you could >> skip the assembly of them in rescue mode or livecd mode or whatever >> you used and simply assemble the arrays correctly the first time. >> Basically I think you are going to do: >> >> * rescue >> * assemble arrays >> * stop arrays >> * assemble arrays correctly >> >> Which is perfectly acceptable. The result will be fine. But now that >> we know what we need to do you could simply do this: >> >> * rescue >> * assemble arrays correctly >> >> But I don't want to distract you with complications like this! :-) >> >> And then after you get everything working you should visit the >> partitioning on that second array. Your partitioning starts at the >> sector 1. But that won't be aligned. It will cause all writes to be >> a read-modify-write and performance will suffer. >> >> > Device Boot Start End Blocks Id System >> > /dev/sdd1 1 243201 1953512001 fd Linux raid >> autodetect >> > Partition 1 does not start on physical sector boundary. >> > Device Boot Start End Blocks Id System >> > /dev/sde1 1 243201 1953512001 fd Linux raid >> autodetect >> > Partition 1 does not start on physical sector boundary. >> >> Instead of using the entire disk starting at 1 it would be much better >> if you started at sector 2048 as is the new standard for Advanced >> Format 4k sector drives. I would expect that to be a large >> performance lever on your system. But fix that after you have your >> data up and available. >> >> Bob >> > >
