@snapd team
This is automated, unattended deployments, which have no ability to
"stop snapd.seeding, and run it again". That's not an acceptable
solution. The unit is pulled into the initial transaction, failing or
stopping it, will make the transaction fail, and will fail to complete
the boot correctly and finish cloud-init on first boot, which needs to
install snaps and have operation snapd which has completed seeding.
It sounds like we must remove seeded snaps from our LXD images, and not
install any seeded snaps inside our container. And like only install the
lxd stub deb. Cause it looks like seeding snaps is not supported inside
classic lxd containers.
** Changed in: snapd (Ubuntu)
Importance: High => Critical
** Also affects: snapd
Importance: Undecided
Status: New
** Also affects: cloud-images
Importance: Undecided
Status: New
** Summary changed:
- snapd.seeded.service waits forever (?) to have snaps seeded in LXD on s390x
and arm64
+ Please remove lxd.snap from lxd images, as it fails to seed thus failing the
first boot - snapd.seeded.service waits forever (?) to have snaps seeded in LXD
on s390x and arm64
** Changed in: autopkgtest (Ubuntu)
Status: New => Invalid
** Changed in: auto-package-testing
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1878225
Title:
Please remove lxd.snap from lxd images, as it fails to seed thus
failing the first boot - snapd.seeded.service waits forever (?) to
have snaps seeded in LXD on s390x and arm64
To manage notifications about this bug go to:
https://bugs.launchpad.net/auto-package-testing/+bug/1878225/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
