VirtualGentoo gets a GUI

I recently went through the process of installing Gentoo into a bhyve VM using sylve.  After the first successful install which I broke during my attempt to get FVWM3 working, I decided I would use my blog post about it as a guide as much as possible for a second install.  I recognized a number of changes and a few chunks of additions to that blog post.  If I somehow break my VirtualGentoo a second time, now with the adjustments I can follow my blog post without needing to refer to the video.

Finishing up with xorg

This is the process of setting up a GUI for my Gentoo virtual machine.  The end of the first video talks about getting a very vanilla dwm up and running.  I might follow that instruction along with the next video that describes more of the process.  Once I have dwm working, I can switch to FVWM3.

What I did for myself was to add neovim and symbolic link it from vi.  I added the turbo c shell, which I can use by invoking it from bash to switch to it.
emerge -av app-editors/neovim
ln -s /usr/bin/nvim /usr/bin/vi
emerge -av app-shells/tcsh

In order for vipw or visudo to function with vi instead of nano as it presently expects, we need to complete three more steps.
eselect editor list

Available targets for the EDITOR variable:
 [1]	vi 
 [ ]	(free form)

eselect editor set 1
.  /etc/profile

The last of the preliminary steps that need to be done are to add a new user, set its password, exit from root, and login to the non-root user.
useradd -m -G users,wheel,audio,video -s /bin/bash tigersharke
passwd tigersharke

It seems that the video I used which was 3 years old that helped me get all the way here, is not the one that I thought it was at the end.  I had a newer video that was part two to a much more recent pair of videos.  That one mentions setting up dwm.  The older video continues after the preliminary xorg setup to install xfce which is nice, but its not what I had planned to do.  I also forgot that he installs dwm and a few other things directly from source obtained via git.

Setting up X begins with an edit to add or revise lines in the /etc/portage/make.conf

USE="X -wayland -gnome -kde -pulseaudio alsa ccache elogind dbus"

Video_CARDS="qxl"
INPUT_DEVICES="libinput"

Once that is setup, we can install xorg, and then set elogind to default boot level.
emerge -av x11-base/xorg-server
rc-update add elogind default

What I think I will do now is follow the gentoo handbook wiki about fvwm instead of doing xfce or dwm, although I may check with the videos to see what else I might do, what else could apply.

Installing and preparing FVWM3

We need to edit the ~/.xinitrc file to add one line.

exec dbus-launch --sh-syntax --exit-with-session fvwm

The install is rather short and easy as well.
emerge -av x11-wm/fvwm3

After all of this effort, the premise and goal cannot be reached.  It is not precisely the fault of any one component, it is not bhyve or gentoo but the combination of their methods and present capabilities that have failed me.  There is no pending 'fun' part because the fbdev or qxl driver of gentoo does not interface with bhyve in such a way that Xorg can find a screen.  It is possible to setup ssh to access the virtual machine that way, and even pass X out to the host to get application access, but this method is a bit laggy.  It doesn't seem like this ought to be the case but it is.  Maybe there are things to adjust in configurations on one or both sides that can improve it.  I guess I have a bit to learn regarding those possible solutions.  The driver issue I think is out of my hands and lay within the domain of Gentoo and/or bhyve devs.

sshd method setup

The setup of ssh I had already begun on the Gentoo side, which is good, and saves me time now.The setup on the host side is fairly simple as well.  Setting up for a feature of X which will permit much of our desires.Setup sshd which is already a part of the install by adding it to the default runlevel.
rc-update add sshd default

We need to edit the config for sshd on VirtualGentoo to enable a few options.  What I must change is the X11Forwarding but I also changed TcpForwarding, and possibly I should (or could) change UseLocalhost.

#AllowAgentForwarding yes
AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientActiveCountMax 3
#UseDNS no
#PidFile /run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

After those changes are made, we restart sshd on VirtualGentoo.
rc-service sshd restart One more detail we need, and this might be true only if we do not enable localhost above, and that is to find out what the IP address is of our VirtualGentoo machine.
ifconfig

VirtualGentoo /home/tigersharke # ifconfig
enp0s3: flags=4163  mtu 1500
        inet 172.16.0.29  netmask 255.255.255.224  broadcast 172.16.0.31
        inet6 fe80::685c:7d16:f123:bee  prefixlen 64  scopeid 0x20
        ether ea:34:6c:2e:b3:c5  txqueuelen 1000  (Ethernet)
        RX packets 12558  bytes 1366765 (1.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 10686  bytes 1204042 (1.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

VirtualGentoo /home/tigersharke #

On the FreeBSD host side, we already have xlibre and fvwm and xauth or install them now and then it is a simple matter of opening an xterm to type a command to start the ssh session.
ssh -X tigersharke@172.16.0.29
There is a supposedly more performant "trusted forwarding" mode with a small adjustment.
ssh -Y tigersharke@172.16.0.29

This will get us our access into the Gentoo Virtual Machine so that we can run any random command or GUIfied application, even games, but there does seem to be some lag.  I am not sure as yet if the lag can be reduced or how much but now we do have the ability to run something in Gentoo and use it in FreeBSD just not the way I had intended when I set out to accomplish this.