I want to simulate an arm environment for arm ubuntu 20.04 LTS.
The host is also ubuntu 20.04 LTS but not arm.
First I created an image like this:
qemu-img create -f qcow2 ubuntu.img 3G
then I ran this command:
sudo qemu-system-aarch64 -m 2048 -cpu cortex-a57 -M virt -nographic \
-bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd -drive \
file=ubuntu.img,if=none,id=hd0 -device virtio-blk-device,drive=hd0 \
-cdrom ubuntu.iso -boot d -netdev user,id=net0,hostfwd=tcp::5555-:22 \
-device virtio-net-device,netdev=net0
I installed the ubuntu on the qemu successfully and everything is working untill I reboot the guest or close the qemu.
After I close the qemu I tried to use the same command to boot the ubuntu without reinstalling it. But this doesn't worked and reinstall the ubuntu again.
I am stack about this problem for a while, and I would love to get some help.
I tried to remove the -cdrom ubuntu.iso but that boot the UEFI because the boot loader didn't find any OS.
Also I tried this command:
sudo qemu-system-aarch64 -m 1024 -cpu cortex-a57 -M virt -nographic \
-drive file=flash0.img,format=raw,if=pflash \
-drive file=flash1.img,format=raw,if=pflash \
-drive file=user-data.img,format=raw \
-drive if=none,file=ubuntu.img,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0,mac=$randmac \
-netdev type=tap,id=net0
That I took from the ubuntu website and again the boot loader didn't find any OS.
Thanks in advance!
Related
Bash script
#!/bin/sh
WINIMG=~/vm/Win10_21H2_English_x64.iso
VIRTIMG=~/vm/virtio-win-0.1.217.iso
qemu-system-x86_64 --enable-kvm -drive driver=raw,file=~/vm/win10.img,if=virtio -m 6144 \
-net nic,model=virtio -net user -cdrom ${WINIMG} \
-drive file=${VIRTIMG},index=3,media=cdrom \
-rtc base=localtime,clock=host -smp cores=4,threads=8 \
-usb -device usb-tablet \
-net user,smb=$HOME
Output of run
qemu-system-x86_64: -drive driver=raw,file=~/vm/win10.img,if=virtio: Could not open '~/vm/win10.img': No such file or directory
Not sure why it responds as "No such file or directory", as i have checked all three files are there as seen below
loo#loo-System-Product-Name:~/Desktop/lunaLand/vm$ ls
virtio-win-0.1.217.iso vm.sh Win10_21H2_English_x64.iso win10.img
The following script should resolve the "No such file or directory" error:
#!/bin/sh
WINIMG=~/Desktop/lunaLand/vm/Win10_21H2_English_x64.iso
VIRTIMG=~/Desktop/lunaLand/vm/virtio-win-0.1.217.iso
qemu-system-x86_64 --enable-kvm -drive driver=raw,file=~/Desktop/lunaLand/vm/win10.img,if=virtio -m 6144 \
-net nic,model=virtio -net user -cdrom ${WINIMG} \
-drive file=${VIRTIMG},index=3,media=cdrom \
-rtc base=localtime,clock=host -smp cores=4,threads=8 \
-usb -device usb-tablet \
-net user,smb=$HOME
The files are located on the desktop in the lunaland/vm folder and not in a vm folder in user loo's home directory.
I am trying to use an external disk instead of a .img file in qemu-system-ppc. I am using the following code:
cd "$(dirname "$0")"
./qemu-system-ppc -L pc-bios -boot d -M mac99 -m 512 \
-prom-env 'auto-boot?=true' -prom-env 'boot-args=-v' -prom-env 'vga-ndrv?=true' \
-drive file=MacOS9.2.2.iso,format=raw,media=cdrom \
-drive file=/dev/disk3s2,format=raw,if=virtio \
-netdev user,id=network01 -device sungem,netdev=network01 \
-device VGA,edid=on \
When I run this code I get the following output from the terminal:
hamishmoore#Hamishs-Mini ~ % /Applications/QEMU\ Mac\ OS\ 9.2.2/qemu.command ; exit;
qemu-system-ppc: -drive file=/dev/disk3s2,format=raw,if=virtio: If device /dev/disk3s2 is mounted on the desktop, unmount it first before using it in QEMU
qemu-system-ppc: -drive file=/dev/disk3s2,format=raw,if=virtio: Command to unmount device: diskutil unmountDisk /dev/disk3s2
qemu-system-ppc: -drive file=/dev/disk3s2,format=raw,if=virtio: Command to mount device: diskutil mountDisk /dev/disk3s2
qemu-system-ppc: -drive file=/dev/disk3s2,format=raw,if=virtio: Could not open '/dev/disk3s2': Permission denied
[Process completed]
The disk has been unmounted from the desktop. And I've tried formatting the disk a few different ways. I am running macOS Catalina.
Help Appreciated.
QEMU will print the suggestion about unmounting from the desktop for pretty much any error attempting to open a device as an image file. The important line here is the last one, which tells you the specific error:
qemu-system-ppc: -drive file=/dev/disk3s2,format=raw,if=virtio: Could not open '/dev/disk3s2': Permission denied
"Permission denied" usually means that the user you're running QEMU as does not have write access to the /dev/disk3s2 device; check the permissions/ownership on it.
Attempting to boot from a Live Linux Mint 18.4 (x64) ISO using QEMU under macOS Catalina (with patches to use hvf as hypervisor in place of kvm).
I am able to get as far as the boot menu, but attempting to boot into the installer leaves me with a blinking cursor.
Booting in verbose mode, I see it hangs at:
clocksource: switched to clocksource tsc
I have also attempted to boot a CentOS and Kali iso. The CentOS VM exits abruptly when booted in verbose mode after a flash of text too fast for me to read, whereas the Kali iso merely shows a black screen, without even a blinking cursor.
I attempted to also boot with the notsc kernel flag enabled, this however merely caused the Mint ISO to hang at
PCI Interrupt Link [LNKB] enabled at IRQ 10
instead, and made no apparent difference in the case of the Kali and CentOS isos.
I'm unsure if this is specifically an hvf issue, but any suggestions are welcome.
These are the command parameters I am launching my VM with.
qemu-system-x86_64 \
-m 4096 \
-show-cursor \
-vga virtio \
-usb \
--device usb-tablet \
-enable-kvm \
-cdrom ./linuxmint.iso \
-drive file=./mint.qcow2,if=virtio \
-accel hvf \
-cpu max
I have had similar issues when using the hvf accelerator with CPU host passthrough.
When I try to boot the Ubuntu 20.04.1 desktop installer ISO, I get a kernel panic immediately after the boot loader's splash screen.
Using QEMU 5.1 from HomeBrew, I have had success emulating the CPU by using the default qemu64 CPU model.
To explicitly use the emulated CPU, your command-line would look as follows:
qemu-system-x86_64 \
-m 4096 \
-show-cursor \
-vga virtio \
-usb \
--device usb-tablet \
-enable-kvm \
-cdrom ./linuxmint.iso \
-drive file=./mint.qcow2,if=virtio \
-accel hvf \
-cpu qemu64
Update
A response to my bug report solved this for me.
Ubuntu 20.04 was crashing because it attempted to use the RDTSCP feature which is supported by the CPU.
The problem is that Hyperkit.Framework fails to pass this feature through, leading to the crash.
If your crash is due to RDTSCP, then the you should be able to fix this by disabling this option.
Disabling this specific feature can be done by providing the CPU type, host, followed immediately by ,-rdtscp, like so:
qemu-system-x86_64 \
-m 4096 \
-show-cursor \
-vga virtio \
-usb \
--device usb-tablet \
-enable-kvm \
-cdrom ./linuxmint.iso \
-drive file=./mint.qcow2,if=virtio \
-accel hvf \
-cpu host,-rdtscp
I am running the FreeBSD image using QEMU.
When I start it with QEMU it works smoothly for a few seconds, but then the FreeBSD system starts being very slow to respond to my keystrokes. Sometimes this happens a few seconds after the FreeBSD has loaded and I have logged in the system using as a root and sometimes it is already slow when it shows the user/password lines.
What is interesting though is that when I open a second terminal session and connect to the slowly running FreeBSD via SSH (I have set up the sshd in the FreeBSD), the connection seems to work without any issues. Also if I do a verbose command such as find / in the QEMU's terminal session it stops being slow for a short while after I stop the command, and then it goes back to being slow again.
It is the first time I am trying QEMU so my guess that the problem is around -serial mon:stdio line but it is just a guess.
This is the command I am using:
qemu-system-x86_64 \
-m 8192 \
--bios $(OVMF_LOCATION) \
-serial mon:stdio \
-net nic \
-net user,hostfwd=tcp::10022-:22 \
freebsd.img
The background: I am following the RTEMS OS setup instructions for running it on the QEMU AMD64: Board Support Package: amd64.
I was suspicious about the -serial mon:stdio part of my original command so I looked around to see what else do people try. I found that I have to replace this line with -nographic and it starts working without being slow.
This is how my command looks now:
qemu-system-x86_64 \
-m 8192 \
--bios $(OVMF_LOCATION) \
-nographic \
-no-reboot \
-net nic \
-net user,hostfwd=tcp::10022-:22 \
freebsd.img
I'm trying to emulate a Raspberry Pi with the Raspian OS using QEMU. I've tried several approaches described on the internet but without any success.
I figured out that I need to patch a Linux Kernel fitting the desired OS. In my case I chose Rasbian Lite with Kernel 4.4:
wget https://downloads.raspberrypi.org/raspbian_lite/images/raspbian_lite-2016-05-31/2016-05-27-raspbian-jessie-lite.zip
unzip 2016-05-27-raspbian-jessie-lite.zip
rm 2016-05-27-raspbian-jessie-lite.zip
Next I load a Kernel from https://www.kernel.org/:
wget https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.4.16.tar.gz
tar -xzf linux-4.4.16.tar.gz
rm linux-4.4.16.tar.gz
Now cross compiling the Kernel:
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabi-
cd linux-4.4.16
make vexpress_defconfig
make all
cd ..
Now I can copy the boot image, that is a compressed kernel image that auto-extracts in RAM, to my workspace:
cp linux-4.4.16/arch/arm/boot/zImage zImage
and run QEMU
qemu-system-arm -kernel zImage -M vexpress-a9 -m 1024 -cpu cortex-a9 -no-reboot -serial stdio -hda 016-05-27-raspbian-jessie-lite.img -append "root=/dev/sda2 rootfstype=ext4"
But all I see is a black filled QEMU-window. :(
I think that the problem is to get the right Kernel. Copying some of the Kernels from the Internet never led to success because they are not fit for the OS.
How can I build/patch a Kernel fitting the OS (without downloading an existing one) and how to run QEMU properly?
Thanks in advance
Alex
2nd approach
I load a kernel-qemu from here https://www.dropbox.com/s/g8u93xblz1v1ly0/kernel-qemu?dl=0 and run QEMU with it:
qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2" -hda 2016-05-27-raspbian-jessie-lite.img
This brings me the following output:
And it makes sense to me because the Kernel is 3.10.25 and older than Raspbian Jessie with Kernel 4.4.16.
With the qemu-kernel from https://github.com/dhruvvyas90/qemu-rpi-kernel/blob/master/kernel-qemu-4.4.12-jessie
qemu-system-arm -kernel kernel-qemu-4.4.12-jessie -cpu arm1176 -m 256 -M versatilepb -serial stdio -append "root=/dev/sda2 rootfstype=ext4 rw" -hda 2016-05-27-raspbian-jessie-lite.img
I got this similar result:
A new try with a new kernel-qemu 4.4.16:
Copy build-kernel-qemu from https://github.com/dhruvvyas90/qemu-rpi-kernel/tree/master/tools and add the following line to checkout the version for Kernel 4.4.16:
git checkout b05965f284db3e086022f4e318e46cb5bffb1376
Run build-kernel-qemu to build the kernel
sh build-kernel-qemu
Run QEMU
qemu-system-arm -kernel kernel-qemu -m 256 -M versatilepb -serial stdio -append "root=/dev/sda2 rootfstype=ext4 rw" -hda 2016-05-27-raspbian-jessie-lite.img
The result:
You should expand the Raspbian Image file before starting
Mount the Raspbian Image file with kpartx (might have to install kpartx)
$ sudo kpartx -av your-image.img
add map loop0p1 (252:5): 0 117187 linear /dev/loop0 1
add map loop0p2 (252:6): 0 3493888 linear /dev/loop0 118784
$ sudo mount /dev/mapper/loop0p2 /mnt/img1
$ cd /mnt/img1
Modify the /etc/fstab and comment out the MMCBLK mounts
$ sudo nano etc/fstab
proc /proc proc defaults 0 0
#/dev/mmcblk0p1 /boot vfat defaults 0 2
#/dev/mmcblk0p2 / ext4 defaults,noatime 0 1
# a swapfile is not a swap partition, no line here
# use dphys-swapfile swap[on|off] for that
Modify /etc/ld.so.preload and comment out lines ...
$ sudo nano etc/ld.so.preload
#/usr/lib/arm-linux-gnueabihf/libarmmem.so
Unmount and destroy loops from kpartx
$ sudo umount /mnt/img1
$ sudo kpartx -d your-image.img
Get the Qemu kernel matching the Raspbian image here...
https://github.com/dhruvvyas90/qemu-rpi-kernel
I used this command to successfully emulate Raspbian Jessie
qemu-system-arm -kernel kernel-qemu-4.4.12-jessie -cpu arm1176 -m 256 -M versatilepb \
-no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" \
-redir tcp:5022::22 \
-hda 2016-05-27-raspbian-jessie-lite.img
You need a modified kernel in order to run in QEMU, because the raspberry PI board hardware is not available in QEMU. That is why your first approach failed.
Your second approach uses a kernel properly patched to run on the versatile board (supported by QEMU), so that is good, but the kernel 3.x is too old for a modern Raspbian. In principle your last approach should have worked.
I recommend this updated guide (feb 2017), I tested it with a 4.4 kernel and it works straight away.
qemu-system-arm -kernel $KERNEL -cpu arm1176 -m 256 -M versatilepb -net nic,macaddr=$MAC -net tap -no-reboot -append "root=/dev/sda2 panic=1" -drive format=raw,file=$IMG
I had to use format=raw,file=$IMG option to avoid a QEMU warning.
You don't need to comment out /etc/fstab, you can add to /etc/udev/rules.d/90-qemu.rules
KERNEL=="sda", SYMLINK+="mmcblk0"
KERNEL=="sda?", SYMLINK+="mmcblk0p%n"
KERNEL=="sda2", SYMLINK+="root"
Also, The ld.so.preload thing is old and does not apply anymore
The script provided on the mentioned guide does all this for you, and also provides network access to your raspbian by sharing your network interface with raspbian.
Ubuntu 16.04 host, QEMU 2.9.0 -M raspi2, Raspbian 2016-05-27, vanilla kernel
Advantages:
with -M raspi2, we can use the vanilla kernel, so the system is more representative
Limitations:
-M raspi2 was added in QEMU 2.6.0, and Ubuntu 16.04 only has QEMU 2.5.0, so we have to compile QEMU from source. But this is not hard.
the GUI shows but is not responding to the mouse / keyboard, tested on both SDL and VNC. But CLI works perfectly however. So you might as well use the Lite image which has go GUI for now.
no networking
Steps:
Compile QEMU 2.9.0 from source:
sudo apt-get build-dep qemu-system-arm
git clone --recursive git://git.qemu-project.org/qemu.git
cd qemu
git checkout v2.9.0
./configure
make `nproc`
Download image and extract the kernel and dts from it:
Download the image and unzip it:
wget http://downloads.raspberrypi.org/raspbian/images/raspbian-2016-05-31/2016-05-27-raspbian-jessie.zip
unzip 2016-05-27-raspbian-jessie.zip
Mount the second image of the partition. The easiest way is:
sudo losetup -f --show -P 2016-05-27-raspbian-jessie.img
This only works with latest losetup on Ubuntu 16.04, other methods at: https://askubuntu.com/questions/69363/mount-single-partition-from-image-of-entire-disk-device/496576#496576
This prints a loop device, e.g.:
/dev/loop0
so we do:
sudo mkdir /mnt/rpi
sudo mount /dev/loop0p1 /mnt/rpi
cp /mnt/rpi/kernel7.img bcm2709-rpi-2-b.dtb .
sudo umount /mnt/rpi
sudo losetup -d /dev/loop0
Run:
./arm-softmmu/qemu-system-arm \
-M raspi2 \
-append "rw earlyprintk loglevel=8 console=ttyAMA0,115200 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2" \
-cpu arm1176 \
-dtb bcm2709-rpi-2-b.dtb \
-sd 2016-05-27-raspbian-jessie.img \
-kernel kernel7.img \
-m 1G \
-smp 4 \
-serial stdio \
;
You can then login on the terminal that shows on your host terminal.
[failed] Ubuntu 17.04, QEMU 2.8.0 -M raspi2, Raspbian 2016-05-27, vanilla kernel
On this newer Ubuntu, QEMU 2.8.0 is the default, so we don't need to compile QEMU from source for -M raspi2. However, 2.8.0 hangs on boot after the message:
Console: switching to colour frame buffer device 100x30
This goes to show how unstable -M raspi2 still is.
[failed] Ubuntu 16.04, QEMU 2.9.0 -M raspi2, Raspbian 2017-08-16, vanilla kernel
On this newer image, using the same method for 2016-05-27, the kernel panics at boot with:
Please append a correct "root=" boot option; here are the available partitions:
...
[ 4.138114] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
bztsrc/raspi3-tutorial RPI3 bare metal on QEMU
https://github.com/bztsrc/raspi3-tutorial is a good set of examples that just work on QEMU, ultraquick getting started at: https://raspberrypi.stackexchange.com/questions/34733/how-to-do-qemu-emulation-for-bare-metal-raspberry-pi-images/85135#85135
I had a similar problem with a custom ubuntu image.
I also applied the modifications as described in #Michael Connors' answer, then I see the system booting.
You can add the following in -append="" to see what happens in your case:
qemu-system-arm ... -serial stdio -append="... console=ttyAMA0,115200 loglevel=8"