Kernel oops when running devstack/stack.sh

[Andrew McDermott]

I was installing OpenStack using devstack/stack.sh and noticed that at some point a `pip install' had failed. I later untarred linux-3.19.1.tar.xz and get the same (or similar) kernel backtrace.

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: linux-image-3.19.0-9-generic 3.19.0-9.9
ProcVersionSignature: Ubuntu 3.19.0-9.9-generic 3.19.1
Uname: Linux 3.19.0-9-generic aarch64
AlsaDevices:
 total 0
 crw-rw---- 1 root audio 116, 1 Jan 1 1970 seq
 crw-rw---- 1 root audio 116, 33 Jan 1 1970 timer
AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
ApportVersion: 2.16.2-0ubuntu3
Architecture: arm64
ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/timer', '/dev/snd/seq'] failed with exit code 1:
CRDA: Error: [Errno 2] No such file or directory: 'iw'
Date: Tue Mar 17 16:06:05 2015
Lspci:

Lsusb: Error: command ['lsusb'] failed with exit code 1: unable to initialize libusb: -99
PciMultimedia:

ProcEnviron:
 TERM=screen-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB:

ProcKernelCmdLine: console=ttyS0,115200n8 root=/dev/sda1 rw rootwait
RelatedPackageVersions:
 linux-restricted-modules-3.19.0-9-generic N/A
 linux-backports-modules-3.19.0-9-generic N/A
 linux-firmware 1.143
RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
SourcePackage: linux
UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
UpgradeStatus: No upgrade log present (probably fresh install)
WifiSyslog:
---
AlsaDevices:
 total 0
 crw-rw---- 1 root audio 116, 1 Jan 1 1970 seq
 crw-rw---- 1 root audio 116, 33 Jan 1 1970 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 2.16.2-0ubuntu3
Architecture: arm64
ArecordDevices: Error: [Errno 2] No such file or directory
CRDA: Error: [Errno 2] No such file or directory
DistroRelease: Ubuntu 15.04
Lspci:

Lsusb: Error: command ['lsusb'] failed with exit code 1: unable to initialize libusb: -99
Package: linux (not installed)
PciMultimedia:

ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB:

ProcKernelCmdLine: console=ttyS0,115200n8 root=/dev/sda1 rw rootwait
ProcVersionSignature: User Name 3.19.0-9.9-generic 3.19.1
RelatedPackageVersions:
 linux-restricted-modules-3.19.0-9-generic N/A
 linux-backports-modules-3.19.0-9-generic N/A
 linux-firmware 1.143
RfKill: Error: [Errno 2] No such file or directory
Tags: vivid uec-images
UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
Uname: Linux 3.19.0-9-generic aarch64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm audio cdrom dialout dip floppy libvirtd netdev plugdev sudo video
_MarkForUpload: True

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1433183

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Andrew McDermott (frobware)]

I will try and reproduce - but this machine is automatically deployed and I have since destroyed it. Please bear with me.

[Chris J Arges (arges)]

I noticed you are on AArch64. Have you had this happen on other arches?
You said you saw a failure then tried the 3.19.1 vanilla kernel, which kernel version exactly did you use before?
Does devstack even work on aarch64 systems? Are you using a special devstack version?
Did this work on earlier kernels? I tried with Ubuntu trusty (3.13) on an xgene aarch64 machine and stack.sh did not fail on the pip install commands.

Thanks,
--chris j arges

[Andrew McDermott (frobware)]

Not noticed on other architectures as I am only testing against AArch64 at the moment. The failure was with the stock kernel that comes with the vivid cloud image (3.19.0-9-generic). I had been building and using 3.19.1 on Trusty (AArch64 again) for about 3 days and hadn't noticed the failure there, so I attempted to untar and build the kernel on vivid. The untar generated the same oops I saw with whatever devstack/stack.sh was doing at the time (which looked like pip install ...).

devstack has been working very well for me on AArch64 - I have been running it daily for months, so yes it does work on earlier kernels. Some of the results are captured here: http://openstack.validation.linaro.org/dashboard/image-charts/tempest-measurements.

This week has been the first time I have targeted vivid (and therefore 3.19.x).

[Andrew McDermott (frobware)]

I have seen this oops twice; I didn't report the issue first time round as the machine I was using had been powered down and I was unable to collect any logs. I happened to notice the stacktrace in my serial console window so I tried again and saw the issue again (and raised this bug). However, I have tried to reproduce it again this morning but 2 stack/unstack.sh have completed successfully - where success means no kernel oops. Each installation of OpenStack is done from a freshly installed cloud image so perhaps there have been other changes in that image since Monday/Tuesday this week.

[Andrew McDermott (frobware)]

apport information

[Andrew McDermott (frobware)]

apport information

[Andrew McDermott (frobware)]

apport information

[Andrew McDermott (frobware)]

apport information

[Andrew McDermott (frobware)]

apport information

[Andrew McDermott (frobware)]

apport information

[Andrew McDermott (frobware)]

apport information

[Andrew McDermott (frobware)]

apport information

[Andrew McDermott (frobware)]

The appport-collect I just did was from the same machine, but a different cloud image deployment (current/ 18-Mar-2015 06:05) . The recent attachments may/may not be useful to the original bug report. But if you look at the dmesg attachment you can see there is a different (and new) stacktrace. Apologies for the confusion.