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
Related
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!
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 have a FreeBSD image that contains /boot/loader* and /boot/kernel and more. It boots fine under an EC2 instance but I would like to boot it with Qemu. I have tried various methods, but they have not worked. See below.
qemu-system-x86_64 -kernel kernel -nographic -append 'console=ttyS0' disk.img
qemu-system-x86_64 -kernel loader -nographic -append disk.img
This boots on Ubuntu 20.04 amd64 host, QEMU 4.2.1:
wget https://download.freebsd.org/ftp/releases/VM-IMAGES/12.1-RELEASE/amd64/Latest/FreeBSD-12.1-RELEASE-amd64.qcow2.xz
unxz FreeBSD-12.1-RELEASE-amd64.qcow2.xz
sudo apt install qemu-system-x86
qemu-system-x86_64 -drive file=FreeBSD-12.1-RELEASE-amd64.qcow2,format=qcow2 -enable-kvm
The username is root with empty password:
The download page for that image is: https://www.freebsd.org/where.html
Unfortunately, trying to add:
-serial mon:stdio -nographic
to get rid of the GUI only shows the bootloader images on the terminal, but not the rest of boot. https://lists.freebsd.org/pipermail/freebsd-hackers/2005-March/011051.html mentions how to fix that by modifying the image, which is annoying, but worked. On the GUI boot, I did:
echo 'console="comconsole"' > /boot/loader.conf
and then the next nographic boot worked fully on my terminal.
You can quit QEMU -nographic with Ctrl-A X as shown at: https://superuser.com/questions/1087859/how-to-quit-the-qemu-monitor-when-not-using-a-gui/1211516#1211516
The next issue is that the disk is full, I have to learn to increase its size. From interactive df -Th inspection, the image appears to contain a single raw UFS partition. I tried:
qemu-img resize FreeBSD-12.1-RELEASE-amd64.qcow2 +1G
but that is not enough presumably because the partition itself was not resized to fit the disk. Likely this can be achieved with gpart as shown at: https://www.freebsd.org/doc/handbook/disks-growing.html but I don't have the patience right now.
The FreeBSD wiki has some recipes how to run FreeBSD inside Qemu
https://wiki.freebsd.org/QemuRecipes
QEMU supports deterministic record and replay as documented at: https://github.com/qemu/qemu/blob/v2.9.0/docs/replay.txt
However, I could not get replay working for a full Linux kernel boot: it always hangs at some point.
These are the commands I'm running:
#!/usr/bin/env bash
cmd="\
time \
./buildroot/output.x86_64~/host/usr/bin/qemu-system-x86_64 \
-M pc \
-append 'root=/dev/sda console=ttyS0 nokaslr printk.time=y - lkmc_eval=\"/rand_check.out;wget -S google.com;/poweroff.out;\"' \
-kernel './buildroot/output.x86_64~/images/bzImage' \
-nographic \
\
-drive file=./buildroot/output.x86_64~/images/rootfs.ext2,if=none,id=img-direct,format=raw \
-drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay \
-device ide-hd,drive=img-blkreplay \
\
-netdev user,id=net1 \
-device rtl8139,netdev=net1 \
-object filter-replay,id=replay,netdev=net1 \
"
echo "$cmd"
eval "$cmd -icount 'shift=7,rr=record,rrfile=replay.bin'"
# Different than previous.
eval "$cmd -icount 'shift=7,rr=record,rrfile=replay.bin'"
# Same as previous.
eval "$cmd -icount 'shift=7,rr=replay,rrfile=replay.bin'"
and my kernel and root filesystem were generated with this Buildroot setup: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/0a1a600d49d1292be82a47cfde6f0355996478f0 which uses QEMU v2.9.0.
lkmc_eval gets evaled by my init scripts. Here we print userspace stuff that is usually random to check that we are actually deterministic, and then power off the machine.
How I came up with those commands:
start from the working command I used in my repo without record replay
copy paste the hard disk and networking parts from the wiki: https://wiki.qemu.org/Features/record-replay
The in-tree docs say there is no networking support, but the wiki and git log says they were added as of v2.9.0, so I think the docs are just outdated compared to the wiki.
Using that setup, the boot replay progresses quite far, but hangs at the message:
[ 31.692427] NET: Registered protocol family 17
In the initial record, the next message would have been:
[ 31.777326] sd 1:0:0:0: [sda] Attached SCSI disk
so I'm suspicious that it is a block device matter.
The timestamps are however identical, so I'm confident that the record and replay has worked so far.
If for the networking I use just:
-net none
then the record itself hangs at:
[ 19.669685] ALSA device list:
[ 19.670756] No soundcards found.
If anyone wants to try a QEMU patch against it, just checkout to your patch inside /qemu/ and run:
./build -t host-qemu-reconfigure
to rebuild.
Your command line looks ok, but unfortunately record/replay is QEMU is broken in this release.
I hope that it will be fixed in the nearest weeks.
I am trying to set up an Arch image and use qemu in order to cross-compile some stuff before I load the image onto the Pi. I thought the easiest way to do it would be to qemu the latest starter image, prepare it with whatever I needed, and then dd it onto the Pi when I was done.
I downloaded the Arch image from http://downloads.raspberrypi.org/arch_latest, and wanted to run it under Qemu similar to http://xecdesign.com/qemu-emulating-raspberry-pi-the-easy-way/.
I tried many variations on the qemu command line they gave
qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1" -hda 2013-05-25-wheezy-raspbian.img
substituting the archlinux-hf-2013-07-22.img. But this eventually led to "Kernel panic - not syncing: No init found. Try passing init= option to kernel"
I'm sure this means the kernel-qemu I downloaded won't work with the Arch image, but I'm not sure the right way to fix the issue.
Edit:
Even the latest Raspbian image kernel panics when I use the command line above with it. Which I guess shouldn't have surprised me, since it's most likely an old kernel.
So I guess my real question is, how can I use whatever kernel is included in the image, rather than having to build my own kernel?
In case archlinux-hf-2013-07-22.img
Here there 3 partion are made.
you can check by using
fdisk -l archlinux-hf-2013-07-22.img
rootfs is in sd5 i.e 5th partion.
So pass this parameter "root=/dev/sda5 panic=1" , it will boot perfectly.
In 2013-05-25-wheezy-raspbian.img
You can use same kernel for both image.
Here you have to comment ld.so.preload which will load some shared-library,which will unable login. so kernel panic.
Note:-"root=/dev/sda2 panic=1" pass this parameter only.
You can comment it by doing below.
sudo kpartx -av 2013-05-25-wheezy-raspbian.img
mkdir tmp
sudo mount /dev/mapper/loop0p2 tmp/
cd tmp/etc
sudo vi ld.so.preload
/usr/lib/arm-linux-gnueabihf/libcofi_rpi.so
comment
#/usr/lib/arm-linux-gnueabihf/libcofi_rpi.so
umount /dev/mapper/loop0p2
kpartx -d 2013-05-25-wheezy-raspbian.img
Then run qemu
qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1" -hda 2013-05-25-wheezy-raspbian.img
this will perfectly boot without any trouble