Cannot boot trusty kernel on qemu-system-arm

Bug #1303657 reported by Ryan Finnie on 2014-04-07
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Paolo Pisati
Paolo Pisati

Bug Description

== SRU Justification ==

Upon d-r-u of a qemu ARM guest from saucy to trusty, the kernel no longer boots:

== Fix ==

Build the correct dtb for this board and disable the console-over-jtag


Apply the attached patches, recompile and install.

== Impact ==

Kernel hangs at boot.

== Test Case ==

Try booting your installation with and without those fixes.

U-Boot 2013.10 (Nov 23 2013 - 04:30:10)

WARNING: Caches not enabled
Flash: 256 MiB
In: serial
Out: serial
Err: serial
Net: smc911x-0
Hit any key to stop autoboot: 0
reading boot.scr
352 bytes read in 28 ms (11.7 KiB/s)
## Executing script at 60000000
reading vmlinuz
5474584 bytes read in 958 ms (5.4 MiB/s)
reading initrd.img
17883834 bytes read in 3013 ms (5.7 MiB/s)
reading board.dtb
11863 bytes read in 6 ms (1.9 MiB/s)
Kernel image @ 0x60008000 [ 0x000000 - 0x538918 ]
## Flattened Device Tree blob at 62008000
   Booting using the fdt blob at 0x62008000
   Using Device Tree in place at 62008000, end 6200de56

Starting kernel ...


At this point, the host CPU just spins. The previous kernel from saucy (3.11.0-19-generic) boots correctly into the trusty environment.

The VM is being launched as so:

export QEMU_AUDIO_DRV=none
exec qemu-system-arm -display none -M vexpress-a9 -kernel /srv/arm-dev/u-boot -m 1024 \
    -serial stdio -net nic,model=lan9118,macaddr=52:54:00:68:90:14 \
    -net tap,ifname=arm-dev,script=no,downscript=no -sd /dev/mapper/host-arm_dev \
    -pflash /srv/arm-dev/pflash1.img -pflash /srv/arm-dev/pflash2.img -smp 1

The flash images are unused; the scr points to the SD:

fatload mmc 0:1 0x60008000 vmlinuz
fatload mmc 0:1 0x61008000 initrd.img
fatload mmc 0:1 0x62008000 board.dtb
setenv bootargs console=ttyAMA0,38400 root=/dev/mmcblk0p2 nosmp
setenv fdt_high 0xffffffff
setenv initrd_high 0xffffffff
bootz 0x60008000 0x61008000:0x1000000 0x62008000

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-image-3.13.0-23-generic 3.13.0-23.45
ProcVersionSignature: Ubuntu 3.11.0-19.33-generic
Uname: Linux 3.11.0-19-generic armv7l
AlsaVersion: Advanced Linux Sound Architecture Driver Version k3.11.0-19-generic.
AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
ApportVersion: 2.14.1-0ubuntu1
Architecture: armhf
ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', '/dev/snd/controlC0', '/dev/snd/pcmC0D0c', '/dev/snd/pcmC0D0p', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
CRDA: Error: [Errno 2] No such file or directory: 'iw' Error: [Errno 2] No such file or directory: 'amixer'
Card0.Amixer.values: Error: [Errno 2] No such file or directory: 'amixer'
CurrentDmesg: [ 113.007517] init: plymouth-upstart-bridge main process ended, respawning
Date: Mon Apr 7 01:23:13 2014
IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'

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

 PATH=(custom, no user)

ProcKernelCmdLine: console=ttyAMA0,38400 root=/dev/mmcblk0p2 nosmp
 linux-restricted-modules-3.11.0-19-generic N/A
 linux-backports-modules-3.11.0-19-generic N/A
 linux-firmware 1.127
RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
SourcePackage: linux
UpgradeStatus: Upgraded to trusty on 2014-04-07 (0 days ago)

CVE References

Ryan Finnie (fo0bar) wrote :

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

apport-collect 1303657

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.

Changed in linux (Ubuntu):
status: New → Incomplete
tags: added: saucy

Looks like the lp helper script got confused; logs were already attached from apport-bug. Overriding.

BTW, I removed u-boot from the situation and tried booting 3.13.0-23-generic directly from qemu-system-arm, same result. I have not yet been able to get 3.13.0-23-generic to boot.

summary: - Cannot boot 3.13.0-23-generic from u-boot on qemu-system-arm
+ Cannot boot 3.13.0-23-generic on qemu-system-arm
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
tags: removed: saucy
Joseph Salisbury (jsalisbury) wrote :

Can you follow the "Boot options" instructions on the following wiki to enable additional output on boot:

As mentioned on the wiki, it would be great if you can attach a log file which may have captured any messages you see. If you are unable to capture a log file, a digital photo will work just as well. As a last resort you can even copy messages down by hand.

Changed in linux (Ubuntu):
importance: Undecided → High
Joseph Salisbury (jsalisbury) wrote :

Also, will the machine boot if you select the 3.13.0-22 kernel from GRUB?

tags: added: kernel-key
Ryan Finnie (fo0bar) wrote :

The only option on of relevance to booting an ARM kernel in QEMU is the "debug" flag, which doesn't change anything. The u-boot output is in the original report; when booting through u-boot, it CPU spins after "Starting kernel ...". When booting the kernel directly from qemu-system-arm, there is literally no output.

I don't have access to 3.13.0-22, it was a d-r-u from saucy to trusty this weekend. I was referring to the difference between the saucy kernel line (3.11) and the trusty kernel line (3.13). I'm compiling an armhf kernel from to test vanilla, but this is going to take a very long time.

