Why can't the kernel run init?

6,998

Solution 1

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

Solution 2

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.

Share:
6,998

Related videos on Youtube

dbush
Author by

dbush

Updated on September 18, 2022

Comments

  • dbush
    dbush over 1 year

    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?

    Updates

    I have also tried the following, with no luck:

    • I tried compiling with and without CONFIG_VFP enabled
    • I added CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT
    • 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.

    • Connorelsea
      Connorelsea over 8 years
      I would say this is an issue regarding hard floating point support. Do you have CONFIG_VFP=y?
    • dbush
      dbush over 8 years
      @AlexandreBelloni I've tried the kernel with and without CONFIG_VFP and it makes no difference.
    • Gilles 'SO- stop being evil'
      Gilles 'SO- stop being evil' over 8 years
      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?
    • dbush
      dbush over 8 years
      @Gilles as a parameter to qemu? No, it doesn't make a difference, unfortunately.
    • Gilles 'SO- stop being evil'
      Gilles 'SO- stop being evil' over 8 years
      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.)
  • printf
    printf about 5 years
    not sure if this is know to the be how
  • Jeff Schaller
    Jeff Schaller almost 4 years
    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?
  • Rick
    Rick over 3 years
    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.
  • Kusalananda
    Kusalananda over 3 years
    Counter example: Devuan Linux.