Bug#61065: Adam Di Carlo: Re: Bug#61065: Need /dev/md0 for boot/install RAID support in root.bin
I'm not sure what the mail problem is. If it is something on our end, let
me know and I'll look into it as I serve as postmaster here.
On Fri, 31 Mar 2000, Adam Di Carlo wrote:
>
> I was unable to send mail to you but recently. I'm going to resend my
> bounced messages up to 10 days old. Sorry if this is stale info.
>
> ------- Forwarded Message
>
> Received: by arroz.fake (Postfix, from userid 421)
> id 5916193857; Sat, 25 Mar 2000 13:51:30 -0500 (EST)
> Sender: apharris@arroz.fake
> To: Mike Bilow <mikebw@colossus.bilow.com>
> Cc: 61065@bugs.debian.org
> Subject: Re: Bug#61065: Need /dev/md0 for boot/install RAID support in root.bin
> References: <[🔎] Pine.LNX.3.96.1000324183147.18502G-100000@colossus.bilow.com>
> From: Adam Di Carlo <adam@onshore.com>
> Date: 25 Mar 2000 13:51:30 -0500
> In-Reply-To: Mike Bilow's message of "Fri, 24 Mar 2000 18:44:04 -0500 (EST)"
> Message-ID: <[🔎] oa3dpehoi5.fsf@arroz.fake>
> Lines: 53
> User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
>
> Mike Bilow <mikebw@colossus.bilow.com> writes:
>
> > Basically, it is possible to boot on the Rescue/Root floppies (with a
> > non-standard kernel),
>
> Note that the standard, "vanilla" kernel has changed in the following way:
>
> kernel-image-2.2.14-i386 (2.2.14-2) frozen unstable; urgency=low
> .
> * Enabled ServerRAID (closes: #52597).
> * Enabled DAC960 (closes: #49863).
> * Enabled CONFIG_FILTER (closes: #50996).
> * Enabled quota support (closes: #60206).
>
> Is this enough? I guess not... it doesn't have md support?
I will have to check into this. The start of the problem is that there is
no proper software RAID support in the kernel source tree. The software
RAID support which is present is years old and is referenced as v0.4x
RAID. The newer code, which completely replaces the earlier code and is
currently being distributed as kernel source patches by Ingo Molnar (at
http://people.redhat.com/mingo) which is referenced as v0.90 RAID.
I ended up using a custom kernel in order to have the patches to use v0.90
RAID, which is by all accounts what is going into the 2.4 kernels. The
narrower issue I raised was that root.bin does not have the /dev/md?
nodes, which is a much simpler matter.
> > drop to fdisk manually to set partition types to
> > 0xFD (RAID autodetect),
>
> Can't cfdisk set this partition type? If not, please file a bug
> against cfdisk.
There is no problem with fdisk/cfdisk as far as know. (I used fdisk and
did not test cfdisk.) The issue is that the Debian install program does
not seem to understand how to make any use of /dev/md? devices even after
they exist, so what I meant by "manually" is that I had to drop out to a
shell to run fdisk, mkraid, mke2fs, and mount before I could continue the
regular install. Whether this is appropriate behavior for the
installation program is a matter of opinion, and at worst is a wishlist
bug. One could argue that, if one is installing onto RAID for the boot
volume, then one ought to know what one is doing with a shell prompt.
On the other hand, there is also no good reason that the install program
should not be able to handle this, at least all but mkraid.
In addition, before I could run mkraid, I had to remount the root
partition as read-write and do "mknod /dev/md0 b 9 0". Getting rid of
these steps would have helped the installation. If there is any support
for software RAID in the kernel, there must be /dev/md? nodes in root.bin
just as any kernel with IDE support is going to need /dev/hd? nodes, too.
> > run mkraid (from a mounted floppy) to unite the partitions,
>
> mkraid isn't part of root.bin, is it? I think we have room on i386 at
> least to add it, btw.
Well, raidstart would be nice, too, especially if the rescue disk is
really expected to be able to serve as a "rescue" disk. Most of the other
RAID components in raidtool2 are actually just symlinks to either mkraid
or raidstart, anyway, so they consume essentially no space in root.bin.
> > and proceed with a more or less standard install -- except
> > that the root filesystem in the RAM disk is mounted read-only and has no
> > node /dev/md0.
> >
> > It can be fixed ("mount -o remount,rw /dev/root / ; mknod b 9 90"), but I
> > think it would be a good idea and very minimal effort to make the node
> > present by default so that it would be accessible when the kernel started
> > the RAID automatically.
>
> I can certainly add this device to the list of devices created. Could
> you clarify:
>
> - are you sure it's just /dev/md0 that we need?
>
> - this is not present but should be added to root.bin?
>
> - is it present in the base file system?
No, ideally there should be a set of /dev/md? nodes like /dev/hd? or
/dev/sd?. I think the current default in the source is 12 RAID sets, but
I am not sure what their standard names are once past 9. I think anyone
would be happy to have /dev/md0 through /dev/md9 provided. At that point,
no one would mind having to run mknod manually. These things consume
almost no space in root.bin, as they are simply device nodes.
I am not sure if /dev/md? devices are created in the base file system. I
suspect they are not, and that this is currently the responsibility of the
raidtools2 package rather than the base installation. This would be
consistent with Debian Policy, I think, except that it is now possible to
boot on software RAID and therefore the responsibility should be moved.
As long as the /proc filesystem is in the kernel, you can do an existence
check for /proc/mdstat. If it exists, then the kernel has RAID support
and the /dev/md? devices should probably be created during base install.
> > In general, support for installing to bootable software RAID should
> > probably be added to boot-floppies at some point for the 2.4 kernel.
>
> There are limitations on what we can add to the kernel. But I think
> this is in the cards for woody.
Once software RAID is in the mainstream 2.4 kernel, combined with the fact
that it was added to mainstream Lilo last week, this is going to be an
expected part of a Linux distribution and we absolutely must provide it.
The fact that I was actually able to do it successfully with potato by
replacing the kernel and Lilo is an indication that we are very close.
-- Mike
Reply to: