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
Attachment:
signature.asc
Description: This is a digitally signed message part.