[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Preseeded RAIDed installs again

On Sat, Aug 26, 2006 at 11:46:54AM +0100, Simon Huggins wrote:
On Tue, Aug 22, 2006 at 11:56:06PM +0200, David Härdeman wrote:
I was kinda hoping that I'd be able to finish that so that I'd be able to give input on how the partman-auto-raid stuff could be hooked into the UI as well so it not only allows preseeding but also manual action.

Interesting.  What would you hope to achieve this way though?  There is
already a RAID interface via the menus.

A RAID option in the partman-auto menu was what I was referring to. However, I realise that it would require much more work than just hooking it up (like integration with partman-auto-lvm) so it would probably be wise to postpone that feature for now.

On Wed, Aug 23, 2006 at 02:50:47PM +0200, David Härdeman wrote:
One comment and one question so far:

partman-auto-raid/init.d/initial_auto_raid seems to contain a copy of
confirm_changes() from partman-base/definitions.sh

Quite probably.  Do you mean I should try and source that then?  I took
a copy so I was working with something static that wouldn't change under

Yeah, I think you should source it, it would reduce the size of initial_auto_raid by two thirds.

Would it be possible to use lvm on top of the md device? The reason
that I'm asking is that it would allow all the existing recipies to be
used, no separate recipe format would be necessary for RAID (just
preseed disk and raid level) and much of the heavy lifting could be
done by partman-auto-lvm once partman-auto-raid has setup the md

That would involve LVM however and my goal was to set up RAID without
LVM.  I realised at the time that there could well be some useful work
to do both and to put LVM on top of an MD device for further carving up.

At the moment the partman-auto-raid stuff will give you automatic RAID
devices but I suspect some of the -auto-raid and/or -auto-lvm code would
need to be rejigged in terms of priorities at least in order to do this.

Yes, I agree, most code can be reused quite easily but a solution would still be needed for a proper /boot partition etc. This would perhaps involve adding a flag similar to $lvmok to the partman-auto recipies etc, but it sounds like something that would be suitable for post-Etch.

I see that as additional work on top of what I've already written
though; I think it's useful as is or I wouldn't have written it but I'm
open to suggestions and at least one of the server configs I install
Debian on requires some RAIDed partitions and then LVM on one of the
RAIDed partitions.

Let me know what you think needs to be done before this can go in.

It's a pretty low amount of code and it doesn't touch anything else, I think it could go in (with the duplicate confirm_changes() fixed). We can always work on further integration post-Etch.

In the end it's not my decision though, it's FJP's (and perhaps joeyh's while acting as interim RM), I only looked at the code :)


Reply to: