From: Michael Tokarev <mjt@tls.msk.ru>
To: "Cress, Andrew R" <andrew.r.cress@intel.com>
Cc: donj@asaca.com, linux-raid@vger.kernel.org
Subject: Re: Booting from a raid1 device ?
Date: Thu, 30 Oct 2003 17:26:31 +0300 [thread overview]
Message-ID: <3FA11F97.4020800@tls.msk.ru> (raw)
In-Reply-To: <E5DA6395B8F9614EB7A784D628184B200E33E8@hdsmsx402.hd.intel.com>
Cress, Andrew R wrote:
> Michael,
>
> If you only have an MBR on the first disk, and it fails, your system
> will not boot, since BIOS won't be able to read an MBR from the
> redundant disk (the only working one). You may be thinking of a use
> case in which the first disk has a corrupted partition, but its MBR is
> intact.
Corrupted boot partition - yes. If it contains corrupted MBR, it
will not boot either, because BIOS will not try 2nd disk anyway
(if 1st disk "half-works"). None of current bootloaders support
"fallback" (or redundrand) boot (e.g. try first disk, if read
fails or bad checksum, try another disk etc). That to say: with
half-working disk, nothing will work. Note that it is the loader
itself plus the kernel image that (and MBR) that should have
failed - if all this (pretty small) stuff is ok (but there's
a bad block or many bad blocks but elsewhere on the disk), system
will boot just fine.
> You have to also have a working MBR on the redundant disk as well, or
> you'll never get to the loader if the first disk really fails. Usually
> it is the loader's responsibility to set up (or at least verify) the
> MBR.
Well.. not really. Sure, working MBR should be on all disks involved.
But it is necessary to set it up only once on every disk, and forgot
about it. "Standard" MBR that comes with MS-DOS, or any other similar
MBR code will work, and there's no reason to touch it during the whole
lifetime of the disk.
That's exactly what I said in my previous email: set up standard MBR on
each disk once, and install lilo/grup/whatever on the raid partition,
so that kernel raid code will replicate every e.g. lilo update to all
disks.
The only possible problem with that is - disks with different geometry
and/or partition placement (e.g. raid1 made from /dev/hda1 and /dev/hdb2
- 1st partition on first disk and *second* partition on second, so that
sector addresses of loader data will be different on the two). For this
case, some support from the bootloader IS needed, but it's rather bizzare
case.
/mjt
next prev parent reply other threads:[~2003-10-30 14:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-30 14:11 Booting from a raid1 device ? Cress, Andrew R
2003-10-30 14:26 ` Michael Tokarev [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-10-30 15:22 Cress, Andrew R
2003-10-29 15:50 Cress, Andrew R
2003-10-31 14:41 ` Eric Wood
2003-10-27 21:14 Cress, Andrew R
2003-10-30 0:54 ` Michael Tokarev
2003-10-30 10:00 ` Lars Marowsky-Bree
2003-10-31 8:28 ` Luca Berra
2003-10-31 17:40 ` Bill Rugolsky Jr.
2003-10-27 15:25 Don Jessup
2003-10-27 15:37 ` Gordon Henderson
2003-10-27 16:00 ` Paul Clements
2003-10-27 22:11 ` Hermann Himmelbauer
2003-10-27 23:02 ` maarten van den Berg
2003-10-28 10:56 ` Lars Marowsky-Bree
2003-10-28 16:23 ` Michael
2003-10-28 20:31 ` Sandro Dentella
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=3FA11F97.4020800@tls.msk.ru \
--to=mjt@tls.msk.ru \
--cc=andrew.r.cress@intel.com \
--cc=donj@asaca.com \
--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).