After taking a long look at ubiquity, I decided to try another route. I've been unsuccessful at getting ubiquity to build on debian, although I haven't really been that interested in using ubiquity, so I haven't tried too hard to get it to build. I did get it to grab the debian installer parts from debian instead of ubuntu, but the build fails somewhere else. I was mainly looking through it to gather ideas of how to use parts of the debian installer in an application.
What I wound up doing is trying to make a debian package out of partman. I
did this by checking out the partman directory in the svn repository, and
building the udebs. I then extrated the udebs into a directory, and the
templates into a subdirectory of that directory. I then used regular debian
tools to install the result into a deb. The deb also contains a script that
takes the templates, and makes a temporary debconf database purely for the
running of partman. This method almost works. The debconf menu seems to
work ok, and the partition selection also seems to work, until you actually
want to change something on the disk. At that point it seems to fail.
This has been very tiring for me. I've had to dig through the debconf code to
figure out how to use a config file that's not in a standard location. I
should've read the debconf(7) page a little more carefully as it says this,
but only after it says that it's used to ignore the ~/.debconfrc file (so I
took this to be what it did and ignored the rest).
There are a few things that would keep this from running properly in a live
environment. There seem to be writes to /usr/lib while the program is
running (I don't really know why /var/lib wasn't used). It also seems that
there are parts missing, and that the same (or similar) commands on the
system won't work as substitutes. I think that I'd have to include some more
udebs in order to get this to start working. I also think that I should
probably put these all under a "di" directory in /usr/share (that can be
cp -s into /var/lib) and chroot into it. I think that might be easier than
extracting the initrd (which takes up memory on a live system). Well maybe
not easier, as you have to include nearly every udeb that you expect to use
in the deb that's created. However, using a preselected set of udebs, and
having additional ones installed at runtime does seem possible with this
method.
The code for this is here:
svn://svn.berlios.de/paella/debpartman
Please use this on virtualbox or some system that you can trash, since I don't
know what it might do to it. I do know that it makes writes to /usr/lib
while it's being run, and dpkg will warn you that it can't erase some
non-empty directories if you deinstall it after running it. It also seems to
keep some information in another place that I haven't pinned down, as it will
fail sometimes (and everytime thereafter) when there is
no /var/lib/partman/devices present. I haven't figured out what causes this
yet.
I took a look around the web, and it seems that the state of automated
partitioning is about the same as it was in 2003 when I started making
paella, with the exception of partman (and maybe anaconda, I'd almost
forgotten about that one). I guess that there aren't very many people
interested in this. It seems that after looking around, the perl script in
fai is still the best choice for partitioning disks and creating filesystems
on a regular system (with the possible exception of anaconda, which I'm going
to look into once I'm done writing this).
--
Thanks:
Joseph Rawson
signature.asc
Description: This is a digitally signed message part.
