Re: RAID 1

From: P.T. Breuer (ptb_at_oboe.it.uc3m.es)
Date: 12/28/03 

Date: Sun, 28 Dec 2003 08:40:16 GMT

Les Mikesell <lesmikesell@comcast.net> wrote:

> "P.T. Breuer" <ptb@oboe.it.uc3m.es> wrote in message
> news:qj6lsb.fvt.ln@news.it.uc3m.es...

> > > The question was obvious from the first post: "when you have mirrored
> >
> > What "first post"? This is usenet!

> Yes, usenet messages are threaded and reasonable readers can

Usenet messages are NOT threaded. They are not even "there"! And they
don't even stay there, where they aren't, until I come to read them.

> traverse the list backwards to the beginning of the thread.

I only see your message and I do not see any others, precisely because
I am seeing your message. If you think I am going to stop reading your
message and go over to goolgle to look up your previous missives, in
order to find out what you mean right now, you are mental. You know
that you have to make life easy for *me*, if you expect me to do work
for you, because I am not going to go and do work in order to do more
work.

> > Are you sure you mean drives and not partitions? It is most unusual to
> > mirror whole drives because raid devices are not partitionable
> > themselves, and because the kernel relies on the *partition* typelabel
> > at boot to know if it is a raid device or not.

> That is precisely the problem. You create mirrored partitions. Update

It's not a problem, but a general decision that people take to mirror
partitions and not whole drives. As a consequence you don't get a
mirror of the boot sector, and you have to take care of doing that
yourself. I imagine you have set up a grub.conf on the mirror device
that says to place the boot sector in one of the underlying drives, not
both of them. At which point your "non-problem" :0 arises - your
bootsector on the other drive is proably not up to date when you come
to need it.

> your kernel a few times, then the primary drive breaks. You have
> still have a copy of everything, but because grub didn't make the
> drive containing the still-working mirror partition bootable, you
> can't use it.

The solution is to make two grub.conf's, each pointing to a different
boot device and naming a different grub boot directory and map
palcements, and so on, and run both grub setups.

> > Perhaps you are running lvm over the raid1 device, in order to provide
> > partitions?

> Well, that might be a problem if Redhat's installer would actually
> install on lvm but I've never seen it work. It will install on
> mirrors but leaves the mirror unbootable.

Well, I pointed out why that would be - I doubt that either or both of
grub or the kernel boot code can cope with the extra indirection layer!

> > I don't understand your question - why should you care if grub puts it
> > there or not? YOU can put it there, using the "cp" command, if grub
> > puts it anywhere at all. You will have more problem with getting grub to
> > locate the second stage loaders physical location on disk!
> >
> > So, give us a clue, what *is* your problem, exactly?

> As you've pointed out, it isn't simple to describe to grub how to
> make the drive containing the spare partitions bootable, and after
> going to the trouble and expense of mirroring the data it would be
> nice to be able to use it when the primary drive fails. So, that is
> the problem. Lilo seems to know enough about md devices to
> make both mirrors boot. Grub doesn't, but it has some other

I think lilo got some fixes a while back to cope with maps on a
mirrored device. But that's beside the point - you are mixing up several
different questions, and you must distinguish between them. I'll start
you off by naming two of the different questions that you touch on:

 1) how do you maintain the boot sector automatically
 2) how do you persuade your boot loader to get its second stage off
     of a raid device instead of off a real device
  
> advantages and is now the default in a RedHat install. What does
> it take to make grub know as much as lilo about md partitions? Or,

Lilo knows nothing much except how to descramble the logical placement
of its map file and kernel image on a raid1 device back to physical
placements that it can implant in the boot loader (that's (2) above).
With luck, it might also put slightly different boot sectors in the two
target drives, if you manage to tell it about two target droves (that's
(1) above).

> if grub can't do it, what command would you issue to make sure
> the non-primary mirror will boot.

I would run grub twice, with different boot devices as target both
times. That solves (1), and presupposes that you have solved (2).

I don't know if grub can deal with (2) at all. I doubt that it has an
md driver in in order to be able to mount a raid partition, and it must
have since it runs before the kernel runs and tries to read the file
system to get its conf. If that is the case, then you must configure
grub to read the underlying partitions instead, not the raid device.

That's a problem, because grub may like to write its second stage
bootloader with some physical info at that point. I hope not. If it
does, you will have to fool it into writing on the raid device, not
the underlying partition(s).

Why not ask the grub authors what they intend you do? I don't know
grub (but I know its documentation is gibberish in general).

Peter

Relevant Pages

  • Re: F8/F9 Multiboot question
    ... > 1) Boot in Fedora-Live ... > + Disk drives are DIFFERENT, not necessarily the same as when booted ... This was the grub I "popped" ... partitions for 3 boot directories, boot-sys, boot-f8, and boot-f9, ...
    (Fedora)
  • Re: IDE CD/DVD Drive Visible to GRUB
    ... to mark all other partitions as hidden, ... Longhorn to from the bootable CD. ... This was quickly fixed with my GRUB floppy. ... The reason that I was trying to find a way to boot from the CD _after_ ...
    (comp.os.linux)
  • Re: How to shift Grub left from a prior Linux Install?
    ... The Master Boot Record is neither FAT nor NTFS - it's just the first 512 ... If your machine keeps on using the Grub boot loader then you've probably ... primary master disk that counts. ... Kubuntu was on separate partitions to Win 7. ...
    (microsoft.public.windows.file_system)
  • Re: any difference ?
    ... And therefore GRUB may not be able to see that it is bootable ... because we can't have more then four primary partitions. ... They can boot from any partition on the first two ... no idea how to boot it, it is hard to say if Linux could boot it. ...
    (alt.os.linux)
  • Re: RAID 1
    ... >> mirror whole drives because raid devices are not partitionable ... You create mirrored partitions. ... > drive containing the still-working mirror partition bootable, ... You will have more problem with getting grub to ...
    (comp.os.linux.networking)