[Bug 1943077] Re: snapd fails to autopkgtest on mksquashfs, which is looking for libgcc_s

[Ian Johnson]

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
Foundations Bugs, which is subscribed to squashfs-tools 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