Re: speeding up installs
On Fri, 07 Jun 2019 at 19:29:49 +0200, Adam Borowski wrote:
> A desktop install can writeout
> while the user answers installer questions
I can't help wondering whether the right answer for a finite number
of relatively predictable installations (a minimal system, or all of
Priority: standard, or all of [insert favourite desktop environment
here]) is to build a pre-prepared installation image, unpack it onto
disk as one big blob (some compressed archive, or an unpacked tree on
the installation media, or OSTree, or OCI, or whatever other format is
most appropriate), and do the configuration steps during the first boot
into the installed system.
Smaller customizations like whether to install sshd or not could be done
during first-boot; larger customizations like "I want to install both
GNOME and KDE" are less suitable for this, but is that common enough to
be optimizing for?
This is the approach assumed by gnome-initial-setup, which we don't
really support in Debian yet (it's automatically run by gdm if there are
no users in the "ordinary user" uid range, but d-i never sets up that
situation), and also one of the modes the cross-desktop/cross-distro
Calamares installer can work in.
It's also very suitable for preinstalled hardware, where it's sometimes
referred to as the "out of the box experience": the hardware vendor does
the partitioning and the "unpack installation image" step (in practice
via a disk image), then ships the device, and the buyer starts from the
first boot into the installed system (which could start by expanding
the disk image from its minimal size to a disk-filling partition, so
one disk image can work for many disk sizes).
If the pre-prepared installation image is in a suitable format (for
example an unpacked tree, squashfs or OSTree, but not a tarball or an
OCI image), then there's no reason it couldn't also be bootable as a
stateless live system.
> * almost all Pre-Depends and preinsts care only about upgrades
> * dpkg-diverts can be a problem but going yolo seems to work for me so far
These seem fine for a prototype, but also like the sort of assumption
that is likely to come back to haunt you when moving from prototype to
production, unless supported by Policy requiring some identifiable class
of bad things not to happen.
smcv
Reply to: