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

Re: new demo system -- chrooted!

On Wed, Jan 10, 2001 at 05:21:38PM -0800, Joey Hess wrote:
> Well I was thinknig if all the interaction was during preconfiguration,
> we wouldn't have to worry about that since we could reasonably expect
> there was no extraneous non-debconf-protocol output. 
> But on reflection, these packages are going to be using debconf only for
> critical level stuff, which often means failure messages, recovery from
> bad situations etc. Things that you run into in a postinst. 

Right. We could just declare "any failures are fatal, and will be reported
with a generic `Something bad happened trying to install the base system
:(' message", and maybe even get away with it, but... :-/

> So I don't think that we even need to preconfigure them. And we do need
> to redir the output somehow.

Well, we can't redirect the output unless we redirect their input too, and
we can't redirect their input while debconf needs it. :-/

> Can you refresh my memory about how the unix socket forwarding stuff
> would look?

Well, I thought I could, but I can't.

You'd need to have a Unix socket in /target/var/run/debconf.$$ or so
that the cdebconf frontend is listening on. This'd then be passed via
the environment to create_chroot.sh; which'd then remove the /target
prefix and pass it on to debconf-tiny from base.

But anna can't rely on /target/var/run being partitioned or formatted,
let alone setup with the appropriate socket in there. And cross-filesystem
hardlinks don't work, and you can't symlink out of a chroot.

Hmm. I guess another possibility would be create_chroot.sh setting up a
faux-passthrough frontend, so that it all ends up looking like:

        cdebconf-backend        /var/run/debconf.1  -- cdebconf-frontend
                        \        /          |
                        cdebconf            |
                               \            |
                        create_chroot.sh    |
                                chroot dpkg-preconfigure
                                         debconf ConfigDb backend

That is:
        * cdebconf only ever has a passthrough frontend
        * create_chroot.sh can duplicate the passthrough frontend into
        * possibly, then, the cdebconf-frontend may have to cope with
          multiple simultaneous connections across the socket? dunno
          about this one

All together now: yuck.

I've taken out base-config and switched to the Noninteractive frontend
for the moment instead...

> > Isn't the timezone asked earlier anyway? If it is (and still is with d-i),
> > then we can just use that answer.
> No, d-i is not going to configure timezone. Some real package in debian
> will have to do it after reboot.

Won't that break the timestamps on some of the files the installer creates
(/etc/fstab, eg) though? If, say, my hardware clock's set to localtime,
and my TZ is +1000?


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

Attachment: pgp86YvFWWIBy.pgp
Description: PGP signature

Reply to: