Dan, note that although we set the SNAP_REEXEC environment variable in that integration test, that environment variable is actually not obeyed when it comes to the mksquashfs command which is called here:
https://github.com/snapcore/snapd/blob/dfba7de59a41bc22786d87f53b20deea14240713/snap/squashfs/squashfs.go#L524 and the function snapdtool.CommandFromSystemSnap does not observe the SNAP_REEXEC environment variable at all, instead just checking if the snapd or core snaps exist at all, and using the mksquashfs from those snaps instead of what's on the host on $PATH (though we do fallback and if there is no mksquashfs found in the core or snapd snaps (somehow???), then we use $PATH). As I mentioned on IRC, we could potentially someday add a workaround where if mksquashfs from the system snap specifically segfaults then we will fall back to using the host's mksquashfs, but we have chosen for now not to work on that patch. Hope this helps explain things. -- 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 : [email protected] Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
