Running the Qemu image

I went to the page where downloading the image qemu-x86_64 as explained. It says on
When I run this on my FreeBSD laptop with the command:

# qemu-system-x86_64 -boot menu=on -drive file=qemu-x86_64.qcow2,format=qcow2 -vga virtio -display gtk -m 1G

It boots up fine, but I don’t have any mouse support in the guest system and can’t slide the the screen from the bottom to unlock the “phone”.

The mouse in the host system works fine from touchpad and USB mouse in the Xorg server and in the moused. What could be the problem?

Btw: Before the “phone” comes to the screen, there is a login into PureOS presented (which I do ignore). What would be the login and password?


on debian

sudo qemu-system-x86_64 -boot menu=on -drive file=qemu-x86_64.qcow2,format=qcow2 -vga virtio -display gtk -m 3G -enable-kvm

password = 123456
the user is purism.

best regards

1 Like

I’m not sure why mouse support isn’t working for you in the guest system. Does it work with other images? For example, with live-booting ISOs for Linux distributions?

You can skip the slide to unlock to access the passcode/pin entry screen by pressing the space bar, then just type the passcode using the keyboard. That won’t help you much if you don’t have mouse support. :frowning_face:

mouse work with other images with live-booting ISOs linux on my pc (debian). On Qemu i dont know

It works, for example, with VirtualBox and an Ubuntu-17.10 ISO image. I will test it with qemu as well and report back.

Thanks, this unlocks but I can’t do anything, as you expected.

I booted an Ubuntu-17.10 ISO with qemu and no mouse either. So, it’s an Qemu or FreeBSD issue. I will dig into it in the FBSD community.

I had the same issue, I couldn’t see the mouse when the input was grabbed or something like that. Try Crtl Alt G and see if the mouse shows up.

Edit: Sorry, I actually misread that last post from @guru. I don’t think I’ve had the same problem on other VM’s. I’ll have to check later and make sure though.

I downloaded Qubes (last release) and transformed, with qemu in qcow2 format. I used the following string

sudo qemu-system-x86_64 -boot menu=on -drive file=Qubes.qcow2,format=qcow2 -vga virtio -display gtk -m 4G -enable-kvm

to make it the same as the one used for librem5) and I don’t see the screen of the virtual machine because graphically wrong but I capture the mouse that I release with CTRL ALT G

(added "last release)
best regards

i downloaded Debian-live-10-kde.iso and trasformed in qcow2 with qemu in qcow2 format. i used the following string from terminal
sudo qemu-system-x86_64 -boot menu=on -drive file=debian.qcow2,format=qcow2 -vga virtio -m 4G -enable-kvm
the mouse work very well when it is above the qemu window and executes the commands of the virtual machine without needing to release it (in qemu I had not enabled “capture mouse”)

Would it be an option for Purism to build as well a VirtualBox *.vdi file? I tried to convert the Qemu file with:

qemu-img convert -O vdi qemu-x86_64.qcow2 qemu-x86_64.vdi

but with this VB crashes on boot.

How is a vdi file normally built? If qemu-img cannot convert the existing image then it will require a separate process, won’t it?

Is there a way to import a qcow2 image, or even a plain img, into VirtualBox?

If VirtualBox is installed, you should have “VBoxManage”. I cannot the specific command in my head. But you can do something like “VBoxMange convert” and then somthing about the formats. It can convert a raw to vdi

Edit: let me know, if I should find a specific command

Thanks for the information. Hopefully @guru can import the qcow2 file using VBoxManage. :smile:

I’m not running VirtualBox myself because it’s not in the regular repositories for Debian stable - unless I’ve somehow missed it.

A qcow2 image must be converted with the tool qemu-img to VDI, i.e.

qemu-img convert -O vdi qemu-x86_64.qcow2 qemu-x86_64.vdi

but doing this, the VB crashes on boot;

A raw image could be converted with VB itself, like:

VBoxManage convertdd raw.img VBox.vdi --format VDI

Do we have a raw image?

Yes, the raw image has the .img.xz extension, so it will need decompressing with the xz tool first.

Here’s a build that is currently available: Build #2050.

So i don’t know if this workaround is expected to work?

So i downloaded the raw .img.xz and successfully decompressed it.
I successfully converted it to a .vdi via the command:

VBoxManage convertfromraw qemu-x86_64.img qemu-x86_64.vdi --format VDI

When I start the virtualbox from the .vdi I see the correct grub screen, and can select the boot-record, however the magic stops here.
It just hangs in a black screen with a cursor blinking, I don’t know if I have to make some other settings or so.

This is not so much of a post to get help, more for curiosity and to inform that it is at least not working out of the box.
(I use the qcow2 format without any problems with qemu)

I did the same and have the same problem: only a dark screen with blinking cursor line. The system is up, because if you use Alt+F1 you are switching to tty1 and a login is there, same is true for Alt+F2 … Alt+F6. After 2-3 secs it switches back to (perhaps) tty7 where the X should be running, but this is somehow not up. I’m struggling since 1-2 hours to get the network of the VB guest up (without any luck so far), to be able to SSH into the guest and see what the problem is.

Is there some way, that the “phosh” is not launched on start, to be able to login on tty1 and start it manually?

Someone from Purism should please dig into that or help me to get the feet into the door.

I verified that the .img image from Build #2050 works in qemu with this command:

qemu-system-x86_64 -boot menu=on -drive file=qemu-x86_64.img,format=raw -vga virtio -display gtk -m 3G -enable-kvm -device e1000,netdev=net0 -netdev user,id=net0,hostfwd=tcp::5555-:22

So maybe there’s something strange with VirtualBox. Do you need to have some extensions enabled for graphics and networking?

The same VB configuration boots fine any Ubuntu-17.10 iso image into graphical mode.

It does not help much, that you say “boots fine with qemu” and we both (Rhodez-x and I) have the same problem with VB. Wouldn’t it be better to download some VB and test the image within VB? Or, to give me a hint how to start the system without starting auto the phosh? Thanks.

Well, running the image in qemu helps to establish that the image isn’t completely broken.

I used a lot of time today trying to figure out how to get VirtualBox running on Debian 10 and ultimately failed, both using unofficial packages and ones from Someone with more experience of VirtualBox will need to provide assistance at this point.