[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian machine not booting



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 <jamesaallsopp@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 <bob@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



Reply to: