raid1: module or compiled in?

raid1: module or compiled in?

[Zeno Davatz]

Hi List

I am a Debian Woody 2.4.20 user and got the following question:

If I want the software raid to work do I need to compile it into the
kernel or does it suffice if I just load the support as module?

I was reading in the software-RAID Howto that the support should NOT be
loaded as Module. Why would that be?


Zeno

Re: raid1: module or compiled in?

[Paul Clements]

Zeno Davatz wrote:

> I am a Debian Woody 2.4.20 user and got the following question:
> 
> If I want the software raid to work do I need to compile it into the
> kernel or does it suffice if I just load the support as module?

md generally does have to be compiled in...the raid personality modules
(raid1, raid5, etc.) can be compiled as modules... more below...
 
> I was reading in the software-RAID Howto that the support should NOT be
> loaded as Module. Why would that be?

Were they talking about _md_ needing to be compiled in? Because it has
to be compiled into the kernel if you want to use persistent superblocks
and/or use it for your root partition. I have patches against 2.4 and
2.5 to fix this md problem, BTW, if anyone wants them...I posted the 2.5
one a while back...

--
Paul

Re: raid1: module or compiled in?

[Zeno Davatz]

On Wed, 2003-05-07 at 17:48, Paul Clements wrote:
> Zeno Davatz wrote:
> 
> > I am a Debian Woody 2.4.20 user and got the following question:
> > 
> > If I want the software raid to work do I need to compile it into the
> > kernel or does it suffice if I just load the support as module?
> 
> md generally does have to be compiled in...the raid personality modules
> (raid1, raid5, etc.) can be compiled as modules... more below...
>  
> > I was reading in the software-RAID Howto that the support should NOT be
> > loaded as Module. Why would that be?
> 
> Were they talking about _md_ needing to be compiled in? Because it has
> to be compiled into the kernel if you want to use persistent superblocks
> and/or use it for your root partition. I have patches against 2.4 and
> 2.5 to fix this md problem, BTW, if anyone wants them...I posted the 2.5
> one a while back...
Ok, thanks. This is useful. In that case I must patch the kernel with your patch
or I must compile md into the kernel.

Thanks for the hint.

Zeno


> --
> Paul

Re: raid1: module or compiled in?

[Derek Vadala]

On 7 May 2003, Zeno Davatz wrote:

> If I want the software raid to work do I need to compile it into the
> kernel or does it suffice if I just load the support as module?
>
> I was reading in the software-RAID Howto that the support should NOT be
> loaded as Module. Why would that be?

It depends when you start the arrays. If you are booting from SW RAID or
autostarting, you need to have the driver compiled into the kernel or you
need to use an initial RAM disk that preloads the md driver and necessary
RAID level modules.

If you are booting the system from a standalone disk you can skip this and
use modules without the initial RAM disk.  After the system comes up, just
start the array using mdadm or raidstart (in rc.local, for example).

A lot of people prefer compiling drivers directly into the kernel for
production systems. I've found both approaches work just fine.

-- 
Derek Vadala, derek@cynicism.com, http://www.cynicism.com/~derek

Fatal: map file must be on the boot RAID partition

[Zeno Davatz]

[-- Attachment #1: Type: text/plain, Size: 936 bytes --]

On Wed, 2003-05-07 at 18:07, Derek Vadala wrote:
> On 7 May 2003, Zeno Davatz wrote:
> 
> > If I want the software raid to work do I need to compile it into the
> > kernel or does it suffice if I just load the support as module?
> >
> > I was reading in the software-RAID Howto that the support should NOT be
> > loaded as Module. Why would that be?
> 
> It depends when you start the arrays. If you are booting from SW RAID or
> autostarting, you need to have the driver compiled into the kernel or you
> need to use an initial RAM disk that preloads the md driver and necessary
> RAID level modules.
Well yes I believe this is true. I followed following howto:
http://www.james.rcpt.to/programs/debian/raid1/

And I tried to load the drivers via RAM disk over mkinitrd. But my lilo
always tells me:
Fatal: map file must be on the boot RAID partition

I attached my lilo.conf and my /etc/raidtab.

Thanks for your time and help.

Zeno

[-- Attachment #2: lilo.conf --]
[-- Type: text/plain, Size: 3992 bytes --]

# /etc/lilo.conf - See: `lilo(8)' and `lilo.conf(5)',
# ---------------       `install-mbr(8)', `/usr/share/doc/lilo/',
#                       and `/usr/share/doc/mbr/'.

# +---------------------------------------------------------------+
# |                        !! Reminder !!                         |
# |                                                               |
# | Don't forget to run `lilo' after you make changes to this     |
# | conffile, `/boot/bootmess.txt', or install a new kernel.  The |
# | computer will most likely fail to boot if a kernel-image      |
# | post-install script or you don't remember to run `lilo'.      |
# |                                                               |
# +---------------------------------------------------------------+

# Support LBA for large hard disks.
#
lba32

# Overrides the default mapping between harddisk names and the BIOS'
# harddisk order. Use with caution.
disk=/dev/md0
#    bios=0x81

#disk=/dev/sda
#    bios=0x80

# Specifies the boot device.  This is where Lilo installs its boot
# block.  It can be either a partition, or the raw device, in which
# case it installs in the MBR, and will overwrite the current MBR.
#
boot=/dev/md0
#raid-extra-boot="/dev/hda,/dev/hdc"

# Specifies the device that should be mounted as root. (`/')
#
root=/dev/md0

# Enable map compaction:
# Tries to merge read requests for adjacent sectors into a single
# read request. This drastically reduces load time and keeps the
# map smaller.  Using `compact' is especially recommended when
# booting from a floppy disk.  It is disabled here by default
# because it doesn't always work.
#
# compact

# Installs the specified file as the new boot sector
# You have the choice between: bmp, compat, menu and text
# Look in /boot/ and in lilo.conf(5) manpage for details
#
install=/boot/boot-menu.b

# Specifies the location of the map file
#
map=/boot/map

# You can set a password here, and uncomment the `restricted' lines
# in the image definitions below to make it so that a password must
# be typed to boot anything but a default configuration.  If a
# command line is given, other than one specified by an `append'
# statement in `lilo.conf', the password will be required, but a
# standard default boot will not require one.
#
# This will, for instance, prevent anyone with access to the
# console from booting with something like `Linux init=/bin/sh',
# and thus becoming `root' without proper authorization.
#
# Note that if you really need this type of security, you will
# likely also want to use `install-mbr' to reconfigure the MBR
# program, as well as set up your BIOS to disallow booting from
# removable disk or CD-ROM, then put a password on getting into the
# BIOS configuration as well.  Please RTFM `install-mbr(8)'.
#
# password=tatercounter2000

# Specifies the number of deciseconds (0.1 seconds) LILO should
# wait before booting the first image.
#
delay=20

# You can put a customized boot message up if you like.  If you use
# `prompt', and this computer may need to reboot unattended, you
# must specify a `timeout', or it will sit there forever waiting
# for a keypress.  `single-key' goes with the `alias' lines in the
# `image' configurations below.  eg: You can press `1' to boot
# `Linux', `2' to boot `LinuxOLD', if you uncomment the `alias'.
#
# message=/boot/bootmess.txt
prompt
timeout=150
#	prompt
#	single-key
#	delay=100
#	timeout=100

# Specifies the VGA text mode at boot time. (normal, extended, ask, <mode>)
#
# vga=ask
# vga=9
#
vga=normal

# Kernel command line options that apply to all installed images go
# here.  See: The `boot-prompt-HOWO' and `kernel-parameters.txt' in
# the Linux kernel `Documentation' directory.
#
append="md=0, /dev/hda2, /dev/hdc2"

	# Boot up Linux by default.
#
default=Linux

image=/vmlinuz
	label=Linux
	read-only
#	initrd=/initrd.img
#	restricted
#	alias=1

image=/vmlinuz.old
	label=LinuxOLD
	read-only
	optional
	initrd=/initrd.img
#	restricted
#	alias=2

[-- Attachment #3: raidtab --]
[-- Type: text/plain, Size: 202 bytes --]

raiddev /dev/md0
	raid-level      1
	nr-raid-disks   2
	nr-spare-disks  0
	chunk-size	32
	persistent-superblock 1
	device          /dev/hda2
	raid-disk       0
	device          /dev/hdc2
	failed-disk	1

Re: raid1: module or compiled in?

[Paul Clements]

Derek Vadala wrote:

> It depends when you start the arrays. If you are booting from SW RAID or
> autostarting, [...] you
> need to use an initial RAM disk that preloads the md driver and necessary
> RAID level modules.

You would think that would work, but it doesn't, unfortunately... :/

md has to be compiled in if you want to use autostart. I suppose you
could put a raidtab file and raidtools (or maybe mdadm would be easier?)
on your initrd, and get the thing to boot, but that's rather
complex...and most distros don't have the setup to make an initrd like
that...(they just compile md in and call the autorun ioctl from the
initrd after loading your storage and raid modules)

I've got a patch for md (2.4 and 2.5), so you can do autostart with md
compiled as a module...

I just posted a message about it...

--
Paul