Current rpi images are broken

Status changed to 'Confirmed' because the bug affects multiple users.

The causes of the desktop images not launching into the first-time setup are as follows:

1. The first-time setup process is oem-config (or more specifically the GTK front-end of oem-config).

2. The oem-config process is launched by the systemd oem-config.service unit

3. The oem-config.service unit is launched by the systemd oem-config.target

4. The oem-config.target and oem-config.service units are *not* (as one might expect) installed by the oem-config package, but by the oem-config-prepare script

5. The oem-config-prepare script (which is part of the oem-config package) is called by ... drum roll, please ... a livecd-rootfs hack that hasn't made its way into the new ubuntu-image

The quick'n'easy (and horrid) fix is to add this hack [1] to ubuntu-image and have it run during the image build. The longer (but I think much cleaner) fix is to have the oem-config package itself install this service and target.

The questions this brings up are:

1. Does anybody install the oem-config package and *not* prepare it to run on first boot (and if so, why?).

2. What removes oem-config.service and oem-config.target? They're not present after first-time setup but they're not owned by any package so some process somewhere is deleting them manually (and will no longer need to do so if their ownership is moved to the oem-config package which is also removed during first-time setup).

If it turns out there *are* people that depend on installing oem-config and not having it run on first boot, the trivial work-around is to add another package (e.g. oem-config-first-boot) which owns (and sets up) the oem-config.service and oem-config.target units, which can be seeded alongside oem-config just by those that want it to run on first boot.

The second question is a little more complex if there are people that manually construct oem-config.service and/or oem-config.target, but still expect them to be cleaned up.

[1]: https://git.launchpad.net/ubuntu/+source/livecd-rootfs/tree/live-build/ubuntu/hooks/099-ubuntu-image-customization.chroot?h=applied%2Fubuntu%2Flunar#n14

As far as #2 goes, I would hazard a guess that it is /usr/sbin/oem-config-firstboot that is removing the service.

The current dailies are now launching oem-config successfully, and I've proceeded through first time set up with no issues (the initial fix for this didn't *quite* work due to another DNS-related issue, but that's now fixed as well).

There's one remaining issue: the resulting apt setup lacks the universe and multiverse components, but we'll treat that as a separate issue.