- Use updated probert *Info class for accessing object data
- Add --dry-run parameter to prevent invoking curtin when testing
- Add new make target to run ui-view by default with --dry-run
- Use a template to write out curtin config file for installation
- Use virtio disks and multiple nics to test probing.
Signed-off-by: Ryan Harper <ryan.harper@canonical.com>
Update subiquity welcome controller to call probert to extract
host information and present it to the user briefly before
invokin the curtin installer.
Add the install_src to git clone probert. Pack this as a tarball
in the user-data like subiquity.
Update user-data package installs for new probert deps.
Modify boot parameters to handle systemd persistent nic naming;
we may not always have eth0 as a nic. Subsequently update
user-data to use bootcmd to automatically attempt to bring up
nics during the boot before the installer.
Finally fix commandline parsing/output in geninstaller.
Implement version parameter and better caching of previous
maas ephemeral images.
Fix issue with removing cache after unpacking rootfs which is
now owned by root (add sudo to rm of cache).
Signed-off-by: Ryan Harper <ryan.harper@canonical.com>
Hacky method, but in welcome controller, use subprocess to
call a script which invokes curtin at a known location with
a specific set of parameters.
Modify the installer configuration and start-up scripts to
ensure Subiquity runs on tty1 and keeps the service running.
Upon hitting 'Confirm' Subiquity will exec curtin_wrap.sh
which calls the *real* curtin. Cloud-init user-data has been
modified to unpack the curtin archive embedded.
When complete, the target.img file is bootable.
Signed-off-by: Ryan Harper <ryan.harper@canonical.com>
- Tar up the subiquity code and inject that into the user-data
- Add support for encoding when adding binary files
- Until we have a way to detect serial presence, run installer on tty1
- Add power_state hook to shut machine off after subiquity exits
- git status ignore image file in installer dir
Signed-off-by: Ryan Harper <ryan.harper@canonical.com>
Ryan Harper