snapd 2.40+18.04 ADT test failure with linux-bluefield

Bug #1849533 reported by Kleber Sacilotto de Souza
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux-bluefield (Ubuntu)
New
Undecided
Unassigned
Bionic
Confirmed
Undecided
Unassigned
snapd (Ubuntu)
Incomplete
Undecided
Unassigned
Bionic
Incomplete
Undecided
Unassigned

Bug Description

Testing failed on:
    arm64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/arm64/s/snapd/20191010_150200_d4eee@/log.gz

These are the last messages from the log:

+ export SPREAD_CORE_CHANNEL=stable
+ export SNAP_REEXEC=0
+ mkdir -p /etc/systemd/system/snapd.service.d
+ cat
+ systemctl daemon-reload
+ systemctl restart snapd
+ snap install --classic go
2019-10-10T15:01:23Z INFO Waiting for restart...
go 1.12.10 from Michael Hudson-Doyle (mwhudson) installed
+ export GOPATH=/tmp/go
+ /snap/bin/go get -u github.com/snapcore/spread/cmd/spread
Segmentation fault

I haven't found this issue in any of the other generic our cloud kernels running on arm64, so this might be specific to the bluefield kernel.

tags: added: kernel-adt-failure
description: updated
Changed in linux-bluefield (Ubuntu Bionic):
status: New → Confirmed
Revision history for this message
Ian Johnson (anonymouse67) wrote :

What shows up with `SNAPD_DEBUG=1 snap run go get -u ...`?

Also are there any denials in the system journal at the time of the segfault? i.e. `journalctl -e --no-pager -k`?

Changed in snapd (Ubuntu):
status: New → Incomplete
Changed in snapd (Ubuntu Bionic):
status: New → Incomplete
Revision history for this message
Kleber Sacilotto de Souza (kleber-souza) wrote :

Hi Ian,

Sorry for taking so long provide the requested info.

This is what I get from a arm64 VM running the latest linux-bluefield kernel (5.0.0-1011.21):

# SNAPD_DEBUG=1 snap run go get -u github.com/snapcore/spread/cmd/spread
2020/03/23 10:35:19.060409 cmd_linux.go:224: DEBUG: restarting into "/snap/core/current/usr/bin/snap"
2020/03/23 10:35:19.853191 cmd_run.go:364: DEBUG: SELinux not enabled
DEBUG: umask reset, old umask was 022
DEBUG: security tag: snap.go.go
DEBUG: executable: /snap/core/8691/usr/lib/snapd/snap-exec
DEBUG: confinement: classic
DEBUG: base snap: core
DEBUG: ruid: 0, euid: 0, suid: 0
DEBUG: rgid: 0, egid: 0, sgid: 0
DEBUG: apparmor label on snap-confine is: /snap/core/8691/usr/lib/snapd/snap-confine
DEBUG: apparmor mode is: enforce
DEBUG: preparing classic execution environment
DEBUG: creating lock directory /run/snapd/lock (if missing)
DEBUG: opening lock directory /run/snapd/lock
DEBUG: opening lock file: /run/snapd/lock/go.lock
DEBUG: sanity timeout initialized and set for 30 seconds
DEBUG: acquiring exclusive lock (scope go, uid 0)
DEBUG: sanity timeout reset and disabled
DEBUG: releasing lock 5
DEBUG: creating user data directory: /root/snap/go/5572
DEBUG: requesting changing of apparmor profile on next exec to snap.go.go
DEBUG: ruid: 0, euid: 0, suid: 0
DEBUG: loading bpf program for security tag snap.go.go
DEBUG: read 14 bytes from /var/lib/snapd/seccomp/bpf//snap.go.go.bin
DEBUG: execv(/snap/core/8691/usr/lib/snapd/snap-exec, /snap/core/8691/usr/lib/snapd/snap-exec...)
DEBUG: argv[1] = go
DEBUG: argv[2] = get
DEBUG: argv[3] = -u
DEBUG: argv[4] = github.com/snapcore/spread/cmd/spread
DEBUG: umask restored to 022
DEBUG: working directory restored to /root
Segmentation fault

There are nothing on the system journal at the time of the segfault.

Revision history for this message
Kleber Sacilotto de Souza (kleber-souza) wrote :

It's worth mentioning that I could not reproduce the issue on the same VM with the generic kernel.

summary: - snapd 2.40+18.04 ADT test failure with linux-bluefield 5.0.0-1003.12
+ snapd 2.40+18.04 ADT test failure with linux-bluefield
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.