Replace ioutil.WriteFile with os.WriteFile since the former has been
deprecated since go1.16 and simply calls the latter.
Signed-off-by: Miguel Pires <miguel.pires@canonical.com>
The location of these directories depends on the model.
E.g. `InstallHostWritableDir` is
- on classic: `/run/mnt/ubuntu-data`
- on core: `/run/mnt/ubuntu-data/system-data`
So these dirs need to take a minimal model interface instead
of being strings.
had to make the comment in wrappers/services_test.go a one-liner
otherwise half of it is lost
last set of files needing changing (as per current master)
to achieve this change the signature of MakeBootableImage (also drop
now unused argument)
setImageBootFlags needed adjustments and also the tests using it
Thanks to Maciej for the suggestions.
Also expand the unit test, also from Maciej's suggestion
Co-authored-by: Maciej Borzecki <maciek.borzecki@gmail.com>
Return a list of locations, since there could hypothetically be multiple mount
points for ubuntu-data, such as in run mode where there is both "/" and
"/run/mnt/data".
Also verify that the install mode directory actually exists before returning
it. While we expect that this function will primarily be used during the
install-device hook which runs by definition after the partitions are created,
it is possible someday we could use this function at a time in install mode
where the partitions haven't been created and thus the mount point doesn't
exist.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* boot,tests: move where we write boot-flags one level up
/run/snapd/snap-bootstrap is a scratch directory and user space
shouldn't care a lot about it
* cmd/snap-bootstrap/initramfs-mounts: fix boot-flags location from initramfs
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
Co-authored-by: Ian Johnson <ian.johnson@canonical.com>
This function is meant to be used by snap{,ctl} system-mode in reporting the
location of ubuntu-data as it is used by run mode. For recover mode in order to
find the location of ubuntu-data, we need to parse degraded.json to get the
mount-location and mount-state, but for the other modes the directory is
statically known.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
When the flags are filtered out to only be the ones that are currently
understood, then we return a specific error type that can be checked for in
addition to the full set of understood boot flags. This allows more robust
implementations to process understood/supported boot flags while still logging
unknown ones that pop up from untrusted places like the bootenv or possibly a
newer snapd that we reverted away from (or one that was newer and running in
run mode, but now we are running in recover mode).
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
Add a family of functions for reading and writing boot-flags in various
contexts:
* Reading the current effective boot flags from either the modeenv or the
bootenv from the initramfs depending on the mode.
* Writing the current effective boot flags to a file in /run from the initramfs
* Reading the current effective boot flags from userspace (this is from a file
in /run)
* Writing the next boot flags to the modeenv from userspace
* Reading the next boot flags from the modeenv from userspace
* Writing the next boot flags to the bootenv during snap
prepare-image/ubuntu-image time
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
