Re: new demo system -- chrooted!
On Tue, Jan 09, 2001 at 08:16:58PM -0800, Joey Hess wrote:
> > * you end up having downloaded the latest versions of a bunch of .debs
> > and your /var/cache/apt/archives directory is already populated
> > with 'em
> That's a good thing? :-P
Packages and Release files get put in the right place now too, dunno if I've
uploaded a version that does that yet though. :)
Main reason for it is that it's the only place where there should
*definitely* be enough space to do it. And it seemed kinda cute.
> > * get_debs.sh doesn't seem to work properly with busybox wget, or
> > busybox wget doesn't support proxies or something. It *should*
> > work, but it just doesn't seem to
> Could you try to use anna and/or the debian-installer retreiver system
> here? We need it to support grabbing Packages and debs from whatever
> medium is being used, which might be a cd or whatever.
Sure, that's the plan.
> > Note that a lot of the complexity from b-f's disappears if you're
> > allowed to interact with the end user while you're dpkg -i'ing the
> > base packages...
> This is the part I really dislike. The user should not be bothered by a
> binch of questions about what debconf frontend and what keymap and a
> million other questions (that I forget) when they are doing a fresh
> install.
The debconf frontend should really be passed through to the udeb frontend;
the keymap should already have been determined.
> (I hate investing a lot of time into
> installing and configuring something and only then find out that lilo is
> broken.)
This reason makes the most sense to me. So, basically, configuration should
go like:
* ask just enough questions to build a self-sufficient system &
install it
* boot said system
* ask the remainder of the questions
* install the system
If you ask more questions initially, and the boot doesn't work, you've
wasted the installer's time. Otherwise, you should ask all the remaining
questions as close as possible to at once.
Which means things like the "should sshd run" should probably be treated
as "no" until the remaining questions have been asked (since the people'll
who'll say no would probably much rather sshd *never* be active) [0].
(And then of course there's the notes like "The Jewish and Hindi calendar
files are outdated"... Grrr.)
> I think the program needs to set the debconf priority to critical so only
> the most important question will be displayed (and if packages abuse
> that they get bugs file or we invent an even higher priority level).
We might be better of setting an environment variable (or touching a
/setting-up-base-system file) too, and using the same priority setting
as anna/cdebconf are using (which seems like it'd handle the new lilo
deb better, maybe).
> Packages that don't use debconf should not be allowed to display
> anything at all, and the dpkg log should be redirected to a log file
> and/or some other console.
I don't think there's anyway for me to do this atm? Did anything happen
with the unix domain socket debconf frontend thing? If I could use
something like that to talk through the chroot to the anna/cdebconf
frontend, that'd be pretty choice I guess.
> My other problem with this idea are that I feel it makes the
> installation a little bit less robust (we discussed this on irc). I
> would feel a lot better about it if it didn't have quite so many special
> cases.
Okay. Special cases:
* perl-5.005 junk, should go away with hopefully new perl packages
* devices stuff. difficult. would go away with devfs on b-f's :)
* lilo needs a real fstab to configure properly, should go away
when plugged into an installer
* the essential pkgs install is:
- unpack everything manually
+ lie to dpkg and tell it it's installed
+ forcefully add base-files, base-passwd, ldso
+ forcefully add dpkg
+ forcefully add libc6 (which likes to have a timezone, or
it'll prompt)
+ forcefully add perl-5.005 (and take care of its symlink)
- install debconf-tiny
- preconfigure everything
- install everything, in the knowledge that all they're
dependencies are already unpacked, even if dpkg doesn't
know this
the +'s points could probably be gotten rid of. i can't seem to
get the base*,ldso,dpkg,libc6 set shortened though without things
dying. how annoying.
Some risky sorts of things:
* some programs need procfs in the chroot, and some package mounts
dev/pts when it's installed :-/
* start-stop-daemon gets replaced by true to stop daemons from
starting
There's some other special cases in there that've been fixed since potato
too, actually; the ldconfig.new stuff eg.
Cheers,
aj
[0] Of course, there's probably no real reason to have ssh be in base
anyway, it was more of a test to see if I could get debs from non-US
if available. inetd asking if echo and discard and so on should be
enabled, might be a better example, although it never asks in the
first place.
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``Thanks to all avid pokers out there''
-- linux.conf.au, 17-20 January 2001
Reply to: