QEmu-ARM-Ubuntu: CPU1: failed to boot: -38

Question

How to fix "CPU1: failed to boot: -38" issue in QEmu?

I am hosting Ubuntu 16.04 on Virtual Box from Windows 10. Inside that Ubuntu 16.04, there is QEmu emulating ARM processor, running Ubuntu Trusty (14.04). When the ARM-Ubuntu boots, it prints to console "CPU1: failed to boot: -38" and something similar multiple times. Is it a matter of some command-line switch to QEmu, or configuration files? Or is it a bug or lack of support of QEmu ARM emulation inside another VM?

Effectively the ARM-Ubuntu uses only 1 core out of 6 available in the physical machine and the middle virtual machine.

To setup ARM-Linux on QEmu I mostly followed these steps. I had to do something differently, e.g. because Ubuntu Sauce is no more available. Specifically the steps I did are:

# 1) setup the rootfs

sudo apt-get install qemu-user-static qemu-system-arm

mkdir vexpress
cd vexpress
mkdir qemu-img

# Create 8-GB image
dd if=/dev/zero of=./vexpress-8G.img bs=8M count=1024
sudo losetup -f ./vexpress-8G.img
sudo mkfs.ext4 /dev/loop0
sudo mount /dev/loop0 qemu-img

# Bootstrap Ubuntu Trusty armhf rootfs in the qemu-img directory
# For Ubuntu versions later than Trusty some commands fail
# For Ubuntu versions before Saucy there is no port to ARM
# Ubuntu Saucy is not supported anymore
sudo qemu-debootstrap --arch=armhf trusty qemu-img
sudo cp `which qemu-arm-static` qemu-img/usr/bin/

# setup serial console, apt repositories and network
sudo chroot qemu-img
sed 's/tty1/ttyAMA0/g' /etc/init/tty1.conf > /etc/init/ttyAMA0.conf
echo "deb  http://ports.ubuntu.com trusty main restricted multiverse universe" > /etc/apt/sources.list
apt-get update
echo -e "\nauto eth0\niface eth0 inet dhcp" >> /etc/network/interfaces

# root password
passwd


# 2) pick and install a kernel

# Fix locale problems http://askubuntu.com/questions/162391/how-do-i-fix-my-locale-issue
locale
sudo locale-gen "be_BY.UTF-8"
sudo locale-gen "en_US"
sudo locale-gen "en_US.UTF-8"
sudo dpkg-reconfigure locales

apt-get install wget ca-certificates
wget https://launchpad.net/ubuntu/+archive/primary/+files/linux-image-3.13.0-24-generic-lpae_3.13.0-24.46_armhf.deb
dpkg -i linux-image-3.13.0-24-generic-lpae_3.13.0-24.46_armhf.deb

# So far I'm getting the following warnings:
#   Warning: cannot read table of mounted file systems: No such file or directory
#   warning: failed to read mtab

# !!! press CTRL+D to exit the chroot
^D


# 3) Boot it up


# copy kernel, initrd and dtb files
sudo cp qemu-img/boot/vmlinuz-3.13.0-24-generic-lpae .
sudo cp qemu-img/boot/initrd.img-3.13.0-24-generic-lpae .
sudo cp qemu-img/lib/firmware/3.13.0-24-generic-lpae/device-tree/vexpress-v2p-ca15-tc1.dtb .

# umount the rootfs img
sudo umount qemu-img

sudo chmod 777 vmlinuz-3.13.0-24-generic-lpae
sudo chmod 777 initrd.img-3.13.0-24-generic-lpae
sudo chmod 777 vexpress-v2p-ca15-tc1.dtb
sudo chmod 777 vexpress-8G.img

# http://unix.stackexchange.com/questions/167165/how-to-pass-ctrl-c-in-qemu
# Allow Ctrl+C and Ctrl+Z on guest, changing them on host to Ctrl+] and Ctrl+[
stty intr ^]
stty susp ^j

qemu-system-arm --drive format=raw,if=sd,file=vexpress-8G.img -kernel vmlinuz-3.13.0-24-generic-lpae -initrd initrd.img-3.13.0-24-generic-lpae -M vexpress-a15 -serial stdio -m 2048 -append 'root=/dev/mmcblk0 rw mem=2048M raid=noautodetect rootwait console=ttyAMA0,38400n8 devtmpfs.mount=0' -dtb ./vexpress-v2p-ca15-tc1.dtb
# Still getting error: "CPU1: failed to boot: -38"

Answer 1

The specific machine you're emulating (vexpress-v2p-ca15-tc1) is a dual-core one, so the kernel will try to bring up the secondary CPU it sees described in the DTB you're passing. However, since QEMU is only emulating a single CPU, the secondary naturally fails to come online on account of not existing.

The message in and of itself is perfectly harmless, but if you're allergic to error messages, just add maxcpus=1 to the kernel command line to prevent Linux even trying to bring up any secondary cores. If you really want to emulate both cores, pass the -smp 2 option to QEMU, although it may well result in more emulation overhead and be slower overall.