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:
> > 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.
Ah, no, as far as i see it, the partman stuff is an unscrutable spagetti mess,
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.
> 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
Nope, you can leave them there, if i am not wrong, the fact that
matts-own-partitioner.udeb has a higher menu item number and provide the right
functionality, should be enough.
We already have two partitioners in d-i, partman and autopartkit, so you can
see how they do it.
> 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:
As said, have a look at the nobootloader control file. It runs (after though)
the other bootloader-installers, like grub-installer, so it does exactly what
you want, and is dead simple. Here is its control file :
Package: nobootloader
XC-Package-Type: udeb
Architecture: all
Provides: bootable-system
Depends: cdebconf-udeb, base-installer (>= 1.23), di-utils-mapdevfs
XB-Installer-Menu-Item: 77
Description: Don't install any bootloader.
This package will skip installing a boot-loader
There is a document somewhere which describe the menu item priority numbers.
> 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.
> 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 :
Package: autopartkit
XC-Package-Type: udeb
Architecture: any
Depends: ${shlibs:Depends}, e2fsprogs-udeb, libuuid1-udeb,
libparted1.6-udeb, cdebconf-udeb (>= 0.43), disk-detect, md-modules,
lvm10-udeb | lvm2-udeb, partconf-mkfstab, di-utils (>= 1.15)
Provides: mounted-partitions, created-fstab, made-filesystems,
partitioned-harddrives
XB-Installer-Menu-Item: 50
Description: Automatically Partition Hard Drives (unsafe)
This module will automatically partition the harddrive on which you wish
...
So, you see, there is a whole lot of provides you have to do, and i guess you
can do those manually.
> 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.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
