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

Re: Custom partitioning shell script?



On Wed, May 31, 2006 at 08:10:19AM +0200, Sven Luther wrote:
> d-i is a modular design,

Which I've been most impressed with in my travails, but unfortunately it's
(necessarily) quite complicated to dig into, so I haven't been able to
exercise it's full potential.

> the obvious answer, is to create a custom .udeb,
> which would replace the other partitioning tools. I guess it only needs to
> provide the same meta-dependencies as the other partitioning tools, and use a
> menu number inferior to the other partitioning tools.

Is there a better description of how the partitioning system hangs together
(as far as where scripts go and such) than

http://d-i.alioth.debian.org/svn/debian-installer/installer/doc/devel/partman/partman-doc.sgml

?  I tried going through that, but I had the very devil of a time trying to
actually understand how it all works.

I strongly suspected that a custom udeb was the answer, but I didn't want to
assume too much.  I presume that if I just remove all of the partman-related
udebs, and create matts-own-partitioner.udeb (and make sure it ends up in
the d-i Packages.gz) it'll work nicely -- what I'm curious about is how I
wire up the custom udeb to make it interact with the rest of the system, in
(at least) the following ways:

1) Run at the right time (in the order of sequence)
2) Have all of the partitions mounted in /target
3) Have /target/etc/fstab written

And so on.

> The work is relatively easy, and you can take the nobootloader package as an
> example, which is indeed just a simple script with a few debconf stuff needed
> to print a user-informing message. I did it from scratch in the begining, and
> thus know it is well suited for newbie doing their own scripts.

Thanks for that, I'll definitely check it out as an example.

> Simply add it to the image you build should be enough, or add it to a
> local copy of your archive. Once d-i gains support for multiple package
> archives, it will become easier even.

I'm comfortable wiring up a custom install CD -- I've already done a little
bit of that (removed a couple of problematic udebs in an instalinux CD I was
using, and mangled preseed files onto a CD) so that part of it shouldn't be
a drama.

> Alternatively, you could help working on partman until it does what you need,
> which is the responsible altough long-termed thing to do.

I think that counts as *very* long-term.  Considering the trouble I've had
understanding even the basics of d-i, I don't think you want me poking
around at it's internals too much too quickly.  I've also noticed that,
despite some attempts, there's still very little in the way of LVM support
in partitioning recipes (that I can find documented at least;
partman-auto-lvm is there, but I can't work out how to feed it a recipe),
and if the best-and-brightest of the d-i team haven't come up with a good
solution, it's quite unlikely that I'll do any better.  My needs are also
quite specialised -- I need a single CD which will do different things based
on hardware configuration, which will probably always best be served by a
shell script rather than a recipe.

One thing I'll almost certainly end up doing, though, is documenting my
travels with the custom partitioner, in case others wish to follow in my
footsteps that way.  Perhaps that's the contribution I can make -- that
elusive preseed option that runs a shell script to do partitioning instead
of invoking all of partman.

As an aside, is there a suggested method for testing d-i udebs?  I'd prefer
not to have to reinstall a real machine every time, and qemu is just so damn
slow...

- Matt



Reply to: