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