linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: maarten <maarten@ultratux.net>
To: linux-raid@vger.kernel.org
Subject: combining two raid systems
Date: Thu, 13 Jan 2005 20:17:16 +0100	[thread overview]
Message-ID: <200501132017.16910.maarten@ultratux.net> (raw)


Hi,

I'm currently combing two servers into one, and I'm trying to figure out the 
safest way to do that.

System one had two md arrays: one raid-1 with the OS and a second one with 
data (raid-5)  It is bootable through lilo

System two had 9 arrays, one with the OS (raid-1) two raid-1's for swap, and 6 
md devices that belong in an LVM volume. This system has grub.

All md arrays are self-booting 0xFD partitions.

I want to boot off system one.  I verified that that boots fine if I 
disconnect all the [system-2] drives, so that's working okay. 

Now when I boot I get a lilo prompt, so I know the right disk is booted by the 
BIOS.  When logged in, I see only the md devices from system two, and thus 
the current md0 "/" drive is from system two.  Now what options do I have ?

If I zero the superblock(s) (or even the whole partitions) from md0 of system 
2, it will not boot off of that obviously, but what will now get to be md0 ? 
It could be the second array from system 2 equally well as the first array 
from system one, right ?

I could experiment with finding the right array by using different kernel 
root= commandlines, but only grub gives me that possibility, lilo has no 
boot-time shell (well, it has a commandline...)

Another thing that strikes me is that running 'mdadm --detail --scan' also 
only finds the arrays from system 2. Is that expected since it just reads 
its /etc/mdadm.conf file, or should it disregard that and show all arrays ?

Upon first glance 'fdisk -l' does show all devices fine (there are 10 of them)

I think (er, hope, actually) that with mdadm.conf one could probably force the 
machine to recognize the right drives as md0 as opposed to them being 
numbered mdX, but is that a right assumption ?  At the time the kernel md 
code reads / assembles the various 0xFD partitions, the root-partition is not 
mounted (obviously) so reading /etc/mdadm.conf will not be possible.

I'll start to try out some things but I _really_ want to avoid having an 
unbootable system: for one, this system has no CDrom nor floppy, and even 
more importantly I don't think my rescue media have all neccessary drivers 
for the ATA & SATA cards.

Anyone have some good advice for me ?

Maarten

-- 


             reply	other threads:[~2005-01-13 19:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-13 19:17 maarten [this message]
2005-01-13 19:57 ` combining two raid systems maarten
     [not found] ` <1105645254.3390.12.camel@south.rosestar.lan>
2005-01-13 20:27   ` maarten
2005-01-13 21:22     ` Derek Piper
2005-01-13 22:30       ` maarten
2005-01-13 23:04       ` Guy
2005-01-14 10:03         ` Robin Bowes
2005-01-13 23:46 ` berk walker
2005-01-14  1:01   ` maarten
2005-01-14  2:18 ` Neil Brown
2005-01-14  3:09   ` maarten

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200501132017.16910.maarten@ultratux.net \
    --to=maarten@ultratux.net \
    --cc=linux-raid@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).