snapd 2.40+18.04 ADT test failure with linux-bluefield

Bug #1849533 reported by Kleber Sacilotto de Souza on 2019-10-23
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux-bluefield (Ubuntu)
snapd (Ubuntu)

Bug Description

Testing failed on:

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
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
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

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
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] =
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.

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  Edit
Everyone can see this information.

Other bug subscribers