works almost with ubiquity

http://askubuntu.com/questions/36671/how-do-i-pre-install-ubuntu-for-someone-oem-install

• start in OEM mode (e.g. oem-config/enable=true in grub cmdline of ISO)
• install
• reboot
• in installed system sudo apt install oem-config oem-config-kde (probably not working out of the box because of T2853)
• at this point one could do additional modifications
• sudo oem-config-prepare will put the system into deployment mode
• reboot
• oem-config-kde is actually starting now and allowing the configuration of the system
  • has a bug with continue button enabled on last screen
  • we do not have a slideshow here, so last screen is blank background
• system should auto reboot
• [BUG] sddm shits its pants because autologin is still set to the temporary OEM user which was removed by oem-config. supposedly oem-config or casper also needs to un-mangle sddm.conf

Discussed on telegram. Calamares would be the more reasonable software to use as the python-kde code is in a bad state and Qt4 and baldy integrated. Calamares does have inferior OEM support and user home encryption for OEM isn't a thing apparently (that's only nice-to-have IMO though).

Biggest problem with calamares is that using it is blocked by T3206 which hasn't even been started. Given the importance of the installer, from T3206 being implemented to us actually wanting to use it in a device we'd want to have at least a month of implicit QA through user adoption (i.e. having regular neon ISOs roll with calamares only). Doing so before then only calls for problems as getting updates onto devices is hard or even impossible.

Or maybe it just is easier to do with ubiquity? I feel like this could drag forever...

Seeing as calamares has been drag on for 11 months, I am guessing the chances of it getting dragged on forever are fairly good

Assuming we fix the continue button bug and give it a slideshow, ubiquity should do nicely as well. We'd have to keep our fingers crossed that it doesn't break.

Unless there are objections by Friday I'll work on OEM mode fixes next week.

So, I have most issues covered now. Jens and I refined the sidebar a bit so it doesn't look so shitty.

• broken continue button is caused by lack of slideshow in oem install, either install manually in oem session or I think I have a fix which should prevent the slideshow from disappearing
• kwin rules need probably manual creation. I may be able to dump a sane config in place via the oem configuration UI that comes up when the user starts the system but I am not sure that will work reliably
• mini/maximize needs a decoration setting via systemsettings as I cannot make windowflags do the job. same caveat as with window rules applies
• Jens wanted to have a more proper welcome screen, alas, I think we don't want to spend the necesary amount of engineering on this (needs l10n set up for python bits, which already has l10n from ubuntu...)
• autologin retention is weird and I am not sure how this even works for ubuntu TBH, there's casper which creates the original autologin but if that applied it would twiddle the existing autologin to login the configured user instead. there's also code in share/ubiquity which would move /etc/foodm.conf.oem over /etc/foodm.conf, what purpose that serves or where foodm.conf.oem comes from is not clear though. chances are the OEM session should simply have an empty /etc/sddm.conf.oem and ubiquity needs patching to support sddm.conf as a name and then sddm.conf gets wiped upon OEMing. whether or not that is appropriate is another question (e.g. if sddm.conf is installed by sddm proper then overwriting it thusly would cause a dpkg diff conflict moving forward)
• Jens wants to do some slideshowing, which is kinda hindered by not having any l10n infrastructure set up, as a stop gap a more manual approach may be employed.
• going to start landing the ubiquity changes as they need some additional QA what with being installer changes and all

Overall I think the OEM experience is really good and more or less snazzy looking.

First part here https://code.launchpad.net/~apachelogger/ubiquity-neon/icantwritetotrunk/+merge/313754

It's probably worthwhile to look into building the oem kwin configs through the scripts somehow as the actual OEM systems may be installed by a human, so the less fiddling the better.

Development ISOs as of today should have a fully working OEM mode (pending final verification). I am going to move this to review and proceed with slideshow touch-up separately as it's only related on a technical but not functional level.

To use oem mode

• BIOS systems: hit esc during first splash ➔ boot menu comes up ➔ hit f4 ➔ change mode to OEM ➔ hit enter to boot
• UEFI systems: in ISO GRUB hit e to edit the entry ➔ append oem-config/enable=true to the initrd line ➔ hit ctrl-x to boot

Session will look much the same but the installer itself will say something like 'Install Neon - OEM mode' in the window frame and the user setup will have oem as user name pre-set-up. Once installed the system will boot into OEM preparation mode. In this mode the system can be altered as necessary (updates applied, software installed, install languages etc.).
Once the system is ready to ship it can be switched into firstboot mode by running sudo oem-config-prepare. On the next boot the first start wizard comes up to guide the user through setting up keyboard/locale/timezone/user. Once complete the system is ready to use.

documentation as requested https://userbase.kde.org/Neon/Installation/OEM

works good on uefi and bios, well done. It may be polite to e-mail any fixes to ubiquity to kubuntu as they've had it broken for years.

implementing this in calamares is another job coming soon.