Merging Kickstart support from Ubuntu
I implemented Red Hat-style Kickstart support for the Ubuntu installer a
while back. It's broadly Anaconda-compatible, with various additions and
omissions documented here:
I think it's really about time that I got round to merging this back
into mainline d-i. Since it's moderately complicated I thought I'd
explain roughly what it involves.
Kickstart files are a list of directives, possibly including package
groups and pre/post scripts, that correspond approximately to preseed
files. The correspondence is sufficiently close that, with a bit of
hackery and some additions to d-i (most of which we made ages ago, like
preseed/interactive), it's possible to transform a useful subset of
Kickstart files into a set of preseeds. It turns out that, due to some
features of the specification, notably the ability to write out
Kickstart fragments at run-time and process them using %include, the
only time when we can sanely do this transformation is at d-i run-time,
before main-menu starts up.
I wrote a package called kickseed to do this transformation, obviously
all GPLed, producing initrd-kickseed and kickseed-common udebs (the
latter being a legacy of a previous implementation that had
file-kickseed and network-kickseed too, but I've kept the separation
since it might turn out to be useful again some day). These udebs weigh
in at around 14KB combined; perhaps this would be a good use for the
recently-freed 35KB on the root floppy :-), or we could support
Kickstart only for install methods other than floppies.
kickseed needs to be able to fetch Kickstart files from disks and the
network, and it's a real hassle in terms of compatibility with Anaconda
to try to separate these bits out the way we do for preseed at the
moment. Instead I pulled some interesting tricks with udpkg and anna to
arrange to bring disks or the network up early, installing and
configuring any necessary retrievers first if need be. This does involve
a few nasty layering violations which I'm not sure how to avoid, but it
works well and it's all survived remarkably unscathed anyway in the
nearly a year since I wrote it; about the only change I've had to make
at that level was the switch from hw-detect-full to disk-detect.
After that, kickseed fetches the Kickstart file from wherever it's told
by kernel command line parameters, and translates the directives there
into preseeds which it hands straight to the debconf database. It's
fairly easy to make this preseed several different things for
compatibility with different suites; I'll ditch the compatibility code
for old versions of Ubuntu since we don't promise installer
compatibility there, but it would be straightforward enough to make the
same version of kickseed support both sarge and etch to whatever extent
is possible for each. I also added a 'preseed' extension to the
Kickstart file format, so you can easily use Kickstart for top-level
automation and fine-tune using custom preseeding.
Things that kickseed needs from d-i:
* Mandatory: enable the 'getopt' builtin in busybox; bug filed;
increases the size of the busybox binary by a little over 1KB on
powerpc. Parsing Kickstart files correctly in shell is just way too
painful without this (I did try).
* Mandatory: Kickstart lets you choose to install specific packages as
well as package groups (i.e. tasks). Ubuntu has a
pkgsel/install-pattern question that can be preseeded with an
aptitude pattern, so it's easy there; in Debian, we probably need a
similar facility in tasksel.
* Optional: enable CONFIG_NFSMOUNT in busybox. Anaconda supports
retrieving Kickstart files over the network, and it's easy enough to
do the same from d-i given 'mount -t nfs'.
* Optional: I'd suggest enabling chvt in busybox, since I've had
requests for it for custom Kickstart scripts that display messages
to the user.
Things that d-i needs from kickseed:
* Root password handling will need to be changed based on however we
decide to implement #344873.
* 'xconfig --defaultdesktop' should be implemented properly
(shared/default-x-display-manager?). For Ubuntu I just assumed
One other thing: I've been developing this in arch, and I'd like to
preserve my revision history when moving it into d-i svn, but I don't
particularly want to flood IRC with CIA notifications of a couple of
hundred commits. Would anyone mind if I prepared an svn dumpfile with
equivalent changesets and loaded it straight into the d-i repository
Colin Watson [email@example.com]