8

Sorry for bothering folks:

I tried a lot of instructions to get a Raspbian image running on QEMU (2.0.0 via homebrew) on OS X (10.9.3).

I downloaded several versions of Raspbian but always the first boot fails.

qemu-system-arm -kernel ../kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -hda 2013-12-20-wheezy-raspbian.img 

brings the error message

Unable to determine your tty name.

and starting into a shell

qemu-system-arm -kernel ../kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 init=/bin/sh rw" -hda 2013-12-20-wheezy-raspbian.img

makes the system wait indefinitely before the login prompt appears.

I know that I have to edit

/etc/ld.so.preload

but for this a first boot would be helpful.

Any ideas, hints, facepalms?

with regards yogi viegelinsch

2

Try installing qemu version 1.7.1 (the version prior to 2.0.0).

I had very similar problems with qemu 2.0.0 (installed via macports in my case), and switching back to the prior version made everything work.

I do not use homebrew, but this response at Stackoverflow has detailed instructions to revert to an earlier version of any package using Homebrew.

3

When booting first time you should use bash as init application and change /etc/ld.so.preload. Please note -append parameter:

qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw init=/bin/bash console=ttyAMA0,115200" -hda 2014-12-24-wheezy-raspbian.img

Kudos for this hint should go to xecdesign for tutorial that explain how to boot versatilepb with arm1176.

  • that didnt work for me – Piotr Kula Feb 20 '15 at 9:04
  • Did you change ld.so.preload according to instructions from tutorial ? You should disable libcofi_rpi.so usage, because of replacement of memcpy and memset. You can find more information about this problem here. – Piotr Król Feb 21 '15 at 18:49
2

I had similar issues and I finally got this working last night, on OS X 10.8.5 with QEMU v2.2.0, after working on/off for two weeks.

Preamble

I was prompted by the question, Can I program for Arduino without having a real board?, to try to use a real emulator, such as QEMU, as suggested by zmo, in a comment to Anindo Ghosh's answer.

I thought that I would relate my experience here.

I set this up on a MacBook Pro, running 10.8. (Mountain Lion). I quickly found the link Installing QEMU on OS X1. Yes, I know is seems to be related to the Pi, but bear with me. After a quick browse, it was clear what was required.

First step was to set up the Mac with the correct environment. This required, in the following order:

  1. Xcode;
  2. Xcode command line tools;
  3. homebrew;
  4. a compiler, and finally;
  5. qemu itself

Details

Going into each step in detail

  1. Xcode - I used 5.1, from the Apple site [link?]
  2. The command line tools were downloaded from within Xcode, from Tools -> Downloads.
  3. Homebrew was installed in the terminal, using the following command

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

There was a failed download at first, due to the Thai telephone network dropping, which required a messy cleanup. But running the command again worked.

  1. Then brew doctor, at first complaining that I had a case sensitive file system, threw up a requirement for Quartz 2.7.7, I had 2.7.4 installed evidently. This I downloaded, rebooted, ran brew doctor again. It was still complaining, but this time because I had Quartz 2.6.3 installed! I gave up at that point and moved on.
  2. Selecting the QEMU build required these two commands

cd /usr/local/ # Or wherever you installed Homebrew.

git checkout 2b7b4b3 Library/Formula/qemu.rb

  1. Then installing gcc, which I left to run its course.

brew install https://raw.github.com/Homebrew/homebrew-dupes/master/apple-gcc42.rb

  1. Then install pkg-config

brew install pkg-config

  1. And finally (!) QEMU

brew install qemu --env=std --cc=gcc-4.2

Then unfortunately that page's instructions failed me as the links to the zImage and rootfs files on dropbox had been killed, due to over subscription, so I had to find another method. I decided to sleep on it, as I was getting irritated by now.

Then following morning, after a not so refreshing sleep, I found the link, QEMU – Emulating Raspberry Pi the easy way (Linux or Windows!)1 which, pretty much enabled me to carry on from where I left off.

  1. Downloading the PI images from the Raspberry PI downloads page
  2. Downloading the linux kernel (which required brew install wget beforehand):

wget http://xecdesign.com/downloads/linux-qemu/kernel-qemu

  1. Verifying qemu's available emulation modes:

qemu-system-arm -cpu ?

  1. First boot

qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw init=/bin/bash" -hda 2013-09-25-wheezy-raspbian.img

This resulted in a cycle of SCSI errors,

ABORT, DEVICE RESET, BUS RESET, HOST RESET, sym0: SCSI BUS has been reset, HOST RESET, Device offlined

and so on, cycling through ever increasing SCSI device IDs, n, (scsi 0:0:*n*:0). n = {0, 1, 2... 6, 8, 9... 15} 7 was skipped as it is presumably the host controller.

Screenshot of QEMU window first run #1

It would cycle up to SCSI ID=14,

Screenshot of QEMU window first run #2

with the console in the QEMU window eventually crashing, at SCSI ID=15,

Screenshot of QEMU window first run #3

leaving the following error in the terminal from which it was run.

snowserv:local user$ qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw init=/bin/bash" -hda ~/Documents/PI\:Arduino/Lapdock/Raspberry\ PI\ Disk\ Images/2015-02-16-raspbian-wheezy.img
Uncompressing Linux... done, booting the kernel.
pflash_write: Unimplemented flash cmd sequence (offset 00000000, wcycle 0x0 cmd 0x0 value 0xf000f0)
pflash_write: Unimplemented flash cmd sequence (offset 00000000, wcycle 0x0 cmd 0x0 value 0xf0)
snowserv:local user$ 

