Re: Custom partitioning shell script?
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?
> 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).
> 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?
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.
> > 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.
- Matt
Reply to: