Steven Chamberlain <steven@pyro.eu.org> (2014-08-21): > * 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 This indeed looks like something worth a bug report if none exists yet. > 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.". There's a strace udeb; you can copy host files into d-i as well (see EXTRAFILES for example), 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?" Debian Live looks like a very bad and sad joke from where I stand. I'm not going to name issues here though because I don't think it's going to bring anything useful to the “discussion”. I should mention that Live images exist for (linux) amd64 and i386 only and that they are built on Debian infrastructure since only 7.5 or 7.6, thanks to enormous efforts from Steve McIntyre, from the CD (and not Live) team. > 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 :) It's fine that you can find your way to installing Debian without using that useless, crappy, hard-to-debug, replicated-code-based tool that d-i is. But it's not fine to try and use these “arguments” to dismiss the fact that d-i has to work properly on all release architectures, and that many or most users are using it to install their machines. KiBi.
Attachment:
signature.asc
Description: Digital signature