I tried the same command prefixed with sudo, but the same issue occurred.

I thought that the issue was the root=/dev/sda2. Copying the Raspbian image locally didn't help (it had been on a separate partition). Looking at the comments on the web page, a number of people were getting the same SCSI errors.

It appeared to be an issue with the version of QEMU. I was using 1.1.50

qemu-system-arm --version

After some to-ing and fro-ing, I found the newer version, 2.2.0

I checked out fce79940eb

git checkout fce79940eb Library/Formula/qemu.rb

Unlinked the older version

brew unlink qemu

Install new checked out version

brew install qemu --env=std --cc=gcc-4.2

And running the first boot command

qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw init=/bin/bash" -hda 2013-09-25-wheezy-raspbian.img

this time resulted in the expected command prompt.

I ran through the suggested edits of /etc/ld.so.preload and /etc/udev/rules.d/90-qemu.rules, without any issues arising.

However, I was unable to halt, shutdown or reboot the Pi. The errors received were

init: /run/initctl: No such file or directory

Screen shot first real boot

I ended up doing a hard reboot, by just quitting the QEMU app.

In the terminal were a lot of

coreaudio: Could not lock voice for audioDeviceIOProc
Reason: Invalid argument

errors logged. Probably from failed beeps arising from failed shutdowns.

I repeated the first boot, as a google2 suggested that the init issue could be solved simply by just a hard boot, but I still had the start up errors, and the halt errors.

Screenshot of halt errors

There was a "better" way of shutting down though, as I was given the tip (see below) that

reboot -f 

worked.

In an attempt to lose the init errors, after some more googling3, I ran the following commands:

mkfifo /dev/initctl

but, predictably, it was not persistent, and didn't fix shutdown.

mkfifo /run/initctl

which was persistent, but didn't fix the shutdown.

I encountered henje on Super User having the same issue. From shutdown: /run/initctl: No such file or directory

Thx for the reboot -f. Good tip. After further googling, a hard reboot is supposed to fix the issue, but it hasn't. I have also run mkfifo /run/initctl which stops the No such file or directory error, but still doesn't shut the system down. I now get init: timeout opening/writing control channel /run/initctl. I have compared the /run/initctl just created, with the one on my working RPi, and they look identical: prw------- 1 root root 0 Jan 1 1970 /run/initctl.

I carried on regardless, and ran the proper boot command, the same as the first boot, minus the init=/bin/bash

qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -hda 2013-09-25-wheezy-raspbian.img

It booted, apparently without issue, into the raspi-config screen. I changed the hostname and pi user's password. Then hit Finish and agreed to the restart, the QEMU just exited, appearing to die, the window vanished.

I ran the same proper boot command again

qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -hda 2013-09-25-wheezy-raspbian.img

command again. It booted to normal text console login. Logged in, ran startx, X can up. Ran sudo shutdown-h now. System shutdown without mishap, leaving System halted message. Although the CPU was left running at 100%, and the window did not close. I had to close it manually.

Ran same proper boot command again, it booted OK. It does run fsck each boot, so I am not sure if that is indicative of the halt not working correctly, or whether Raspbian does that anyway on each boot. However, upon sudo halt, I see the message

[ ok ] Unmounting local file systems...done.

so I assume that it is OK and normal.

I hope that this (rambling) tale, helps someone else.


1 There is way too much info to attempt to summarise, in case of link death.

2 According to can't reboot debian and systemd-sysv, sysvinit: problems rebooting when switching between systemd-sysv and sysvinit

3 According to I got a error flag "init: /dev/initctl: no such file"

0

This works for me on MacOS Mojave,

Create a file called qemu_script.sh and copy-paste the code below

nano qemu_script.sh

give execution perms and execute,

$ chmod +x qemu_script.sh
$ ./qemu_script.sh

Code:

#!/bin/sh

brew install qemu

export QEMU=$(which qemu-system-arm)
export TMP_DIR=~/tmp/qemu-rpi
export RPI_KERNEL=${TMP_DIR}/kernel-qemu-4.14.79-stretch
export RPI_FS=${TMP_DIR}/2018-11-13-raspbian-stretch-lite.img
export PTB_FILE=${TMP_DIR}/versatile-pb.dtb
export IMAGE_FILE=2018-11-13-raspbian-stretch-lite.zip
export IMAGE=http://downloads.raspberrypi.org/raspbian_lite/images/raspbian_lite-2018-11-15/${IMAGE_FILE}

mkdir -p $TMP_DIR; cd $TMP_DIR

wget https://github.com/dhruvvyas90/qemu-rpi-kernel/blob/master/kernel-qemu-4.14.79-stretch?raw=true \
        -O ${RPI_KERNEL}

wget https://github.com/dhruvvyas90/qemu-rpi-kernel/raw/master/versatile-pb.dtb \
        -O ${PTB_FILE}

wget $IMAGE
unzip $IMAGE_FILE


$QEMU -kernel ${RPI_KERNEL} \
    -cpu arm1176 -m 256 -M versatilepb \
    -dtb ${PTB_FILE} -no-reboot \
    -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" \
    -drive "file=${RPI_FS},index=0,media=disk,format=raw" \
    -net user,hostfwd=tcp::5022-:22 -net nic \

You should get: enter image description here

HTH someone

  • What's that? Can you explain please? – Ingo Feb 11 '19 at 20:41
  • Hi, yup, let me edit to the post. – user9869932 Feb 11 '19 at 20:46

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.