I've downloaded the Raspbian image on this page. I'm trying to compile a kernel that can be used to boot the image within qemu.

I downloaded the Linux kernel source from kernel.org and ran:

make versatile_defconfig
make menuconfig

I then added the following features to the kernel:

  • PCI support (CONFIG_PCI)
  • SCSI Device Support (CONFIG_SCSI)
  • SCSI Disk Support (CONFIG_BLK_DEV_SD)
  • SYM53C8XX Version 2 SCSI Support (CONFIG_SCSI_SYM53C8XX_2)
  • The Extended 3 (ext3) filesystem (CONFIG_EXT3_FS)
  • The Extended 4 (ext4) filesystem (CONFIG_EXT4_FS)

I also loop mounted the disk image and:

  • commented out /etc/ld.so.preload
  • adjusted /etc/fstab to use /dev/sda1 and /dev/sda2

I then unmounted the image and attempted to start the machine with:

qemu-system-arm \
    -M versatilepb \
    -m 256 \
    -kernel linux-4.3/arch/arm/boot/zImage \
    -hda 2015-09-24-raspbian-jessie.img \
    -serial stdio \
    -append "root=/dev/sda2 rootfstype=ext4 rw console=ttyAMA0"

The kernel was able to mount the filesystem but it immediately ran into some trouble:

Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004

CPU: 0 PID: 1 Comm: init Not tainted 4.3.0 #1
Hardware name: ARM-Versatile PB
[<c001b5c0>] (unwind_backtrace) from [<c0017e18>] (show_stack+0x10/0x14)
[<c0017e18>] (show_stack) from [<c0069860>] (panic+0x84/0x1ec)
[<c0069860>] (panic) from [<c0025b98>] (do_exit+0x81c/0x850)
[<c0025b98>] (do_exit) from [<c0025c5c>] (do_group_exit+0x3c/0xb8)
[<c0025c5c>] (do_group_exit) from [<c002dfcc>] (get_signal+0x14c/0x59c)
[<c002dfcc>] (get_signal) from [<c001bf28>] (do_signal+0x84/0x3a0)
[<c001bf28>] (do_signal) from [<c0017a94>] (do_work_pending+0xb8/0xc8)
[<c0017a94>] (do_work_pending) from [<c0014f30>] (slow_work_pending+0xc/0x20)
---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004

At first, I wondered if this wasn't related to SELinux. I tried booting the kernel with:

selinux=0 enforcing=0

...but it made absolutely no difference.

What am I doing wrong? And what does this error mean?


I have also tried the following, with no luck:

  • I tried compiling with and without CONFIG_VFP enabled
  • Applying this patch and enabling CPU_V6, CONFIG_MMC_BCM2835, & CONFIG_MMC_BCM2835_DMA
  • Using the gcc-linaro-arm-linux-gnueabihf-raspbian toolchain
  • Compiling a simple C program with the toolchain and then passing its path to the kernel via init= works - leading me to believe there's a discrepancy between binary formats

    • file <sample program>:

      ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 2.6.26, BuildID[sha1]=e5ec8884499c51b248df60aedddfc9acf72cdbd4, not stripped
    • file <file from the image>:

      ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=3e92423821f3325f8cb0ec5d918a7a1c76bbd72c, stripped`
    • diff of ELF header

I compiled this simple C program with the toolchain:

<path>/arm-linux-gnueabihf-gcc --static simple.c -o simple

...and copied it to /root in the image, changing the init= boot parameter to /root/simple. This gives me the following when booting:

Starting bash...
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004

It seems to be choking on the execv() call.

  • 3
    I would say this is an issue regarding hard floating point support. Do you have CONFIG_VFP=y? Nov 17, 2015 at 8:36
  • @AlexandreBelloni cat .config | grep CONFIG_VFP yields CONFIG_VFP=y - seems like it is enabled. Nov 17, 2015 at 18:38
  • @AlexandreBelloni I've tried the kernel with and without CONFIG_VFP and it makes no difference. Nov 17, 2015 at 21:04
  • 1
    I think Alexandre is on the right track, but VFP isn't the problematic setting. versatilepb is an ARM926 CPU, which is older than the RPi's ARM1176, so Raspbian binaries may be using some other feature that isn't being emulated. From unixmen.com/emulating-raspbian-using-qemu, does -cpu arm1176 help? Nov 18, 2015 at 0:04
  • 1
    Hmmm. Maybe try an armel toolchain? (For the actual program that keeps running, not just for the relay stub. You could use busybox — grab the busybox-static binary from debian armel.) Nov 18, 2015 at 12:22

4 Answers 4


I've also tried booting ARM images with QEMU with no reliable success. I am sorry to say that you will have to use real hardware to work with a ARM OS, or wait patiently for developers to make a more reliable emulator for ARM.

Its Dec 2018, and still there are still issues with qemu-system-arm.

I was able to boot Raspbian Jessie on a QEMU emulator using a freshly installed Ubuntu 18 Bionic, however it was not stable for my work so I had to leave it for real hardware. It would freeze up frequently.

qemu-system-arm did not work on my OS, so I used Virtualbox to install Ubuntu Bionic and inside Bionic I installed Raspbian with QEMU.

I followed this tutorial: https://azeria-labs.com/emulate-raspberry-pi-with-qemu/

Good luck


I know it's a somewhat aged question, but since there are still no good answers for testing Raspberry Pi images with QEMU, allow me to contribute a partial answer.

I wanted to use the Ubuntu 16.04 raspi3 image with QEMU. Downloaded it, extracted it, mounted the boot partition, got the vmlinuz file and the initrd file, and ... qemu-system-arm -M blabla -cpu ... -kernel ... doesn't work. Black screen.

Then using a kernel-qemu-4.4.34-jessie from here with the xenial image/rootfs led to the same "init killed" problem you have.

But since I'm using a known good kernel, and since your simple statically linked C program works, it's likely the problem only surfaces when one uses the dynamic linker. (And the linker is not particularly sensitive to kernels, because the ld-2.24 from the latest debian9 (stretch) based raspbian works fine on a 4.4 debian8 (jessie) based kernel.)

Even after copying the files that do work on/with the "jessie" image into the ubuntu xenial image I only got a weird "calling preinit: KE" error.

Oh, and anyone looking at compiling a kernel for a Raspberry Pi, should check this site, which directly references the "official" docs/howto.


Did you use the right cross-compiler?

In my case, I followed the link below and I was getting the same error with exit code 0x00000004, when I used arm-linux-gnueabihf- (i.e., hard-float) gcc compiler.


When I recompiled everything with arm-linux-gnueabi-, the kernel booted successfully. Please check if this resolves your problem.

  • 1
    The OP mentions a very similar situation: "Using the gcc-linaro-arm-linux-gnueabihf-raspbian toolchain ... <path>/arm-linux-gnueabihf-gcc --static simple.c -o simple" -- is your answer distinct from that?
    – Jeff Schaller
    Jul 14, 2020 at 13:07

The linux kernel does not run init anymore. Instead, it runs systemd which is like init but a bit more advanced features and extra multitasking capabilities, although against unix philosophy systemd is so useful.

  • not sure if this is know to the be how
    – printf
    Apr 7, 2019 at 22:14
  • This is not correct. Many embedded Linux systems run the latest kernel without the use of Systemd, oftentimes using a slimmer init system, such as the one provided by BusyBox.
    – Rick
    Jan 16, 2021 at 23:20
  • Counter example: Devuan Linux.
    – Kusalananda
    Jan 17, 2021 at 20:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.