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

Greenonline
  • 2,969
  • 5
  • 27
  • 38
Hendrik Eggers
  • 103
  • 1
  • 6

4 Answers4

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.

Piotr Król
  • 346
  • 3
  • 14
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.

Community
  • 1
Anupam
  • 136
  • 2
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"

Community
  • 1
Greenonline
  • 2,969
  • 5
  • 27
  • 38
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

user9869932
  • 151
  • 2
  • 5