My debian-installer test methods

Since people who are working on d-i often wonder what's a good way to test changes, I thought I'd write up some of the techniques I use for d-i testing. This won't be a comprehensive list or a howto, just a brain dump of the kind that some occasionally find useful.

There's really only one key peice of advice and that is, do not use debian-cd to build a custom CD image just to test your change to d-i. Even if you know how to do it, even if you have a setup that will build working netinst images, it's just not worth the pain of messing with debian-cd, and with ISO images. There are so many better ways to test a change to d-i, that building a custom CD image should be your absolute last resort, and only done if you need to test something specific to the debian-cd package, or if you need to test a specific type of iso image.

My favorite way to test a change to d-i right now is to build a udeb with the change; copy it to installer/build/localudebs; make rebuild_netboot; and untar dest/netboot/netboot.tar.gz into /var/lib/tftpboot. Then netboot a test laptop. This takes less than 5 minutes to boot up into d-i for each test. It of course requires a machine that can netboot.

One step I left out is that if the udeb in question is not one that is on the normal netboot initrd, then I have to echo 'udeb-name *' > pkg-lists/netboot/local. This ensures that the udeb and all its dependencies are put on the initrd. Otherwise it would not go on, and d-i would load an unmodified version from the network.

When I'm downstairs and do not have a ethernet wire to netboot from (and can't from wireless, on my hardware), I use my second favorite method. This is to build a hd-media image instead, with my udeb on it, and write it to a usb keychain. Often I only copy over the dest/hd-media/initrd.gz to a keychain that already has a recent version of the installer on it, as this is much quicker on slow usb 1.0 controllers.

If you can't netboot or usb boot, the next best thing is to use a miniiso. One is built in dest/netboot/mini.iso as part of the netboot build. This is a small iso that has only the d-i kernel and initrd on it, once it's booted it's the same as if you'd netbooted d-i. Since it's such a small iso (3-4 mb), it will build and burn very fast.

If you have to boot from CD and the machine has no or a slow network connection, an alternative is to edit config/i386.cfg, uncomment the "monolithic" on the first line, and make rebuild_monolithic. The resulting ISO in dest/monolithic/mini.iso will have nearly every udeb on it, and you'll only need to download the debian base system from the network.

If the network is very slow, loop mount a debian netinst iso on a nearby machine with a web server, and hey presto, you have a partial debian mirror that is enough to install base from.

The above cover almost every method I use of testing changes to the installer. One other trick I use is avoiding rebooting to test every change, if only small changes are needed, I'll make them on files in the running d-i, test them until they work, and then make the same changes in my source tree (or finish the install and copy the changes over with scp if they're larger).

One neat trick I've seen is if you're testing d-i on the same machine you develop on (with care), you can just mount your development partition from inside d-i, and chroot into it. Now you have a real d-i test environment, and a development environment side-by-side.

It's not quite ready yet, but I'm already finding d-i preseeding to be a useful complement to testing. Why press enter over and over when you can automate all the parts of the install except for those you're working on?

Finally, I often find it's quicker to use vmware or qemu to test d-i CD images, if the thing I'm testing is not too far into the install. Though these are slower, the time gained by not needing to write installation media often makes up for the slow speed. And of course I use nothing but virtual machines to test floppies..

One thing not to do when testing a change to d-i is to try to run it in a regular debian system. Maybe this is ok for initial testing during development of certian things, but you'll often run into busyboxisms, missing commands, and other problems and it's rarely worth the bother.

To make any given change to d-i, I often boot my test machines a dozen times, and build new initrds with 3 or 4 different versions of the thing I'm changing. I may repeat this for five or ten changes a day, which is a lot of rebooting and testing. Without the tricks described above, I doubt I could manage more than one test cycle every hour, for less than 10 test cycles a day, not enough to do a lot of development. So a final peice of advice is do everything you can to shorten that test cycle, be it faster hardware, or whatever, because your time really does matter.