Installing Debian when debootstrap isn't available can be extremely
inconvenient, because the only alternative is the installer, which is:
- slow
- requires booting the media
- primarily aimed for stable
- inflexible and difficult to customize and/or automate

A better alternative in such situations is using debootstrapped
tarballs, which can be simply unpacked into a suitable mountpoint and
further configured (similar to Gentoo's stage3 tarballs). It should also
be faster as an installation method than using the Debian Installer.

Generating them can be quite straightforward, and doesn't even require
root privileges:
$ cdebootstrap --foreign --arch=ARCH [...]
$ tar [...]

Usecases:
- VM provisioning
- automated installs, possibly handing over to a configuration
management system
- rescue environments
- manual installation from an existing non-Debian OS
- custom setups unsupported by the Debian Installer

Generally, I don't think the Debian Installer is a good idea in such
cases, and it's best left for interactive installation.

Please consider distributing Debian in this manner.

Hi!

It's an option we're considering for work in the near future; we're
thinking of distributing images more than tarballs, though, to make
them more useful directly for a number of reasons. Mainly images will
be more useful for non-Linux users, I think.

Hi Eduard,

Given that you say, quite rightly, that it's pretty easy to generate
tarballs:

Eduard - Gabriel Munteanu <edgmnt@gmail.com> writes:
...

I'd suggest users would be better served learning to do that.
Especially if they plan to do any of the more complicated things you're
talking about.

We used to have a tarball that one could just drop onto a system (until
about 15 years ago IIRC) but it wasn't a very good solution, and you get
left with the job of doing all the bits that d-i does for you now to
make sure the result boots, and that the network works etc.

Anyone that can deal with those issues after installing a tarball should
have no trouble at all running {c}debootstrap themselves.

Might I suggest that if you have concrete examples of things that
you mention, like:

that you report bugs about those, with specific examples, because you
may find that you've just not noticed the way in which such setups are
supported, and will therefore find out that it is possible to do what
you want, or you will highlight real weaknesses in the installer, which
are then more likely to get fixed.

Certainly, for example, some multi-layered RAID/lvm/crypto setups are
rather difficult to arrange in an automated way in debian-installer, but
I see nothing in your suggestion that is going to address that weak
spot.  Instead you're wanting to have nothing at all to handle the
partitioning. I presume you're expecting people to do all that by other
means, in which case they should probably just use {c}debootstrap
directly onto the mounted partitions they just created.

For someone that has such a complicated setup, it seems unlikely that
they are going to best served by a tarball created with a different
setup in mind.  They are liable to find that they need to spend more
time kludging round the bits where the assumptions embodied by the
tarball don't fit their needs properly.

It would almost certainly be much better for them to use and understand
deboostrap directly, in which case they could build their own tarballs
if it suits their purpose.  Alternatively they could use and understand
debian-installer preseeding, if that suits them better.

Cheers, Phil.

Hi,

On Sun, 2014-09-21 at 21:46 +0100, Philip Hands wrote:

[snip]

What if {c}debootstrap isn't available in their environment? That's
specifically the case I was talking about.

I suppose we may consider distributing {c}debootstrap in a
distro-neutral, self-contained package, but I'm unsure how difficult
that is.

[snip]

There seems to be a fundamental issue with d-i in the usecases I
mentioned: d-i is a bootable installer meant to run on the target
machine. This translates to a very roundabout way of doing stuff if
installation involves a host OS, e.g. you'll need to set up a full
networked environment with DHCP and HTTP servers just to serve a preseed
file, in a way that's not abstracted / hidden at all. Or you'll have to
remaster a CD image to insert or change a preseed file.

I think this stems from the fact Debian / d-i is not separating concerns
well enough; namely it's mixing up the following, in a rather ad-hoc
manner:
- interactive user interface
- bootable environment
- disk setup helpers
- bootstrapping (note how d-i assumes you want a fully installed and
bootable system, not just a chroot)
- configuration management

[snip]


        Eduard

debootstrap was specifically written to not require anything from a
Debian system; it should work on just about any POSIX system.

At least that was the case a decade ago; I must admit I haven't been
following along very well.

If that's still the case, then all you really need is to do something
like "alien --to-tgz debootstrap*deb"