Re: Custom partitioning shell script?

[Sven Luther <sven.luther@wanadoo.fr>]

On Thu, Jun 01, 2006 at 07:36:39AM +1000, Matthew Palmer wrote:
> On Wed, May 31, 2006 at 04:27:39PM +0200, Sven Luther wrote:
> > On Wed, May 31, 2006 at 11:00:19PM +1000, Matthew Palmer wrote:
> > > On Wed, May 31, 2006 at 08:10:19AM +0200, Sven Luther wrote:
> > > > 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.
> > 
> > Ah, no, as far as i see it, the partman stuff is an unscrutable spagetti mess,
> 
> Thank $DEITY I'm not the only one who thinks so.  <grin>
> 
> > I was not speaking of modifying partman there, but providing a .udeb which
> > would do your script, and place itself as default in higher priority than
> > partman for doing the partitioning task.
> 
> This (and the further comments you made below) give me an "aha!" moment
> about how d-i works out what to run -- it seems like, once one package which
> Provides: the appropriate bits and pieces (mounted-partitions, etc) has run,
> no others of the same ilk get run -- is that about right?

Yep.

> > We already have two partitioners in d-i, partman and autopartkit, so you can
> > see how they do it.
> 
> I was going to mention autopartkit in my last message, but I thought it was
> some sort of after-partman thing (didn't realise about the Provides: stuff). 
> I think I'll have a closer look at autopartkit -- it may do what I want (or
> at least, it's name suggests it might).

Autopartkit is used by the debian-edu/skolelinux folk, not sure what exactly
it does though. BTW, what exactly do you need.

The first time i ran d-i in early 2003, autopartkit was the default, and it
ate my devel harddisk without asking any question, so i never ever looked at
it.

> > There is a document somewhere which describe the menu item priority numbers.
> 
> I think I've seen it -- installer/doc/devel/menu-item-numbers.txt, right?

Yep.

> I've also just had a re-read of doc/devel/design.txt after reading your
> message, and it's making a bit more sense now.  I haven't found (or at
> least, didn't recognise when I saw it) the canonical list of valid options
> for Provides: entries and what precisely they mean, but I'll either find it
> or work out what I need from the values in partman and autopartkit.

I guess the Provides can be anything depended upon by other .udebs, there is
no such canonical list.

> > > 1) Run at the right time (in the order of sequence)
> > 
> > This is what XB-Installer-Menu-Item: is for. The Provides: bootable-system is
> > the virtual package provided by all boot-loader installer, you can simply
> > provide the equivalent one provided by partman and autopartkit.
> 
> Cunning, and oh-so-simple.
> 
> > > 2) Have all of the partitions mounted in /target
> > > 3) Have /target/etc/fstab written
> > 
> > euh ... 
> > Well, i am not an expert of those twos, but maybe looking at autopartkit would
> > be more useful, here is its control file :
> 
> Yep, that explains it -- the four Provides: I need are (with my assumed
> description):
> 
> partitioned-harddrives: the actual parted/MD/LVM wrestling
> made-filesystems: mkfs.<flingle> /dev/sd*
> mounted-partitions: mount /dev/sd* /target/*
> created-fstab: cat <<EOF >/target/etc/fstab
> 
> Presumably created-fstab is going to run at some far-distant time after the
> rest, but now I know *what* the existing systems do, I don't think I'll have
> such a hard time working out exactly how they do it.  I'll probably dissect
> autopartkit, simply because it's not in a dozen different udebs.
> 
> > > 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...
> > 
> > Use a netbootable real machine.
> 
> I can dredge up one of those.
> 
> Thanks for all your help, it's been invaluable.

No problem.

Friendly,

Sven Luther