Whilst this didn't turn out to be a d-i bug, it did occur to me there is a lack of robustness within d-i, and a real bug here would have been a nightmare to find. The sequence of events was something like: * at boot-time, /var/lib/dpkg/info/*.templates are parsed to generate a /var/lib/cdebconf/templates.dat; corruption was happening on reads, but only sometimes were there warnings (non-fatal) about unrecognised fields and such * cdebconf later treated a corrupt templates.dat as valid, even though it was truncated and/or had a long sequence of null bytes at the end I know the previous two are partly due to forward compatibility for new fields, and the RFC822 format being so... relaxed. But then: * cdebconf command_get was being called with an option name not found in its templates.dat; it returns an error message string, but the caller (main-menu) tries to interpret it as an actual debconf setting before failing (The size of templates seems to have grown immensely due to the localisation effort - I'm pretty sure I've seen templates.dat taking up to 3x 10MiB of space in the ramdisk during cdebconf processing - an uncompressed flat-file plain text database doesn't seem ideal any more). And I've had other d-i issues recently where I thought "d-i is so inherentely hard to debug, rebuild, test; I really wish the whole thing could run inside of a chroot/jail/container, or at least the individual components run standalone under gdb/ktrace like a normal application, and have easy access to fully-featured (not Busybox) utils, make quick changes to test, read and save a copy of logs, etc.". But sometimes I've wondered "why fix this particular issue, a larger chunk of it really ought to be ripped out and reworked someday" with the eventual conclusion that "with d-i growing larger and now using a GUI by default, hasn't the full Debian Live system become a more practical base to install from now?" It seems like a lot of functionality (or hacks) must be implemented twice: once for the production system and again for d-i. grub-installer comes to mind as an example - it includes a 32KiB shell script - but a running system or the chroot in /target likely must have the ability to install/configure/upgrade GRUB itself already? I guess that d-i's use cases and typical user base has changed drastically from what it once was. I think a totally new user is better served by a Debian Live system with some kind of installer built into it. Servers have changed a lot in how they're provisioned; KVM (keyboard-video-mouse) switches are out, and fully-featured network-booted Live rescue systems are in. Platform virtualisation happened: hosting providers may now only untar and tweak configuration to spin up a new Debian instance. d-i images may be very small, but I haven't found it practical on embedded systems, which may not even have working VGA or networking; I find myself debootstrapping/grub-installing such devices from a workstation instead. Just a few things off my mind :) Regards, -- Steven Chamberlain steven@pyro.eu.org
Attachment:
signature.asc
Description: OpenPGP digital signature