Executive summary of my confusion:

1) Why do you need a ram disk if raid1 and ext3 are not modules, but
   actually compiled into the kernel?

2) If you have a separate ext2 partition for /boot, do the modules have
   to be there too?  (Or are you expected to use an initrd then?)

3) What is /initrd for, anyway?  Why does that empty directory exist at
   all?

4) Where did Red Hat get there jbd.o module from?  My 2.4.17 kernel
   source doesn't have that as an option.  It's either built in, or not
   there at all.

On 16 Mar, Herbert Xu wrote:
>  > One hint: Software raid on root is always a bad idea. :-) The best thing to 
>  > do is RAID the important data partitions, and have a disk you can swap over 
>  > easily as root (or have a duplicate in the machine ready to go). 
>   
>  Mirroring root is OK.  You just need to put /boot somewhere else. 

Ah.  Another incentive to stop doing the stupid thing of mirroring my
swap partition (which simply slows the system down to no advantage, as
I now understand it).

Then I'll have a partition I can use for /boot.

It still seems strange that using RAID to mirror root is a bad idea,
since it seems to me that raid1 was designed for mirroring file systems
in the first place (especially root)!  And it seems even stranger to
recommend that mirroring it manually, on the other hand, is good.

I'd honestly like to know more details about why some people recommend
against using raid on the root file system.

Anyway, I've now got a small partition ready for /boot.  I booted up in
single user mode, turned off swap with swapoff, did a raidstop on that
device, ran fstab on the two partitions that formerly made up the md,
changing the type of one from raid-autodetect to Linux swap, and the
other to Linux (i.e. ext2).  Then did a mkswap on one and a mkfs on the
other, edited /etc/raidtab to remove the md swap, and /etc/fstab to
change the swap partition to be the new non-raid swap partition, and
booted up multi-user.

But I'm not sure of the next step.  And if I shift things to /boot on a
separate partition and fail to boot, then I'm not going to be able to
boot any of my old kernels.  (That's my worry right now.)

Do I need to have /lib/modules on the same /boot partition?  (If I
don't, aren't I going to have just the same problem with finding the
modules before the filesystem is mounted?)

Also, I've had a look inside the initrd image that is being built by
mkinitrd, and it doesn't match what's inside the initrd image that Red
Hat built, and which works.  *That* one has ext3.o raid1.o and jbd.o in
/lib.

My one generally has nothing, since I build ext3 and raid1 into the
kernel, not as modules (figuring that they're always going to be
needed - especially at boot time!) Since the kernel has them built in,
I don't even understand the need for the initrd.

Certainly mkinitrd requires raid modules if it sees that you have raid
arrays.  As if no one would consider building raid into the kernel
statically...

But just double-checking, now I'm not so sure.  It looks like ext3
filesystem support wasn't being built in at all!  Which would explain
the kernel panics, wouldn't it?

I just made an interesting discovery: a make mrproper removes the
..config file.  So after a make mrproper you really have to load up a
config you've stored.

Fortunately, juggling kernel configs is trivial with the Tk/Tcl mods to
the xconfig's scripts that I mailed a while back.

What I'm trying now is building a kernel that *really* has ext3 and
raid1 built in, and then I don't think I need an initrd, and I'll just
try booting that up.

Then I'll try one with raid1 and ext3 in as modules, with an initrd.
I don't see where Red Hat got the jbd module from, though - xconfig only
offers you a choice of no journal file system debugging or compiled-in -
the module option for it is greyed out.

luke


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Reply via email to