Re: speeding up installs
On Sat, Jun 08, 2019 at 06:36:30PM +0100, Simon McVittie wrote:
> 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
I want more customizability, not less!
Individual .debs are modular and can be cherry-picked.
> 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)
On modern hardware, parallelizing I/O makes it a lot faster. A blob is
supposed to be read linearly. You can split it into chunks to uncompress
individually but we already have that as individual packages.
Splitting too much has a compression ratio cost, but we'd then need some way
to combine packages into blocks compressed together. Which would be ok for
install .isos but not as hot for unstable repos that mutate often.
> and do the configuration steps during the first boot
> into the installed system.
I'd say it's better to ask the questions _during_ install. As soon as the
partitioner is done, we can start fetching+unpacking, and ask stuff like
root password, username or language while the network+CPU+disk are working.
Currently we have:
* a lot of questions before anything starts
* long wait: base install
* popcon
* short wait
* tasksel
* very long wait
* grub
I propose asking the questions in one non-interrupted series. Then the
user can go grab some tea, and so on. Or, if I'm successful, not have to
wait at all as by the time you're asked for root password, the install is
done.
And as my approach happens to require knowing the list of packages to
install beforehand, two stones with one bird...
> 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?
Why not?
I despise Red Hat's approach of installing everything but having it
disabled.
> 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
That's not what I'm optimizing for. My changes would make building the
image faster. What you do with it is another matter.
> 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.
Meh, let's install the system faster than it would take to read it from the
disk :) (2.5GB unpacked vs 750MB packed).
> > * 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.
Yeah. Such assumptions can be tested on current but not future packages;
the latter would require a Policy entry or updating installer data.
What I have in mind is having the installer data ship as a purely
declarative package. Besides keeping a list of packages which must have
their postinst run serially, and a list of tasks, being a real package means
it can have versioned Conflicts declared upon it. This way, you know
that a given .deb won't work with this installer.
Of course, erroring during install (but not producing a broken system) is
non-ideal, but that's only a last resort fallback for unforeseen problems.
If what I'm working on moves beyond mockups and vapourware, we can ask for
declarative diverts.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands
⢿⡄⠘⠷⠚⠋⠀ for Privacy.
⠈⠳⣄⠀⠀⠀⠀
Reply to: