[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: d-i's purpose (was: Cannot find "debian-installer/main-menu doesn't exist" in menu)

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

(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 :)

Steven Chamberlain

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: