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.
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.
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
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”)
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
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.
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 virtualbox.org. Someone with more experience of VirtualBox will need to provide assistance at this point.
