Otherwise snap model --serial returns exit status 1 and thus can't really be
compared to the initial serial assertion from before the reinstallation.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
We need to wait for the system to finish re-seeding itself before using the
snap command, otherwise we are racing with snapd trying to seed itself.
Also delete a duplicated and unnecessary comment.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
This also in effect emulates many customer devices which have all their
partitions created during flashing.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* configcore: relax validation rules for hostname
The strict hostname validation rules in combination with the
fact that we now use the external configuration is broken.
If the hostname can be set externally via the hostnamectl
command we cannot have a validaton that is stricter then what
hostnamectl is doing.
This PR changes two things:
1. Only validate the hostname if it's set to in FSOnly apply mode,
i.e. when no hostnamectl call is issued [1].
2. Directly pass the hostname to hostnamectl and let it handle invalid
names. It has a concept of "static" and "pretty" hostname and will
apply even invalid hostnames as "pretty" hostnames. However it will
simplify/filter the pretty hostname so that it becomes a valid static
hostname. Because of this our logic to detect if the hostname has
changed needs to be tweaked to talk to hostnamectl instead of using
the "hostname" command that only gets the "static" hostname view.
This should fix the issues around hostname setting.
[1] https://github.com/systemd/systemd/blob/main/src/basic/hostname-util.c#L85
* conficore: improve comment
* configcore: add more tests
* tests: update spread tests for new and more flexible hostname handling
* configcore: fix typo (thanks to Miguel)
Don't fail in the debug section if we can't exec commands on the nested VM so
we can still get the generic debug output which will contain the serial log
too.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
This is to prevent an auto-refresh change for the snapd snap from happening
during the initial boot, see:
+ tests.nested copy /home/gopath/src/github.com/snapcore/snapd/tests/nested/manual/cloud-init-never-used-not-vuln/snapd-from-deb.snap
Warning: Permanently added '[localhost]:8022' (ECDSA) to the list of known hosts.
+ tests.nested exec 'sudo snap install snapd-from-deb.snap --dangerous'
Warning: Permanently added '[localhost]:8022' (ECDSA) to the list of known hosts.
error: snap "snapd" has "auto-refresh" change in progress
-----
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
Merge pull request #10925 from anonymouse64/feature/rename-uc20-nested-tests
This test had encryption temporarily disabled as part of #9632,
so it's now high time we re-enable it almost a year later /o\
To be clear, this PR is orthogonal to the tests mentioned in #10923, and specifically this test would not have caught the regression that that PR reverts. This test only would catch specific errors that result in not being able to refresh at all, while the regression in that PR is about a refresh which results in a reseal operation that happens after the new snapd is installed with an existing/old kernel. This test could possibly be extended to also trigger a reseal and cover that case, but I'm going to add that functionality to a different test instead since that's a bit involved and better to keep this test simple as-is I think.
Also rename some UC20 specific tests to make clear they are UC20 specific.
Merge pull request #10930 from anonymouse64/revert-10715-bump-secboot
Reverts #10715
Sadly the new version of secboot seems to auto-upgrade v1 keys to v2, which old recovery systems and even the currently published initrds/kernels do not understand so they fail to unlock the encrypted partitions in the initrd.
This PR includes #10929 which adds the following tests:
* test from stable snapd + stable kernel refreshing to snapd from the PR
* test from stable kernel + snapd from the PR
and for each variant then do something which triggers a reseal operation and a reboot to ensure that the new snapd will not break old recovery system kernels
Merge pull request #10926 from sergiocazzolato/tests-remove-extra-snaps-assertions-test
This test is not adding any value, and the description is not reflecting what the test is actually doing
Avoid the problem of snapd being auto-refreshed during first boot. We sometimes
see this issue because when we build the image, we end up with a snapd snap
from the stable channel, but then there is a new one available by the time the
image finishes booting, so snapd would try to auto-refresh itself
simultaneously while we were trying to install the new snapd snap.
So download and unpack the snap and seed it into the image as local, unasserted
snap to prevent snapd from refreshing itself.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
After recent switch to test-snapd-curl, there was no data being passed in the
request.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
This test ensures that new snapd when doing resealing on a system with an "old"
initrd (i.e. one that is currently published and not from the PR), we are able
to come back after the reboot to try the new kernel after resealing.
This test has two variants, one which starts with the new snapd and one which
starts with the old/existing snapd on the stable channel.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
This test had encryption temporarily disabled as part of snapcore/snapd#9632,
so it's now high time we re-enable it almost a year later /o\
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
The tests have been updated to use test-snapd-curl snap instead of http
snap
Also the code of the test-snapd-curl snap is included in the snapd repo,
which now is built based on the curl packge in ubuntu
