Merge ~waveform/ubiquity:prepare-package into ubiquity:main

[Dave Jones]

[Steve Langasek (vorlon)]

given that the intention is to drop ubiquity out of main entirely for 24.04 (either leaving it for community flavors to maintain in universe if they continue to rely on it, or dropping it from the archive), I'm uncomfortable with the introduction of new code here related to oem-config, the bit of ubiquity that we don't yet have replaced in main. What is the larger plan for superseding this bit of code in 24.04, and can we accelerate that instead?

review: Needs Information

[Dave Jones (waveform)]

I'm told the plan is for subiquity to grow this functionality, but I've no details on delivery (which makes me at least want a backup plan in place). Incidentally, this isn't new code as such: it's code from livecd-rootfs that should've been in oem-config all along. One of the merges in the associated ticket [1] removes that code from livecd-rootfs, this merge places it in an extra package here, and then the final merge from the ticket [2] uses this package in the image definition yaml (which is currently missing all the user setup stuff).

[1]: https://code.launchpad.net/~waveform/livecd-rootfs/+git/livecd-rootfs/+merge/456463

[2]: https://code.launchpad.net/~waveform/ubuntu-images/+git/ubuntu-images/+merge/456465

[Julian Andres Klode (juliank)]

Frankly I do prefer keeping that in livecd-rootfs until we have dropped ubiquity and a final solution rather than add a binary here for a couple of weeks.

[Dave Jones (waveform)]

Re: keeping it in livecd-rootfs: we don't use livecd-rootfs for building the Pi images anymore, so if I wind up needing this as a fallback for the desktop images, it's not going to do any good there.

Having now trawled the desktop engineering Jira, it appears the plan is to deliver this via the Ubuntu Welcome application in 24.04, and things appear to be progressing well (I'll see if I can find some time to play with it in the new year). Still, I like having a plan B to fall back on, just in case (having needed them in the past!). If Ubuntu Welcome lands in time, all well and good, everyone can ignore this extra package and/or remove ubiquity entirely from the archive -- it won't make any difference. If Ubuntu Welcome *doesn't* land in time, this will be required for the Pi desktop images to work at all.

[Michael Hudson-Doyle (mwhudson)]

On Fri, 15 Dec 2023 at 05:56, Dave Jones <email address hidden>
wrote:

> Having now trawled the desktop engineering Jira, it appears the plan is to
> deliver this via the Ubuntu Welcome application in 24.04, and things appear
> to be progressing well (I'll see if I can find some time to play with it in
> the new year).

Please do this uh, conversationally :-) (i.e. talk to the desktop people
about your needs!)

> Still, I like having a plan B to fall back on, just in case (having needed
> them in the past!). If Ubuntu Welcome lands in time, all well and good,
> everyone can ignore this extra package and/or remove ubiquity entirely from
> the archive -- it won't make any difference. If Ubuntu Welcome *doesn't*
> land in time, this will be required for the Pi desktop images to work at
> all.
>

I think plan B on the desktop side is to use gnome-initial-setup. Can that
be made to work for the pi desktop image?

Cheers,
mwh

[Dave Jones (waveform)]

Circling back to this; my understanding was the gnome-initial-setup was considered at some stage but rejected in favour of modifying the new installer to fit the pre-installed use-case. Obviously this didn't happen in noble, and we wound up sticking with oem-config there for the initial release.

I'm still not entirely clear on how those image builds even work because without this patch, the oem user *shouldn't* exist in the images for oem-config-prepare to run successfully (to be clear: the image *doesn't* build successfully in ubuntu-image locally without this patch). Probably something buried in livefs somewhere.

[Sebastien Bacher (seb128)]

I don't have enough context to know what part of the oem config mode the pi image needs but on a standard desktop installation if there is no user created gnome-initial-setup will start in initial-user mode which allows creating the account and setting up language/keyboard/timezone for the system

[Dave Jones (waveform)]

The pi images use (and have always used) oem-config for the initial user setup (and language, timezone, keyboard, etc). The only bit that gnome-initial-setup takes care of is the greeter after the (freshly created) user first logs in.

Incidentally, I've now discussed the requirements of the pi desktop with the installer team; while support for pre-installed images is planned this cycle, it is unlikely that the specific pi case will be supported this cycle (it'd be "nice to have", but I take that as "unlikely"). So, given we'll likely have oem-config again this cycle, I'd really like to get this merged so I can build test images cleanly.

Unmerged commits

7af8f68... by Dave Jones on 2023-09-29

Add oem-config-prepare package

As the package description states, this is intended for use in image
builds to avoid resorting to hooks to execute oem-config-prepare. The
script is executed in this package's postinst instead (and the
oem-config package subsequently removes itself, and thus this package
which depends on it, after run on first boot)

diff --git a/debian/changelog b/debian/changelog
index 5da3681..67f8ba9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+ubiquity (24.04.6) UNRELEASED; urgency=medium
+
+  * Add oem-config-prepare package (LP: #2038098)
+
+ -- Dave Jones <[e-mail]>  Fri, 19 Apr 2024 10:31:04 +0100
+
 ubiquity (24.04.5) noble; urgency=medium
 
   [ Dave Jones ]
diff --git a/debian/control b/debian/control
index d21fa72..73a6cbd 100644
--- a/debian/control
+++ b/debian/control
@@ -242,6 +242,20 @@ Description: KDE frontend for end-user post-OEM-install configuration
  .
  This is a KDE frontend to oem-config.
 
+Package: oem-config-prepare
+Architecture: all
+Depends: oem-config (= ${source:Version}),
+         ${misc:Depends}
+Description: prepares an image for execution of oem-config on first boot
+ The oem-config script re-asks a number of questions that are normally asked
+ during installation, and reconfigures the system accordingly. This allows a
+ vendor to install a skeleton system, clone it onto a large number of
+ machines, and ship it to end users, while still allowing end users to set
+ up their own username and password, language, timezone, and so on.
+ .
+ This package executes oem-config-prepare in its postinst, and is intended for
+ use in preinstalled image builds to avoid resorting to hooks.
+
 Package: oem-config-debconf
 Architecture: all
 Depends: oem-config (= ${source:Version}),
diff --git a/debian/oem-config-prepare.postinst b/debian/oem-config-prepare.postinst
 new file mode 100644
index 0000000..46adcd2
--- /dev/null
+++ b/debian/oem-config-prepare.postinst
@@ -0,0 +1,13 @@
+#!/bin/sh
+
+set -e
+
+if [ "$1" = "configure" ]; then
+	/usr/sbin/useradd -d /home/oem -G adm,sudo -m -N -u 29999 oem
+	/usr/sbin/oem-config-prepare --quiet
+	touch "/var/lib/oem-config/run"
+fi
+
+#DEBHELPER#
+
+exit 0