Merge lp://staging/~taihsiangho/ubiquity/trusty-proposed into lp://staging/~ubuntu-installer/ubiquity/trusty-proposed

I'm concerned that this is very different from the way preseeding is normally done for installations or even oem settings -- oem-config itself simply uses whatever "real" debconf keys would be used on the installed system, which means you'd absolutely have to preseed those after the initial install, rather than being able to push everything at once at install time.

In other words; I think rather than having someone touch the installed system and specify extra boot parameters, or even preseed those in a late_command (or even more complicated, boot the installer with them), we should come up with install-time preseedable keys for the questions oem-config will ask.

Simply put; I'd make a copy of timezone, keyboard, etc. under the oem-config namespace, and teach ubiquity/oem-config to read those if we're running in the oem-config case, so that only the questions that are not seeded will be asked, and you can specify all of it at the time you start the installation process. This way, you can simplify things down to a user only having to fill in their name and password.

Additionally, this depends on having a file available on the filesystem already that contains all the necessary parameters; which is unlikely. One way to handle this better would be to allow using a URL like the preseed package does, but that will need changes in ubiquity itself rather than just the upstart job.

Since this particular merge is not incorrect, please provide more information whether this has been considered, and what the exact use case is that you want to fix here.

We'll need to fix this in Wily first as well, before we apply changes to Trusty.

With the right parameters i believe it was possible to run OOBE ubiquity with preseeded keys. And I believe it was even used in our old-style oem-config pre-seeding tests.

From:
https://wiki.ubuntu.com/DesktopCDOptions
https://wiki.ubuntu.com/UbiquityAutomation

You should pass (at the OOBE oem-config boot stage):
automatic-oem-config

which should run OOBE oem-config in non-interactive mode.

And then via:
preseed/early_command=/path/to/script.sh or url=http://my.server.com/preseed.cfg or file=/path/to/preseed.cfg it should be possible to pressed things that "a OOBE user clicks"

Obviously one will need different preseed files for oem-config install stage & oem-config OOBE stage to test various things.

@ Mathieu
Thanks for the comment.
I agree with we should come up with install-time preseedable keys for the questions oem-config will ask.
If we could specify those preseedable keys at the very beginning, say before the stage 1 is kicked off, that will be very nice.

I think your proposal is promising. Please let me think about the implementation details.
Besides, URL like preseed is useful in my case because I want to automate the whole installation (stage 1, 2 and 3) via PXE boot. The target system will be connected to the network.

@ Dimitri

Thanks for your comment. I have tried the following boot parameter at the OOBE oem-config boot stage:
1. automatic-oem-config: this works very well.
2. url=http://foo-bar/preseed.cfg and file=foo-bar/preseed.cfg. They did not work. I think this is rational because no more boot parameters are read by oem-config at the OOBE oem-config boot stage according to this code:

etc/init/oem-config.conf:
 35 for x in $(cat /proc/cmdline); do
 36 case $x in
 37 debug-oem-config)
 38 debug=--debug
 39 ;;
 40 # We never want to run the oem-config job in the live environment
 41 # (as is the case in some custom configurations) or in recovery
 42 # mode.
 43 boot=casper|single)
 44 exit 0
 45 ;;
 46 ubiquity/frontend=*)
 47 frontend="${x#*=}"
 48 export FRONTEND=$frontend
 49 ;;
 50 automatic-oem-config)
 51 automatic=--automatic
 52 ;;
 53 esac
 54 done

However,
preseed/early_command (or preseed/late_command) looks promising. I also found

oem-config oem-config/early_command string /usr/share/ubuntu/scripts/oem_config.sh early /dev/sda1 /cdrom
oem-config oem-config/late_command string /usr/share/ubuntu/scripts/oem_config.sh late

and /usr/share/ubuntu/scripts/oem_config.sh shows

 81 # Call the oem-config-general script for general types of tasks
 82 if [ -e "/usr/share/ubuntu/scripts/oem-config-general.sh" ]; then
 83 /usr/share/ubuntu/scripts/oem-config-general.sh $1
 84 fi

so I may do something by hooking up a oem-config-general.sh.

Or, just use preseed/early_command (or preseed/late_command).

Let me figure out when preseed/early_command (and preseed/late_command) will be applied and whether they meet my requirement or not first.

@ Dimitri

I wish that I could automate oem installation which comes with ubuntu-recovery.

In some customized images, for example OEM images, some of them have already use oem-config-general.sh. This means oem-config/early_command and oem-config/late_command are not a universal solutions because the hook, oem-config-general.sh, may be used by others at the beginning when that image was built. We could not just put our own.

We have tried to preseed oem-config/early_command and oem-config/late_command at stage 1 installation to use our own script which could include oem_config.sh and oem-config-general.sh,
but both of them will be overwritten by ubuntu-recovery anyway.[1]
We can not actually use our own oem-config/early_command and oem-config/late_command script.

We need a another hook or way to hook up our own customized scripts.

[1]
Please refer to these code snippet:
ubuntu-recovery/ubiquity/ubuntu-bootstrap.py unset_drive_preseeds()
.
ubuntu-recovery/ubiquity/ubuntu-bootstrap.py:1290 → early = '/usr/share/ubuntu/scripts/oem_config.sh early %s %s' % (rec_part['device'], location)
.
ubuntu-recovery/casper/seeds/ubuntu.cfg:138 → d-i oem-config/late_command string /usr/share/ubuntu/scripts/oem_config.sh late