@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
AppArmor mount rules have had a lot of issues in the past (and still do)
depending on the version of kernel, the parser and the exact rule. If
you want an easy way out of this, setting `raw.apparmor=mount,` on your
container will almost certainly get such issues to disappear.
LXD 4.0 has a number
```
root@bos02-s390x-01:~# uname -a
Linux bos02-s390x-01 5.4.0-37-generic #41~18.04.1-Ubuntu SMP Mon Jun 8 13:36:31
UTC 2020 s390x s390x s390x GNU/Linux
root@bos02-s390x-01:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 18.04.4 LTS
Release:
Please ignore the juju reproducer then and focus on the failure on autopkgtest
infra.
The system set up by juju was upgraded from 18.04 as I wrote and the failure is
not that interesting for me. I'm interested in making the systemd autopkgtest
not failing.
--
You received this bug
** Changed in: lxd (Ubuntu)
Status: Incomplete => New
--
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:
snapd.seeded.service waits forever (?) to have snaps seeded in LXD on
"""
ubuntu@juju-d7a408-generic-21:~$ lxc --version
3.0.4
"""
Ubuntu 20.04 does not contain that version of LXD, so there's something
wrong with your system.
** Changed in: lxd (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
On s390x running 20.04 (upgraded from 18.04 and not rebooting after
that) as host:
ubuntu@juju-d7a408-generic-21:~$ lxc launch ubuntu-daily:groovy gg2
Creating gg2
Starting gg2
ubuntu@juju-d7a408-generic-21:~$ lxc shell gg2
root@gg2:~# service snapd.seeded status
● snapd.seeded.service - Wait
What's the actual reproducer for this?
```
stgraber@castiana:~/data/code/lxc/lxd (stgraber/master)$ lxc launch
ubuntu-daily:groovy gg-test
Creating gg-test
Starting gg-test
stgraber@castiana:~/data/code/lxc/lxd (stgraber/master)$ lxc shell gg-test
root@gg-test:~# service snapd.seeded status
●
@stgraber the simplest case failing is starting a not privileged container and
snapd.seeded.service is stuck in "running".
As the plan I'd like to fix both privileged and non-privileged containers to
let systemd enter non-degraded mode:
Looks like a privileged container without nesting enabled. This gets
some pretty strict apparmor rules to prevent trivial privilege
escalation. I'm not sure that there's really much that can be done here
especially considering the many issues with apparmor and its mount
rules.
We allow a lot more
@jdstrand It can be reproduced without autopkgtest being used. Adding
the lxd package per your comment because @stgraber man not monitor snapd
bugs.
** Also affects: lxd (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
@xnox - I took a look at the paste from Balint and all the denials seem
to be coming from lxd's policy. I don't know how the autopkgtest's lxd
apparmor policy is setup, but it may need adjusting. Perhaps @stgraber
can comment?
--
You received this bug notification because you are a member of
@jdstrand it sounds odd to have snapd seeding failing with apparmor
denials on s390x/arm64, can you take a look?
** Changed in: snapd (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Tags added: id-5ebd4319f41bed3faf85e184
--
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:
snapd.seeded.service waits forever (?) to have snaps seeded in LXD on
s390x and arm64
To
OK, so for anyone hitting this error until there may be a fix: For cases
where snapd is not needed (and perhaps purged later), and orchestration
relies on cloud-init to finish, the workaround in the container is:
systemctl stop snapd.seeded.service
or on the host:
lxc exec $CONTAINERNAME --
I believe this is really the bug that snapd cannot install "core" or
"core18" inside a container without failing on udev.
The well-known workaround is to do it twice.
I think we should sit down and discuss this but I think this can only be
done after core20 beta is out as we simply have no time
Have you tested this on amd64? I am seeing the same outputs on amd64 and
trying to find out if it is a regression or something in my config. A
similar report has suggestions it may be due to faulty network setup for
the container:
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1806070
--
# dmesg | grep DENIED | pastebinit
https://paste.ubuntu.com/p/5DXJb9RbWS/
root@clean-lacewing:~# ls -ld /snap
drwxr-xr-x 1 root root 46 May 12 13:37 /snap
It is a vanilla LXD container instance (on s390x), I have not done any changes
to it to trigger the issue apart from starting it.
--
You
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: snapd (Ubuntu)
Status: New => Confirmed
--
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:
The udev error is the well-known problem that of snapd pulling udev into
containers.
--
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:
snapd.seeded.service waits forever (?) to have
In the arm64 oops the error is:
"""
change "seed": "Initialize system state"
prerequisites: Undo
snap-setup: "snapd" (7267) ""
prepare-snap: Undoing
mount-snap: Undone
copy-snap-data: Undone
setup-profiles: Error
ERROR cannot reload udev rules: exit status 1
udev output:
Failed to send reload
We've retrieved the OOPS from the ID mentioned in the log you've
attached. It seems the error is
ERROR run hook "install": cannot perform operation: mount --rbind /snap
/snap: Permission denied
Can you provide the output of "dmesg | grep DENIED" please? In addition,
can you please add "ls -ld
# cat /var/lib/snapd/seed/seed.yaml
snaps:
-
name: core18
channel: stable
file: core18_1756.snap
-
name: snapd
channel: stable
file: snapd_7262.snap
-
name: lxd
channel: stable/ubuntu-20.10
file: lxd_14953.snap
# find /var/lib/snapd/seed/
This looks like a problem in the seed used to create this image. Can you
please attach:
/var/lib/snapd/seed/seed.yaml as well as find /var/lib/snapd/seed
please?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
This prevents creating LXD autopkgtest images on the affected
architectures, see latest systemd autopkgtest logs.
** Tags added: rls-gg-incoming
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1878225
25 matches
Mail list logo
