As seb128 found, the issue is also affecting the debian package of snapd
since when we call mksquashfs, we actually have code which specifically
calls mksquashfs from the "system" snap which is either the snapd snap
or the core snap, this is presumably to ensure that a consistent
mksquashfs is used always and to avoid snaps from being packed with too
old or new mksquashfs's.
So the net effect is that the fix for this that was landed into the
snapd snap will also probably need to be added to the core snap for
completeness, and also means that the only way to avoid snap pack from
failing is to have a snapd snap with the fix which is only available on
the edge channel currently.
So long story short, if you are affected by this today, a short-term
workaround is to use the edge channel of the snapd snap by running
snap refresh snapd --edge
We have already included the fix into the snapd snap that is built on
edge and it will be included in the release branch for 2.52, meaning
that the next bugfix release on 2.52 will have the fix, we do plan on
doing a 2.52.1 release in short order after 2.52 is complete, but it may
be a few weeks from now before that is on stable.
** Changed in: snapd
Milestone: None => 2.52
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1943077
Title:
snapd fails to autopkgtest on mksquashfs, which is looking for
libgcc_s
Status in snapd:
Fix Committed
Status in openssh package in Ubuntu:
New
Status in squashfs-tools package in Ubuntu:
New
Bug description:
During current snapd autopkgtest, a failure can be observed:
https://autopkgtest.ubuntu.com/results/autopkgtest-
impish/impish/amd64/s/snapd/20210907_175258_5451b@/log.gz
error: cannot pack
"/home/gopath/src/github.com/snapcore/snapd/tests/smoke/sandbox/test-snapd-sandbox":
mksquashfs call failed:
-----
libgcc_s.so.1 must be installed for pthread_cancel to work
Parallel mksquashfs: Using 1 processor
Creating 4.0 filesystem on
/home/gopath/src/github.com/snapcore/snapd/tests/smoke/sandbox/test-snapd-sandbox/test-snapd-sandbox_1.0_all.snap,
block size 131072.
-----
error: cannot read snap file: "/var/lib/snapd/snaps/.local-install-136125945"
is not a snap or snapdir
I traced the underlying call to the following:
"/snap/snapd/current/lib/x86_64-linux-gnu/ld-2.23.so" "--library-path"
"/snap/snapd/current/usr/local/lib:/snap/snapd/current/lib/x86_64-linux-gnu:/snap/snapd/current/usr/lib/x86_64-linux-gnu"
"/snap/snapd/current/usr/bin/mksquashfs" asdf asdf.squashfs
(the real call has more arguments, this is a simplified version that
produces the failure)
To observe this, one can create a VM based a cloud image from
https://cloud-images.ubuntu.com/impish/current, then run the above command in
the resulting environment.
Doing so will test against snapd v2.51.4 (12883).
Retesting with edge 2.52+git635.gada2d87 (13323) produces an equivalent
result.
Running a more bland `/snap/snapd/current/usr/bin/mksquashfs asdf
asdf.squashfs` without messing with library paths has mksquashfs behaving as
expected. Also, getting a v2.51.3 snapd seems to behave itself. Updating
from
2.51.3 -> 2.51.4 also works.
One can see a passing mksquashfs by taking libgcc_s.so.1 from hirsute
and placing it in the library path for the above call.
In the working scenario, it appears that libgcc_s is being obtained
from outside of /snap (and also libz). In the failing scenario, this
external copy of libgcc_s is not being loaded (per gdb info sharedlibrary),
but libz still is.
To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1943077/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
