Seems that their is still a small (and disparate) community working on creating BSD (Berkeley Software Distribution) based Desktops. I went to TrueOS web site and this now leads to "TrueOS Discontinuation" page. Others including: GhostBSD, FuryBSD, MidnightBSD & NomadBSD have appeared to take up the mantel. Some only briefly, as "FuryBSD" now goes to a live porn sight...
I have re-tested setting up FreeBSD Desktop on KVM/QEMU with current 13.1 release and can report that this works with some fiddling.
FreeBSD Desktop Options
Having documented how to get FeeBSD Gnome Desktop up and running on QEMU / KVM) and using this with libvirt and virt-manager to test running Bhyve based VMs on, I thought I would look at other BSD distributions.
My interest was to see if some of identified bugs and work arounds had been addressed to get easy QEMU / KVM installs working.
Last time I looked at this in 2020 with TrueOS I gave up almost immediately as it did not run on QEMU / KVM via its default installation and being based on BSD 13.0 CURRENT tree meant that neither networking or virtio worked on newer Q35/OVMF VMs.
So I decided to try GhostBSD with QEMU / KVM. The good news is ...
GhostBSD Desktop can be installed as VM on QEMU / KVM "out of box", but only if you have physical access to the machine and you redirect a USB Mouse to the VM. You cannot do a remote install as this requires the QEMU USB Tablet driver to be installed, which is not included with install.
So GhostBSD (this like others options) does now work "Out of Box" on QEMU / KVM. So current options are:
- Do you own install using standard FreeBSD packages and tools and quite a bit of configuration
- Do GhostBSD install on QEMU / KVM with physical access to get mouse working and then "adjust after" the initial installation to enure this works remotely as well
- Do a VMWare or Virtual Box install and then convert to QEMU / KVM and then tweek VM to work with QEMU / KVM
As I wanted to avoid needing physical access to machine I opted to try (3).
Installing GhostBSD on VMWare and then Converting
Installing GhostBSD on VMWare Fusion works without any hitches. To create a VM that will work on QEMU / KVM create a "Customer VM" with:
- Other 64 Bit VM
- UEFI Firmware (ie not legacy BIOS)
- SATA Hard Disk (keep as 1 file)
- SATA CDROM (for install iso image)
- 2 CPUS with 4086MB RAM
Then simply boot from iso image and follow the installation process, selecting "scfb" graphics option. Only issue I had small was small problem with creating custom disk layout:
- GPT Disk Partitioning
- Partition 1: 200 MB efi Parition (for boot)
- Partition 2: XX GB freebsd-ufs with softupdates (ufs + s) for root "/" mount point
- Partition 3: XX GB swap
The problem appears to be that the disk partitioning tool did not like non-rounded up "swap" size, or leaving unused space on disk. Work around was to create swap first with round number and then using generated remaining space for ufs / root and then swapping the order of these back around using the caclulated sizes (ie Partition 2/swap == 2000 MB => Partition 3/root == XX MB (calculated) and then creating layout with Partition 2/root == XX MB (as calculated) and Partition 3/swap == 2000 (remaining) MB).
Having created the working VM, stop it and copy the "Virtual Disk.vmdk" image to your QEMU / KVM (Ubuntu) machine and convert the image to qcow2:
- Convert vmdk to qcow2 (on Ubuntu QEMU / KVM host): "qemu-img convert -f vmdk -O qcow2 'Virtual\ Disk.vmdk" <MY-DISK>.qcow2
Now create QEMU / VM based on the qcow2 image file:
- Q35 VM (version 4.2) with OVMF Firmware. Note that version 6.2 UEFI machine fails to boot with FreeBSD
- 2 CPUs + 4096 MB RAM
- SATA HD with <MY-DISK>.qcow2 image attached
- SATA CDROM
- virtio or e1000 Networking (these now work with 13.1 based FreeBSD distributions)
- qxl graphics, with increased vgamem size
- QEMU USB Tablet for mouse
You should now be able to boot your QEMU / KVM GhostBSD machine, but you will not be able to use the Mouse. So shutdown the machine (via menu or virsh) and reboot into single user mode (at boot press 2 at BSD boot splash screen).
Now remount disk as writeable, by doing: "df -h" to get the root mount point amd then remounting root partition as writeable:
% df -h Filesystem Size Used Avail Capacity Mounted on /dev/label/rootfs0 35G 7.2G 25G 23% / devfs 1.0K 1.0K 0B 100% /dev procfs 4.0K 4.0K 0B 100% /proc linprocfs 4.0K 4.0K 0B 100% /compat/linux/proc tmpfs 7.2G 8.0K 7.2G 0% /tmp linsysfs 4.0K 4.0K 0B 100% /compat/linux/sys fdescfs 1.0K 1.0K 0B 100% /dev/fd /dev/ada0p1 200M 1.7M 198M 1% /media/ada0p1 devfs 1.0K 1.0K 0B 100% /compat/linux/dev fdescfs 1.0K 1.0K 0B 100% /compat/linux/dev/fd tmpfs 7.2G 4.0K 7.2G 0% /compat/linux/dev/shm --- --- Now remount root as writable... --- # mount -t ufs -u /dev/label/rootfs0 /
And edit /etc/rc to:
- Enable sshd - to allow you to log into machine
- Disable mouse daemon - as we will be using QEMU USB Table
- Disable firewall temporarily so you can ssh into box
- Disable em0 network config (from prior VMWare install), if you have set up your VM to use virtio "vtnet" network device
The resulting /etc/rc.conf:
% cat /etc/rc.conf zfs_enable="YES" kld_list="linux linux64 cuse fusefs" linux_enable="YES" ntpd_enable="YES" ntpd_sync_on_start="YES" devfs_enable="YES" devfs_system_ruleset="devfsrules_common" dbus_enable="YES" lightdm_enable="YES" webcamd_enable="YES" cupsd_enable="YES" avahi_daemon_enable="YES" avahi_dnsconfd_enable="YES" # moused_enable="YES" <<=== disabled # ipfw_enable="YES" <<="==" firewall_enable="YES" ifconfig_em0="DHCP" sshd_enable="YES" enabled keymap="us.kbd" hostname="YOUR-HOST" ifconfig_vtnet0="DHCP" < code>===>
Now reboot and ssh into machine (as you still will not have mouse access). To get mouse access via QEMU USB Tablet install the "utouch-kmod" package (you must su to root first): "pkg install utouch-kmod".
NOTE: If you do not know your machines IP address but have the MAC address from QEMU / KVM then you can use "arp-scan" utility to get the IP address:
--- --- On Ubuntu QEMU / KVM Host --- # sudo apt install arp-scan --- --- find which link for the subnet that the GhostBSD machine is on --- # ip address | grep '192.168.XXX' <<=== 24 where grep is for subnet machine on inet 192.168.xxx.67 brd 192.168.xxx.255 scope global ens4f0 --- now do arp-scan from port ens4fo sudo -v -i 192.168.xxx.0 | <mac-addr> < code>===>
And update "/boot/loader.conf" to load the driver.
NOTE: This is exactly the same as with getting FreeBSD Gnome Desktop up and running on QEMU / KVM. Here is example: "/boot/loader.conf" (only first two lines have been added, rest are standard GhostBSD configuration):
% cat /boot/loader.conf utouch_load="YES" kern.vty=vt rc_system="bsdrc" crypto_load="YES" aesni_load="YES" geom_eli_load="YES"
On reboot you should have a working mouse via QEMU USB Tablet ..
Finally for slightly more snappy performance you coud update the "scfb" graphics to "qxl" graphics via "xf86-video-qxl" driver, which needs to be compiled and loaded. The instructions for this are as per FreeBSD Gnome Desktop notes.
If you do decide to build and install qxl video driver then you should update /etc/X11/xorg.conf:
% cat /etc/X11/xorg.conf Section "Device" Identifier "Card0" Driver "qxl" <<==== changed from "scfb" endsection< code>====>
Aside for this Xorg configuration, the rest of GhostBSD does not have any predefined configuration and so it close to "automagically" onfiguring itself.
GhostBSD is much more polished than prior FreeBSD Desktops and is very close to providing "Out of Box" QEMU / KVM intall.
For my needs which is mostly to test with Bhyve, I am comfortable to still use FreeBSD with Gnome.
If you really want to have a FreeBSD desktop as alternate to Ubuntu (or other Linux) Desktop for using open source tools like OpenLibre, Gimp etc then GhostBSD seems like a viable option. I was all the usuall software available, integrates with NFS (unix), CIFS/SMB (Windows) and AFP (Apple) network environments and would be easy transition for Linux Desktop users.
Given how close GhostBSD is to providing a QEMU/KVM installable FreeBSD Desktop I will post my I my findings and fixes to see these can be pushed back upstream via the GhostBSD effort.
NOTE: Doing an automatic update GhostBSD can result in change to the ABI (Application Binary Interface) and so the qxl device load will fail (if you have compiled this and added as driver). This will require a recompilation of the xf86-video-qxl module, or change back to "scfb"
References & Links:
TrueOS Discontinuation Notice
FreeBSD Gnome Desktop - Install notes updated for FreeBSD 13.1
GhostBSD - another valient effort to create a better BSD desktop experience