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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
