© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
7020100
(Get the code!)
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-
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:/