Ubiquity Proposal - Add "minimal" setup with kernel parameter

Mathieu Trudel-Lapierre mathieu.tl at gmail.com
Tue Jul 25 16:46:42 UTC 2017

On Tue, Jul 11, 2017 at 11:31 AM, Carl Richell <carl at system76.com> wrote:

> System76 would like to use GNOME Initial Setup for user configuration.
> Currently, there is duplication with Ubiquity.
> We propose changing Ubiquity to add a “minimal” mode, triggered by a
> kernel parameter (a flag similar to how OEM install is triggered now). This
> enables flavors to use whichever version makes sense for them. System76’s
> Pop!_OS and the elementary OS team are interested in using “minimal”.
> Minimal might be attractive to Ubuntu w/ GNOME as well.
> “Minimal” will contain the least amount necessary to install the OS. We
> also prefer off-line installs with minimal which would remove options to
> download updates or install 3rd party software during install. This
> requires adding language packs to the iso when using minimal.
Why could this not be a variation on the OEM install type instead?
Installation can proceed as usual, but presumably you don't already know
the name of the user you're installing for. In all install cases you'll
need to at least take the steps of picking a language and keyboard mapping
for the installer (in case you need to also enter other information, such
as the OEM ID we ask for to differentiate OEM install batches, crypto
password, network authentication to reach a mirror, etc.). The difference
is that when you do an OEM install, you do the file copying phase, reboot
into an "OEM preparation" environment, so that you can do any further
customization of the actual setup (pre-installing some software that wasn't
done automatically, checking to make sure everything is as it should, etc).
Then you can tell the system that everything is ready, and reboot into the
"real" system customization phase that is done by the end user: user name,
hostname, timezone, and all of that jazz. Doing so via oem-config or GNOME
Initial Setup could just as well be a decision left to the OEM provider.

> Minimal screens:
> Welcome/Language Select - change: add KB Layout [1]
> Installation Type - change: move hostname here [2]
> If full disk encryption is chosen, Choose Security Key screen.
> --Timezone: we’d like to remove timezone but Ubiquity is crashing when we
> do so. More investigation is necessary.
> [1] KB layout currently comes after “Installation Type”. Users can’t set
> their layout before typing a full-disk encryption password. Moving KB
> layout forward would fix this. However, Ubuntu uses the first Welcome
> Screen to display both language and “Try Ubuntu” or “Install Ubuntu”. A
> couple of ideas:

I don't question the need to move the keyboard setup earlier, it just never
got to the top of my priority list. That said, there's already an easy
workaround, you can choose exactly what keyboard mapping you want before
you pick "Try" or "Install" if you booted in BIOS mode (I know, that
doesn't work in UEFI yet). We'll get to fixing this eventually (sorry!).

> [2] Hostname is currently on the “Who are you?” screen. It uses the
> username and DMI information to populate the hostname. We propose using the
> same DMI information, adding 4 hexadecimals to the end (a checksum of the
> MAC address “Galag-Pro-A8F3”), and moving the hostname up to the
> “Installation Type” screen. This enables “minimal” installs to set the
> hostname and business customers can install the OS on multiple machines,
> with automatic or custom hostnames, then give the computer to their user
> for account setup.
What would setting the hostname earlier actually bring as a benefit? You
can already set automatic/custom hostnames as an enterprise policy via
preseeding or via DHCP. For factory systems, it seems to me like there is
no benefit in setting any hostname at all (or if there is, please let me
know); it's a user decision what they want to call their machine. In an
enterprise setting, I would usually not expect people to use an OEM-type
install (even your 'minimal' proposal), but rather preseed the installation
parameters and only leave to users the few decisions that would make sense
-- in an enterprise setting, this often doesn't even include the username.

Making users further go through GNOME Initial Setup should already be
possible by configuring the final system via a preseed (ie. install the
right package, but the right files in so it starts when you log in).

My concerns with this are mainly that many of the "advantages" listed in
the design document [1] for Initial Setup are already covered by ubiquity
as far as I can tell (speed of install, being able to do unattended
installs, etc.); with the benefit that it's not tied to any particular
desktop environment: ubiquity (oem-config) should work just as well for any
desktop environment, without requiring the use of GNOME software (some
flavours may not want to use some, for various reasons). We let the end
user make customization decisions as late as possible so that we don't
block the installation unnecessarily while the user picks a hostname or
username. In my experience that tends to fit nicely in the time it takes to
complete the file copy (but otherwise, you're not blocking the end of the
installation much either).

I'm all for improving ubiquity by removing code duplication, doing a big
cleanup in that monstrous codebase, and simplifying the installation
process in general, but right now it seems to me like GNOME Initial Setup
would only solve this for a fraction of our users.

Could you come up with a code branch that does what you want and knows to
install GNOME Initial Setup, or with a pre-made image that mocks up how you
see things, so that we could play with it?

As for the flavours, aside for Kubuntu where shipping Initial Setup would
be bad (take up more space on their image and look very odd); how do you
feel about having such an Initial Setup step? How would it look?

[1] https://wiki.gnome.org/Design/OS/InitialSetup

/ Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20170725/c3277aae/attachment.html>

More information about the ubuntu-devel mailing list