summary: - Cannot boot 3.13.0-23-generic on qemu-system-arm
+ Cannot boot trusty kernel on qemu-system-arm
Ryan Finnie (fo0bar) wrote :

FWIW, I was not able to compile the armhf package from

  CC [M] drivers/gpu/drm/msm/msm_drv.o
  CC [M] drivers/gpu/drm/msm/msm_fb.o
  CC [M] drivers/gpu/drm/msm/msm_gem.o
  CC [M] drivers/gpu/drm/msm/msm_gem_prime.o
  CC [M] drivers/gpu/drm/msm/msm_gem_submit.o
  CC [M] drivers/gpu/drm/msm/msm_gpu.o
  CC [M] drivers/gpu/drm/msm/msm_iommu.o
  CC [M] drivers/gpu/drm/msm/msm_ringbuffer.o
  CC [M] drivers/gpu/drm/msm/msm_fbdev.o
  LD [M] drivers/gpu/drm/msm/msm.o
drivers/gpu/drm/msm/hdmi/hdmi.o: In function `.LANCHOR2':
hdmi.c:(.rodata+0x10): multiple definition of `__mod_of_device_table'
drivers/gpu/drm/msm/adreno/a3xx_gpu.o:a3xx_gpu.c:(.rodata+0x4e8): first defined here
drivers/gpu/drm/msm/msm_drv.o: In function `.LANCHOR0':
msm_drv.c:(.rodata+0x20c): multiple definition of `__mod_of_device_table'
drivers/gpu/drm/msm/adreno/a3xx_gpu.o:a3xx_gpu.c:(.rodata+0x4e8): first defined here
make[6]: *** [drivers/gpu/drm/msm/msm.o] Error 1
make[5]: *** [drivers/gpu/drm/msm] Error 2
make[4]: *** [drivers/gpu/drm] Error 2
make[3]: *** [drivers/gpu] Error 2
make[2]: *** [drivers] Error 2
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory `/home/ryan/v3.14-trusty/linux-3.14'
make: *** [/home/ryan/v3.14-trusty/linux-3.14/debian/stamps/stamp-build-generic] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
debuild: fatal error at line 1364:
dpkg-buildpackage -rfakeroot -D -us -uc failed

real 447m6.844s
user 385m56.960s
sys 36m20.700s

Paolo Pisati (p-pisati) on 2014-04-08
Changed in linux (Ubuntu):
assignee: nobody → Paolo Pisati (p-pisati)

Recent distros can silently hang due to insufficient RAM while decompressing
kernel image. Did you give enough RAM?

tags: removed: kernel-key
Paolo Pisati (p-pisati) wrote :

can you try this kernel?

moreover, there's a dtb for this "board" at: /lib/firmware/3.13.0-24-generic/device-tree/vexpress-v2p-ca9.dtb

Paolo Pisati (p-pisati) wrote :

i added the dtb to the archive, and disable the "console via JTAG" that already gave us problem in the past - that should make it.

Paolo Pisati (p-pisati) wrote :
description: updated
Ryan Finnie (fo0bar) wrote :

linux-image-3.13.0-24-generic_3.13.0-24.46~hvcdcc_armhf.deb verified as working, both directly and via u-boot, thank you.

And thanks for including the DTB in the package now. I was using vexpress-v2p-ca9.dtb, but IIRC I compiled it from vanilla sometime last year.

Paolo Pisati (p-pisati) on 2014-04-08
Changed in linux (Ubuntu):
status: Confirmed → In Progress
Tim Gardner (timg-tpi) on 2014-04-09
Changed in linux (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: patch
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux - 3.13.0-24.46

linux (3.13.0-24.46) trusty; urgency=low

  [ Andy Whitcroft ]

  * [Config] d-i -- add nvme devices to block-modules udeb
    - LP: #1303710

  [ Paolo Pisati ]

  * [Config] build vexpress a9 dtb
    - LP: #1303657
  * [Config] disable HVC_DCC
    - LP: #1303657

  [ Tim Gardner ]

  * Release Tracking Bug
    - LP: #1305158
  * rebase to v3.13.9
    - LP: #1296591

  [ Upstream Kernel Changes ]

  * HID: Bluetooth: hidp: make sure input buffers are big enough
    - LP: #1252874
  * ACPI / video: Add systems that should favour native backlight interface
    - LP: #1303419
  * rds: prevent dereference of a NULL device in rds_iw_laddr_check
    - LP: #1302222
    - CVE-2014-2678
  * x86/efi: Fix 32-bit fallout
    - LP: #1301590
  * drm/nouveau/devinit: tidy up the subdev class definition
    - LP: #1158689
  * drm/nouveau/device: provide a way for devinit to mark engines as
    - LP: #1158689
  * drm/nv50-/devinit: prevent use of engines marked as disabled by
    - LP: #1158689
  * rtlwifi: btcoexist: Add new mini driver
    - LP: #1296591
  * rtlwifi: Prepare existing drivers for new driver
    - LP: #1296591
  * rtlwifi: add MSI interrupts mode support
    - LP: #1296591
  * rtlwifi: rtl8188ee: enable MSI interrupts mode
    - LP: #1296591

  [ Upstream Kernel Changes ]

  * rebase to v3.13.9
 -- Tim Gardner <email address hidden> Fri, 04 Apr 2014 09:26:27 -0400

Changed in linux (Ubuntu Trusty):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers