From: Tim Small <tim@buttersideup.com>
To: linux-raid@vger.kernel.org
Subject: Re: RAID 5 questions
Date: Wed, 04 Aug 2004 09:52:04 +0100 [thread overview]
Message-ID: <4110A3B4.8020009@buttersideup.com> (raw)
In-Reply-To: <20040803202334.GB5148@janus>
Frank van Maarseveen wrote:
>try running lilo with -v -v -v
>
>Then you might see the BIOS drive number, geometry it assumes etc. You
>will probably see only _one_ disk and in that case your system boots
>by sheer luck.
>
>With -v -v -v I discovered why my system refused to boot from raid 1.
>It appears to actually boot from the first disk in the raid set, e.g:
>
> md1 : active raid1 hdg1[1] hda1[0]
> ^^^^^^^
>
>This is mounted on /boot and lilo will boot from hda1 (bios disk 0x80).
>I had to reassemble the raid set in opposite order to get this because
>hdg is unbootable (lilo assumed bios drive 0x81). But maybe my lilo is
>old (21.4-4).
>
>
>
You can do this sort of thing to override lilo's idea of which linux
device maps to which BIOS disk number e.g. I use this on one box:
disk=/dev/hda
bios=0x80
boot=/dev/hda
#disk=/dev/hdf
# bios=0x80
#boot=/dev/hdf
# Specifies the device that should be mounted as root. (`/')
#
root=/dev/md3
I run lilo twice (once with the hda lines uncommented, and once with the
hdf lines uncommented) - so that the system will still boot with hda
pulled from the machine - with hda broken, the machine still won't boot,
but at least you can disconnect hda at that point, or disable it in the
BIOS (so that hdf becomes 0x80)...
You can do a similar thing with grub, but with the advantage that you
don't have to play around with the config file every time you upgrade
the kernel (you could use two different lilo.conf's I suppose)...
I'm not sure if this has already been stated (Frank just implied it),
but a simple workaround to the original problem is to make a small RAID1
/boot partition on a couple of the disks, and have the rest of the
drives carved up as RAID5, and I think that if you're using lilo to load
the kernel off RAID5, then you're being lucky (AFAIK).
e.g. I sometimes do this:
drive1 drive2 drive3 drive4
[ boot(raid1) ] [ swap(raid1) ]
[ more-swap (raid5) ]
[ /root (raid5) ]
[ /other (raid5) ]
Tim.
next prev parent reply other threads:[~2004-08-04 8:52 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-01 1:57 RAID 5 questions Ninti Systems
2004-08-01 3:08 ` Daniel Pittman
2004-08-01 3:31 ` Jim Paris
2004-08-01 3:50 ` Alvin Oga
2004-08-02 6:01 ` Jarmo Järvenpää
2004-08-02 6:08 ` Luca Berra
2004-08-02 6:55 ` Jarmo Järvenpää
2004-08-02 6:09 ` Jim Paris
2004-08-02 7:27 ` Jarmo Järvenpää
2004-08-03 20:23 ` Frank van Maarseveen
2004-08-04 8:52 ` Tim Small [this message]
2004-08-01 9:33 ` Luca Berra
2004-08-01 10:24 ` Frank van Maarseveen
2004-08-03 5:19 ` misty-
2004-08-06 0:49 ` H. Peter Anvin
-- strict thread matches above, loose matches on Subject: below --
2004-06-03 14:29 Raid " David Greaves
2004-06-03 15:13 ` Guy
2004-06-03 15:50 ` David Greaves
2004-06-03 16:43 ` Guy
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=4110A3B4.8020009@buttersideup.com \
--to=tim@buttersideup.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).