Hi Colin,
On Fri, Aug 28, 2009 at 02:12:55PM +0100, Colin Watson wrote:
> On Fri, Aug 28, 2009 at 02:53:56PM +0200, Max Vozeler wrote:
> > On Wed, Aug 26, 2009 at 11:09:47PM +0100, Colin Watson wrote:
> > > Attached is a patch which introduces new syntax, looking like this:
> >
> > > Any comments? I think this is a noticeable improvement, so I'll commit
> > > it next week or so if there are no objections.
The change looks good to me, but note that I only read through
the patch and I haven't actually tested it.
> ===================================================================
> --- README (revision 60467)
> +++ README (working copy)
> @@ -38,13 +38,12 @@
>
> d-i partman-auto/disk string /dev/sda /dev/sdb
>
> +# raidid can be anything, as long as it doesn't contain spaces or slashes
> +# and matches something in raidid{ } in partman-auto/expert_recipe. You can
> +# use hash separated lists of ordinary device names instead if you prefer.
> d-i partman-auto-raid/recipe string \
> - 1 2 0 ext3 /boot \
> - /dev/sda1#/dev/sdb1 \
> - . \
> - 1 2 0 lvm - \
> - /dev/sda5#/dev/sdb5 \
> - .
> + 1 2 0 ext3 /boot raidid=1 . \
> + 1 2 0 lvm - raidid=2 .
A question, and a more general, potentially crazy one:
Currently partman-auto-* are limited in how complex block
devices can be preseeded and combined. Single "depth" is no
problem, but stacking complex block devices gets tricky.
(Or brings with it a coupling of unrelated parts which may
not be necessary, e.g. partman-auto-crypto and LVM.)
Reading your patch, it seemed to me that raidid actually
does two things, even though only the first may be intended:
One, it provides a stable and easily accessible identifier.
Second, (here starts crazy): It expresses something which
could be considered a dependency.
It could be taken to mean: Make sure whatever device provides
ID "2" is setup before doing anything else implied by this
preseeded "partition".
Do you think the raidid could, usefully, be generalized to
something like "deviceid=" to allow for a future dependency-
based preseeding of complex block devices?
Or is that overengineering?
Max
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
