Sylve for clean jailed build

My previous description of using sylve for porting software to FreeBSD did not include two features that I have decided to enable, but which also cause me some little bit of grief because the most simple method around it seems to no longer exist.  I setup sylve which was easy, then I configured a jail, and I have used the jail for updating a number of ports since.  I may use it to create new unofficial -dev ports.  What I did not do, was begin from nothing for the start of any port.  What I have been doing lately is just that, begin with an empty jail with the bare minimum required for any port to build from a Makefile, and then reset the jail after.

Sylve has the functionality already integral to the system.  We need to create a ZFS snapshot after the minimal configured jail with minimal required ports are installed.  After the snapshot exists, we can rollback any time at will and also configure sylve to automatically rollback when the jail is stopped.  All of this is easy from within sylve.  The other parts of the jail configuration include some allowed options for the jail, and the fstab entries to allow access to my home directory where my git directories are, and one for ports so I can avoid duplication as well as for consistency between jail builds and builds outside of it.

We need to go to the jail options tab to make some adjustments.  Each item expands by clicking the property name, then going to the top to click the edit button.

OPTIONS

Property

Value

/etc/resolv.conf

—

Additional Options

—

Allowed Options

allow.set_hostname Mount devfs Mount nullfs Raw sockets Reserved ports Set hostname Socket address families Super User privileges SysV IPC

DevFS Ruleset

—

Execution Timeout

120 seconds

FSTab Entries

/home/tigersharke /zroot/sylve/jails/200/home/tigersharke nullfs rw 0 0 /usr/ports /zroot/sylve/jails/200/usr/ports nullfs rw 0 0

Lifecycle Hooks

        Pre-start

no-tick

        Start

ticked

/bin/sh /etc/rc

        Post-start

no-tick

        Pre-stop

no-tick

        Stop

ticked

/bin/sh /etc/rc.shutdown

        Post-stop

ticked

zfs rollback zroot/sylve/jails/200@sjs_fresh-start_1789000233518

Metadata

—

Start At Boot / Start Order  

No / 0

Wake on LAN

No

The snapshot needs to be made but after it exists, clicking on the snapshot line copies the name for it.  The whole path starts with the zfs pool name and the default path of sylve/jails and the id number for the jail followed by an @ and then the snapshot name you copied.

I have all of my -dev repo directories in my home directory organized using the same directory hierarchy as the ports tree (which is important).  In my /etc/make.conf are the necessary lines including one to setup the overlay, this needs to be created inside the jail as well as outside.  For example, my luanti-dev directory path is /home/tigersharke/GitRepos/PortsTree/games/luanti-dev.

/etc/make.confDEVELOPER="YES" DEFAULT_VERSIONS+=ssl=openssl WITH_CCACHE_BUILD="YES" OVERLAYS=/home/tigersharke/GitRepos/PortsTree/

Since we are starting from nothing but the most mandatory initial programs and configuration, any build from that first Makefile (such as for one of my unofficial -dev ports) will potentially cause a build and install of as many as 1400 other ports.  Once upon a time, there was an environment variable that pkg honored which would tell it to install all dependencies as packages rather than build from source via ports.  This functionality is no longer available when building directly from a Makefile in the ports tree.  The good news, as slight as it may be, is that there is still a method to get close to the same result.  I wrote a script for each step of the process.

The first script starts with make build-depends-list run-depends-list which we can pipe to sort to alphabetize and remove duplicates, then pipe to sed and awk to exclude the initial base ports and to remove /usr/ports/ from each line as well, and finally direct it to an output file.

#!/bin/sh
# First Dependencies
make build-depends-list run-depends-list | sort -u -d | sed -e 's:/usr/ports/::' -e 's:devel/bsddialog::' -e 's:devel/ccache::' -e 's:devel/desktop-file-utils::' -e 's:ports-mgmt/pkg::' -e 's:ports-mgmt/portconfig::' | sed '/^$/d' > first_deps_list

Another script takes a file name as input to send to pkg so the content of the file is installed.

#!/bin/sh
# Prep
yes|pkg install `cat $1`

The third script uses pkg origin output which is also similarly organized and cleaned up for an output file with a larger list.

#!/bin/sh
# Most dependencies
PORTNAME=`make -V PORTNAME`
SELF=`pkg origin | grep $PORTNAME`
pkg origin | sort -u -d | sed -e 's:devel/bsddialog::' -e 's:devel/ccache::' -e 's:devel/desktop-file-utils::' -e 's:ports-mgmt/pkg::' -e 's:ports-mgmt/portconfig::' | awk -vLine="$SELF" '!index($0,Line)' | sed '/^$/d' > most_deps_list

This whole process mostly works well, except that when there are conflicting pkgs installed, such as llvm-lite and llvm, or git-tiny and git, especially when an automatic removal of one of the lesser used dependencies causes something like sdl3 to also be removed.  Not a problem but note when trying to build and install the updated or nascent unofficial -dev port, whether it still wishes to build dependencies.  At that point we can leave and allow it to chug away while we are not present, or just cancel the process to install it from pkg, and then clean and resume the install until the next ones if there are any.

The other method if those scripts are not used, is to set the build process going, re-starting it when it unexpectedly fails to get a dependency of a dependency somewhere (which truly should never occur) and then once it is entirely complete, use pkg to get a list of what was installed.  We can stop the build when we notice an extra long compile such as for llvm or any other thing, use pkg for that, clean up and restart the install.  After the build is done, we use pkg origin piped to sort and direct into an organized file, then remove the five mandatory initial ports: devel/bsddialog, devel/ccache, devel/desktop-file-utils, ports-mgmt/pkg, and ports-mgmt/portconfig.  Another two are useful to have for Makefile testing and cleanup: ports-mgmt/portfmt for portclippy, and ports-mgmt/porttools for portlint.  Portclippy has a way of helping visualize how to organize your Makefile, portlint tests various things needed for a proper FreeBSD port.

Any of the secondary lists will likely be larger than a preferred group of dependencies because it is best (for testing and development) to accept the one-size-fits-most default configurations of each and not the most lean build of any or all ports.  This is important because most users will use those defaults rather than a longer process of building customized ports locally.  When the Makefile for the resulting port is used, we can choose other options that may reduce or change dependencies from those defaults.  For testing, any options that affect what is installed should be ticked, any options that are unproven or may change upstream should also be tested, ticked.  My own system denies wayland, so I already have a few things I must build for myself due to a wayland default in the official FreeBSD pkg repo.

Regardless of whether we use the speedier or slower method initially, I believe it is best to do another pkg origin directed into a file for the final actual dependency list, minus those five ports of course.  Those mandatory ports are in the snapshot and so they will always remain after a rollback.  We are making this all-origins file so that each time in the future when we update the -dev port from an effectively empty jail, hopefully we will not need to spend any extra time to build the dependencies.  I could keep a jail for every port and leave those dependencies intact, but only up to the point that upstream changes them.  By keeping these lists and re-populating the jail before a build, its a happy medium without taking too much time after its setup.

It seems that no matter how much care is taken when compiling the list of dependencies for speedy easy install by pkg, there is a chance that weird conflicts among all of the dependencies may occur.  When this happens, automatically accepting by -y or piped yes, may also cause some dependencies to be removed just as quickly.  Instead of wasting effort on that, just get the best list of dependencies as possible, use pkg to install them, and then continue with the fresh build of the port.  I don't know how to manipulate pkg to get a better result or to ignore its sat solver.  I also don't know whatever it would take to truly re-implement that lost capability to install all dependencies with pkg instead of building any that exist in ports.

The main reason we want to test ports, or attempt to port new software, or update ports from within a clean jail, is that dependencies are not silently satisfied and therefore missed in the Makefile.  Another reason is that your main system also remains more clean and "uncorrupted" by all of the excess packages or ports that get installed to satisfy dependencies, or that are installed in hopes of satisfying dependencies.  Inside the jail we can set it up to be much more vanilla than our personal preference outside of it.  And one more good reason, is if we use what is built within the jail which means it is also installed outside of the jail, the update to a port or any testing done in the jail will not cause the executable such as a game, from being uninstalled or broken outside of the jail.  A jail can also be setup to be less vanilla but also distinct from the system outside of it, and again, means that system outside is unaffected.

Use sylve to very easily manage a dozen different jails, or just one.  Sylve makes the management accessible and visible, all of the options are present, it allows a fresh clean jail on demand, even if it is the same one you always use for a purpose.  Working from within a web browser for the interaction may change some things a little bit but those are easily understood.  I get around some of the differences by being able to work with git in the same directory from outside of the jail, but I think its the browser that is getting in the way rather than a quirk with sylve.  The more sylve is used, the greater chance for improvement, but it is still a great tool in its relatively early days.

jail porting with sylve

Once before, in the now distant past I had used a spiffy GUIfied tool to handle jails on my FreeBSD system.  This was Warden on PC-BSD.  It was super helpful and easy to use.  Since then I have tried numerous different tools including bastille.  Of those, only bastille worked for me and was easy enough to use.  Unfortunately I never got accustomed to using it, not having used it enough.  I recently played with sylve as a tool for handling Virtual Machines in bhyve, and since it also has a jail function I have decided to test this out too.

My recent perceived finished Mudlet port seems to have developed a pile of flaws after I erased everything installed on my system when not long ago I had graphics issues.  It is because of this that I am going back to using jails for my periodic port updates if possible, and definitely when I do the initial porting.  This will ensure the option of a clean system with nothing else installed, so that I can start from zero without suffering the lack of things installed on my host system.

sylve jail setup

The setup seems very simple, there is a basic guide on the sylve site that helps to inform the user what each setting is about.  I followed it to get the initial jail setup accomplished but if I can mount my ~/GitRepos/PortsTree and possibly even use that as an overlay of the main ports tree, that would be ideal.

Click image to enlarge

When we create a jail, first from the Basic tab we choose a jail name and host name, they can be the same, and it makes sense to set 200 for the first jail ID.  From the Storage tab, we choose the host ZFS pool, and the Base we downloaded.  I could have chosen a 15.x release image "base.txz" but since there are snapshots for 15.1-stable, I chose to use that as it would be closest to what I have on my host system.  Using something nearly identical to what is on Ichigo will help me duplicate all aspects I already know, and help me find other issues that I have not yet discovered.  From the Network tab I choose Inherit, so that the jail uses the host's connectivity.  Accessing the Hardware tab lets us choose various limits, so I untick Resource limits.  I am unsure precisely what Clean Environment means, but I leave it ticked.  We also choose between Linux and FreeBSD jail type which I leave as FreeBSD because that was what I need for my purposes.  The Allowed Options dropdown includes a number of things we should tick for the jail purpose I need: Set Hostname, Raw Sockets, Mount devfs, Socket Address Families, Reserved Ports, Mount nullfs.

One thing I need to do to make use of the ports tree on the host is to null mount it within the jail.  I could set it as read-only because there are no changes I will need to make, but adding it will eliminate the need to re-create it within the jail.  The small problem is that /usr/ports/distfiles needs to be read-write, so we make the whole /usr/ports read-write.  We need to enter the jail to create the mountpoint, /usr/ports before the fstab can be successful.

Click image to enlarge

On sylve, we need to edit the fstab for the jail.  The jail I created has its name and an ID number in parenthesis, I set mine as 200 so that the ID will be distinct between VMs and Jails.  We click the jailname we gave it, underneath our hostname in the tree on the left.  Underneath the summary tab, at the bottom is options.  We click the options tab which opens a window showing property and value.  Right now there is no value for the FSTab Entries property.  We click on that line, and a new button, Edit FSTab Entries appears.  When we click on the edit button, we get an empty window with the title FSTab Entries.  Into the FSTab Entries window we type the line to add the host ports tree into the jail.

/usr/ports   /zroot/sylve/jails/200/usr/ports   nullfs   rw   0   0

Getting the nullfs mounted ports tree took me a bit of trial and error, since things are slightly different with sylve than they are for other jail managers.  I couldn't look at examples or forum posts and do the exact same thing, I had to try a couple ways to see which was successful by discovering which attempt permitted the jail to start.  Once it started I could use the console button below the summary button to verify by doing an ls of /usr/ports.

The other thing I want to do, to make things easier for myself, is to use a ports tree overlay of my ~/GitRepos/PortsTree onto the official FreeBSD ports tree.  The only time I have done this successfully was using the instructions to build xlibre the first time.  Its already been a while since I did that, but referencing the instructions at b-aaz/xlibre-ports on github, it tells me to clone that repo and enter it, then echo the pwd into the make.conf, and so to translate this to my purposes I do a little differently.

cd ~/GitRepos/PortsTree
echo "OVERLAYS=$(pwd)/" >> /etc/make.conf

This I can also do on the host in order to setup the overlay there as well.  What I am unsure about but seems likely, is that I may need to edit or remove the various directory Makefiles and the MOVED file.  Doing this in the jail will inform me about whether that is necessary.  However, to even attempt the ports overlay that I want, I will need to add two more lines to the fstab and create its mountpoint /home.

/home/tigersharke   /zroot/sylve/jails/200/home/tigersharke   nullfs   rw   0   0

One more detail that missed my recognition, we need to initialize pkg by initiating a pkg update.  Once this is done, a fetch in any of my -dev ports will succeed to register.  When I did a make config I discovered a new improvement that tripped me up some years ago.  Attempting to make config will cause bsddialog and portconfig to be installed, which otherwise would have caused the make config to fail, this was a pleasant surprise.

Working on porting

I had forgotten that I had a duplicate of yajl in the devel directory of my own PortsTree which necessarily conflicted with the official one because I didn't name it to be unique.  This didn't matter until I used my pseudo ports tree with the overlay, but now it caused unusual errors.  Easily fixed, I renamed the directory with the -dev suffix.  At the same time I renamed any extra Makefiles and the touched MOVED file with a hid- prefix.  I may not need them but I'm keeping them around for now.

When I tried to build Mudlet outside of the jail, before I set all this up, I ran into some weird errors.  It took me a while to recognize that the issue was one Mudlet dependency.  The lua-luarocks dependency is an oddity itself.  If you tick the option to use luajit instead of ordinary lua, then lua-luarocks has no flavors.  If you do not tick that option, lua-luarocks does have flavors.  This is somewhat of a concern but I am not sure how to permit either to satisfy the dependency for Mudlet.  I am going to add a note in the Makefile and use the unticked option build of lua-luarocks.

make all-depends-list | sed -e 's#^\/usr\/ports##' > all-depends
yes|pkg install `cat all-depends`

Another oddity originates from how I populated the jail.  Without anything installed, I chose to make an all-depends-list and use that to have pkg install all of those dependencies in the jail.  This greatly speeds things up but since this is an empty jail, there are more than 1000 things to install.  After all of that was installed, the build declares that I need a different port to satisfy the zip requirement, so I revised that dependency line and later, outside of the jail, it wanted to use the other zip dependency.  I decided to have both listed and let the system install whatever.  I am not sure yet if I need to have an option for whether to use zip or minizip.

The build eventually succeeded inside the jail and outside the jail, and I continued to update Mudlet for the more recent upstream commits, my own Mudlet-dev repo advancing from June 26th all the way to July 6th.

Later I adjusted the patch files with conditional wrappers and then on a whim, checked to see how many of the four patches were actually required.  What I discovered was that only one file must be patched and it needs both of the two patches within the GeyserAdjustableContainer.lua file.  I have since submitted a pull request for this patch to upstream Mudlet so that either my corrections will be applied for FreeBSD or better understanding of the issue will lead to changes which may obsolete FreeBSD specific patches for it.

After I setup git with my email and user name, I had to fix the dubious directory permission/ownership setting in git to quiet that complaint.  I had to add my github token file to my root in the jail, so I can copy and paste it, or maybe copy from outside and paste it into the console.  I also may want to eventually add any number of aliases or scripts that would make porting easier within the jail.  One thing that will be very nice is that the options for any port can be different within the jail than outside.  This means that when I rebuild luanti or mudlet for the latest commit, when I build it to use, I can leave the options set to only those that I personally need or want.  I won't need to tick and then untick for the two builds, but also there will need to be two builds because one is in the jail.  I frequently did build twice normally, so this will be a small improvement.

Sylve jail thoughts

Using sylve via librewolf is with a console screen in the browser.  This is a bit different than an xterm, the cursor is a blinking bar on the left edge of the current occupied space or character which takes a little getting used to.  Another difference is that I like to use the mouse to select and paste which is common for Unix/X but can be challenging in the sylve console.  Instead of select with one mouse button and paste with another, its select and control-v to paste.  This is functional but a little strange.  Selecting within the console can be difficult to limit to the line you desire, primarily if the line is near the bottom edge.

I had moments when sylve (or librewolf) forgot that I was typing in the console, and it took a little bit to sort of wake it up, or maybe it simply did not scroll to match what was displayed.  There is also some weirdness with how the option screen for a port configuration appears to me, a bit washed out and a kind of broken almost graph-paper appearance though all a pale blue.  I don't know why it looks like this, except that it is some kind of interpretation by either sylve or librewolf.  Its not something I could determine as able to be changed.

We can change the font size and color or background color from a gear icon in the upper right, so I chose green text on black, and size 14 font.  Closing that dialog after the change sometimes leaves it accessible, so pressing return or clicking the console could brings it back, but it is easily hidden again and doesn't appear unintentionally another time.

I figured out how to get the text in the console to have a gap between it and the bounds of the window with a little CSS but I was unable to figure out how to get the lines in the textarea to have a bit more spacing, and I have not yet checked whether I can use CSS to adjust the cursor.

.terminal-wrapper
{
    padding-left:8px;
    padding-top: 4px;
    padding-bottom: 4px;
    user-select: auto!important;
}

Sylve is definitely functional for use to setup a jail and to stop or start it, and I will be continuing to use it for that function, as well as for the virtual machine I setup previously.  I believe I can access a jail with a simple chroot into it since its localhost, so if I wanted, I could do similarly as with the VM and reach it with an ordinary xterm but with chroot instead of ssh.  Perhaps I am misremembering or it might have been a thing with Warden, so I was wrong, but it seems as though using sh is also the way to access the jail if I do not use the sylve console.

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 /etc/ssh/ssh_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.

sylve makes gentoo bhyve vm

I have decided to try using Sylve and rather than create "Just another BSD on Disk" even though I may at a later date, I am deciding to put Gentoo in a VM.  A long time ago, I had it setup and ready to use on a now non-booting host using Virtualbox.  Shortly before, I had installed ubuntu successfully after a few small difficulties but then discovered that the OS itself seemed to have problems.  I believe that even if I have some difficulties with gentoo, I will be able to find my way out of them.  As before, the process is rather involved, and I am going to follow the same youtuber with his newer friendlier to new users, more descriptive Gentoo installer video. The youtube video I followed for the bhyve setup was from BSD Jedi called FreeBSD - Installing and Using Sylve and helped me quite a bit, but I will make a few small clarifications to it.  I believe it will be much better for me to use bhyve than Virtualbox, this new VM will be for a similar purpose, to use Linux software and to help me with porting it.

Setting up sylve and the VM

The initial step, pkg install sylve works fine for me as I use the latest branch of FreeBSD ports with 15-stable.  The next commands are for preliminary setup, sysrc sylve_enable=yes and then service sylve start to get it running.  Finally, an open browser window to the localhost IP, with port 8181 will bring us to the sylve interface.

Click image to enlarge

Since I am using a real machine and my machine name is ichigo, I click that dropdown which is shown below one named Data Center.  After I click ichigo, the summary window opens, and note the two dark buttons in the upper right, Create VM and Create Jail.  Before we begin with setting up the Virtual Machine, it is easier to download an iso using the host machine, a seperate tab on the gentoo downloads page can be opened.  Initially I had chosen the liveGUI image but have since downloaded the minimal iso.  This is the part of sylve that is a little bit less clear.  I had less success with downloading from a remote site with the sylve mechanism, so I download with the host machine.  Making this new iso available to sylve is done by downloading with a pathname.  I downloaded install-amd64-minimal-20260524T170105Z.iso into /home/tigersharke/Emulators so my next steps are as follows.

Click the ichigo dropdown button, click the utilities dropdown which is visible beneath the 'Node -- ichigo' header, and between the storage and settings buttons.  Under the utilities dropdown it reveals 'Cloud Init Templates' and 'Downloader' so I click on Downloader.  When the downloader displays to the right of the dropdowns, it lists any files that sylve has been informed of existing.  I need to add the gentoo iso, so I click the new button which opens a Download window asking for Magnet (torrent) or Web URL or path.  Below is a box with example magnet text but as soon as anything is typed there, the example text is gone.

I copy and paste the path, add a / and then paste the file name.  The Download type is already Uncategorized and leaving the filename alone means it will default to what was already entered for the file name.  It is an iso, so no need to extract or convert it.  I click the download button and wait for it to complete.  Now the listing in the Downloader shows install-amd64-minimal-20260524T170105Z.iso with uncategorized, a size of 988.73 MiB and 100% for progress.  All of this means that sylve knows that the iso exists and can be assigned to a virtual machine.  Doing this at the outset is one way to get it done, but if, as I had done, the virtual machine is created with the livegui-amd64-20260510T170106Z.iso file attached, the way to get the iso is a similar process which I describe later.

The next step I would recommend before creating the VM is to create the network device.  The network device is part of the host machine, so I click ichigo, to show similar settings dropdowns as may be shown for a VM.  The difference is that a network device cannot be defined by the VM, it can assign a defined device from the host.  Just as BSD Jedi tells us, click network, and then click switches, and choose standard from the dropdown.  Open the dialogs to create a new standard switch by clicking new.  Give the switch a meaningful name that will not lead to future confusion, something like bhyve-LAN would be distinct from LAN if ever looking at other network configurations at home.  For the ports selector, choose the ethernet adapter of the host machine, mine is igb0.  Tick DHCP and SLAAC and then click create.  The other details do not need to be specifically defined, sylve or bhyve will handle them.

Right now all that has been done is to prepare for creating the VM.  Click the host machine name, it may be directly below the 'Data Center' tab, which for me is ichigo.  A summary of your host machine will be displayed.  Now the button in the upper right, Create VM is clicked for its dialogs.  First the basic details, such as a name and a unique VM ID number.  Storage defaults to ZFS Volume which I use, then select my storage pool, zroot and give the VM 20GiB of space.  The installation media is where we choose the iso that was setup earlier.  The network dialog will show the bhyve-LAN that was configured, and the choice of none, which means those same steps to create the switch would be done later.  In the hardware dialog, this has to be enough capability and memory for the machine to succeed.  I use 1 socket, 4 cores, and 1 thread.

A special note about the processor choices, it will not let you start the machine later if the combination of cores, processors, and threads is more than what you actually have.  For my situation, 1 socket, 4 cores, and 1 thread, or 2 sockets, 2 cores, and 1 thread, both would work.

I don't pin any CPU but I give the VM 32GiB of memory (I have 128GiB).  Another important step is in the Advanced panel, VNC Resolution should be set reasonably now because I am unsure how it gets defined otherwise, though likely with a config file that could be edited.  Since I have a 4k monitor, I can choose 1920x1200 for the VNC resolution.  A previous VM creation was left at 640x480 which is extremely inadequate.  Once all choices are made for how the VM is configured, click the Create Virtual Machine button.

The situation with an already existing Virtual Machine which now has the wrong iso attached and a different iso needs to be used is not a difficult problem to solve but it is a bit different than how it was done at the beginning.  Once the host machine has the file, go to the storage tab, then to the right, where it shows the ZFS volume, above that, click the new button.  The box for name that shows "DB Storage" can be filled with the actual file name, or something simpler but its a good idea to give it the iso suffix if it is an iso file.  Choose Import from the type dropdown, Image from the Disk type dropdown, select the correct filename in the ISO/Image dropdown, choose AHCI CD-ROM from the Emulation selection, and if this is for a first boot install, give it boot order number 0.  If it complains, try again after making any other changes needed, such as to detach an old iso.

Under 'Data Center' is our host machine, mine is 'ichigo', and below 'ichigo' is my 'gentoo' Virtual Machine.  To the right of the highlighted 'summary' box, is the start button.  I click the start button to activate the VM configured for gentoo with the installer iso starting first.  Now I have the gentoo video to follow for all the necessary steps.

Setup and Install for a bootable Gentoo

What I see is slightly more graphical and failing to choose quickly enough gives me the default and same choice as in the video.  For this gentoo install, internet access is required so choosing not to wait for setting up the switch is a good idea.  After a quick boot and accepting the default keymap, I can verify internet as was done in the video.

One of the first things that is done is to identify the hard drive with lsblk, it should be sda just like in the video, but if you mistakenly fail to set the installer iso as an ahci CDROM, your virtual HDD will show up as sdb.  This is not a problem, everything should still work just fine but be sure to substitute sdb where the video references sda.  It may just be simpler to shutdown the virtual machine to fix the iso designation.

When following along with using fdisk, and he says how the second value is the size.  If you are listening, it is not mentioned, but what is shown on the screen is a prefix of the plus sign (+) so when he says to set one gig for the size, you type +1G.  Making the rest of the partitions is simple, just follow your plan which may coincide with what is said.  I chose to include a swap and home partition, so mine was 1G, 9G, 2G, 20G, although the last partition is easy with fdisk, just choose the defaults which becomes what is remaining on the virtual HDD.  I tried cfdisk following a different video, and either cfdisk has problems or I did something wrong somehow, so I went to the other video and discovered fdisk was explained.

What I missed including when this blog post was published, although included in the video that I followed, are details about fdisk, we begin with the very first command.
fdisk /dev/sda

Once in the program, we type m for help and we list what we have by typing i, and then we create an empty gpt partition table with g.  Our next step is to type n to create a new parition.  We accept the default for partition 1, and accept the next value for the first sector, and then we type +1G for the efi partition. The remaining partitions are created the same way.  Remember to type p after each change to be sure you get what you wanted.  Before the partitions are all written, they can be deleted easily to fix a mistake such as forgetting + or G or both.

We next create the efi filesystem, mkfs.fat -F 32 /dev/sda1 and once that is created we create the home and root filesystem with mkfs.ext4 /dev/sda2 and mkfs.ext4 /dev/sda4 and swap is set with mkswap /dev/sda3

If for some reason you are not already root, your prompt shows a $ instead of a #, then what you need to do is sudo su which is not mentioned in the video but is necessary for the next step.  I agree, it seems weird that the previous steps could be done without root but the next one needs it.

He explains how to make a new directory like mkdir -p with the gentoo equivalent, mkdir --parents /mnt/gentoo to create a mount point for our root filesystem to be able to install files upon it. And then we attach the root partition to the mountpoint with mount /dev/sda4 /mnt/gentoo.  The df -h command shows how my virtual filesystem looks:

Filesystem  	Size	Used	Avail	Use%	Mounted on
devtempfs   	 10M	   0	  10M	  0%	/dev
tmpfs       	472M	   0	 472M	  0%	/dev/shm
/dev/sr0    	989M	989M	   0	100%	/run
/dev/loop0  	859M	859M	   0	100%	/run/rootfsbase
LiveOS_rootfs	472M	1.2M	 470M	  1%	/
efivarfs    	256K	 20K	 232K	  8%	/sys/firmware/efi/efivars
/dev/sda4   	 20G	 32K	  19G	  1%	/mnt/gentoo

There is mention of going to a new tty to be able to do multiple things at once.  With sylve there is a small tab along the left edge of the terminal window at the middle, click on this and you will see six icons.  The one you need to be able to sent sylve the control-alt-f2 is by using the box with an A.  Clicking on that icon will open another panel with control, alt, windows, tab, escape, and ctrl-alt-del.  Click on the control and then the delete, then press your F key to open the new tty.  Deselect the control and alt keys in the panel to clear their use.

After the stage3 tarball is downloaded using links from the gentoo site in the gentoo vm, the command to untar it properly is somewhat hidden but can be found on in the gentoo handbook wiki for the stage install.
tar xpvf stage3-*.tar.xz --xattrs-include='*.*' --numeric-owner -C /mnt/gentoo

Once its all done unpacking, we set the compile flags to help speed up that process when software is built.  Either use nano or vi, both are available, but as he says, be sure to edit the correct file location.  Use the path ./etc/portage/make.conf from within /mnt/gentoo which is where your cwd should be after the untar was completed.  The changes to the make.conf file are meant to improve compile time but one addition, candy, adds a small animation while a process like emerge is running.  I changed or added all the lines mentioned.

COMMON_FLAGS="-march=native -O2 -pipe"
FEATURES="candy parallel-fetch parallel-install"
MAKEOPTS="-j4"

In the video it is mentioned that we need to create the repos.conf file.  We do this my creating a directory and making a copy of it inside.
mkdir --parents /mnt/gentoo/etc/portage/repos.conf
cp /mnt/gentoo/usr/share/portage/config/repos.conf /mnt/gentoo/etc/portage/repos.conf/gentoo.conf

It is also necessary to copy DNS info so that our chroot will have internet access.
cp --dereference /etc/resolv.conf /mnt/gentoo/etc/

Next we need to make the live iso accessible for the later installations that are done from a chroot into the unfinished install.  It is a crazy bunch of mounts and a sort of control or flow instruction to help maintain access into the chroot environment.  I am only guessing now at exactly what this does but I think its something like that.

mount --types proc /proc /mnt/gentoo/proc
mount --rbind /sys /mnt/gentoo/sys
mount --make-rslave /mnt/gentoo/sys
mount --rbind /dev /mnt/gentoo/dev
mount --make-rslave /mnt/gentoo/dev
mount --bind /run /mnt/gentoo/run
mount --make-slave /mnt/gentoo/run

We enter the chroot with a simple command which seems to also choose our shell.
chroot /mnt/gentoo /bin/bash

Next we fix our prompt, first we source what is in our profile, then we modify it to help us see (remind us) we are in a chroot.
source /etc/profile
export PS1="(chroot) ${PS1}"

The important step after that is to mount the filesystem, each partition, one at a time.  Warning, it seems that the efi partition is not mentioned in the video, so I believe first we make a new directory in the chroot, and then we mount the boot partition to the /efi directory, this is what the handbook wiki describes, but mounting /boot is for BIOS or legacy (non-efi).

mkdir /efi
mount /dev/sda1 /efi
mount /dev/sda2 /home

Before anything more is installed, we need to do the equivalent of initializing the ports tree on FreeBSD, we fetch a current snapshot with one simple command.
emerge-webrsync

In the video, he mentions how it is described to set the best mirror, this cannot be done until after the emerge-webrsync populates the emerge database.  The tool allows for multiple mirrors to be selected, possibly nearer ones than would otherwise be default.
emerge --ask --verbose --oneshot app-portage/mirrorselect

I selected this long command from the gentoo handbook wiki and then remembered the clipboard icon on the panel I saw when I had used the other keys icon.  I was successful with pasting it into the window that opened for the clipboard, but the text is white on a white background and so it remained invisible until I did a select all first control-a which didn't work, and again with the mouse and I saw the text, but unfortunately it didn't work at all as I hoped.

What we get with the eselect news read is something like our /usr/ports/UPDATING log, but we will only see the more recent postings. Earlier we grabbed a snapshot of the emerge database, next we need to update it to today.
emerge --sync

As a sort of shortcut for preparing the world in gentoo, there are numerous profiles that help to configure settings for how things are built or installed.  Choosing one is easy, first we check what the whole list shows us, then we set our selection to one of them and verfy it after, there is an asterisk (*) on the line of our choice.  Then after this is set, we tell gentoo to install what it describes.

eselect profile list
eselect profile set 3
eselect profile list
emerge --ask --verbose --update --deep --newuse @world

This seemed like the correct choice, generic desktop oriented configuration.  However, this ended every time in an unsolvable circular dependency.  When I switched to profile 1 and used a bit different emerge command, I finally got a successful emerge @world process result.  I believe this is because of one or both of the additional things in the command because a previous attempt using profile 1 had difficulties.
USE='-wayland' emerge --autounmask-write --verbose --update --deep --newuse @world

The first five profile options it listed.

[1]	default/linux/amd64/23.0 (stable)
[2]	default/linux/amd64/23.0/systemd (stable)
[3]	default/linux/amd64/23.0/desktop (stable)
[4]	default/linux/amd64/23.0/desktop/systemd (stable)
[5]	default/linux/amd64/23.0/desktop/gnome (stable)

After that finished, we clean up the dependencies, I think this may be like pkg autoremove on FreeBSD.
emerge --depclean

In the video, nothing is removed but since I had to do things a little differently, there are five things removed.  It looks like two were different (older) versions, and at least two, maybe three, possibly all of them were because I used the mirrorselect application.  Where or why doesn't matter, they were removed and we can go on to the next step.

dev-lang/rust-bin-1.94.1
app-portage/mirrorselect-2.6.4
net-analyzer/netselect-0.4-r2
dev-util/dialog-1.3.20250817

When we get to the next step, we no longer have vi, so as nano is present, we use that to edit /etc/portage/make.conf a second time.  For those like me who do not normally use nano, we may not even have a clue how to save and exit from it.  Someone made a handy cheat cheat for nano that is helpful.  Editing the simple line is easy enough to accomplish, then a control-x will let me out, and it asks if I want to save, and then accept the given filename by pressing return.  You can bet that I will be adding vi as soon as I can if it doesn't get included some other way before we're done.  Only one short line was added to the make.conf file.
USE="-wayland -gnome -kde alsa pulseaudio"

First we need to add a new application to discover what gentoo can see related to the cpu capabilities.
emerge -av cpuid2cpuflags

What it shows me is different than what is in the video.

CPU_FLAGS_X86: aes avx2 bmi1 bmi2 f16c fma3 mmx mmxext pclmul popcnt rdrand sha sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3

We can direct the output of the command into a file I think a bit differently on gentoo than we might have done on FreeBSD but the effect is the same.
echo "*/* $(cpuid2cpuflags)" > /etc/portage/package.use/00cpu-flags

The result we can see when we cat the file is below.

*/* CPU_FLAGS_X86: aes avx2 bmi1 bmi2 f16c fma3 mmx mmxext pclmul popcnt rdrand sha sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3

Once more, we go back to edit the make.conf file, this time to add the license.  We can save a bunch of typing by going backwards in history by pressing the up arrow key, the edit was five or six commands earlier.  I agree with his perspective on licenses, not the somewhat political free versus non-free that is an arguement in Linux, so I edit to add an accept all licenses setting.

ACCEPT_LICENSE="*"

Our next task is to set the timezone, so first we list the available options, assuming America rather than Europe or Asia, Australia, but to see the whole category list, omit America from below.
ls /usr/share/zoneinfo/America

We set this in a new file we create with an echo directed into the file and it can be verified if we cat the timez file.
echo "America/Chicago" > /etc/timez

We are about halfway through the video now, and our timezone will be finalized with one more step.  He has a typo to correct, but ours in bhyve seems to already be solved with a symlink to /etc/localtime.  If it had not been, the command below is what we are told to use.
emerge --config sys-libs/timezone-data

The /etc/locale.gen is our next file edit, to be certain at least one UTF8 locale is set.  This is done by uncommenting a line in the file.  As opposed to how it is shown in the video, we will need to search for the line because it is alphabetized with no handy commonly chosen line at the top.  In nano, this is control-f for a forward search, and we get a prompt for the search term, en_US.  Another thing is different in the video compared to how we see it, there is no UTF or ISO-8859 mentioned.  Consulting the handbook wiki tells us there is a few more steps and one includes choosing UTF8 or ISO-8859 or others.  We first uncomment en_US and save the file.The locale-gen command builds and installs two UTF8 locales, C.UTF-8 and en_US.UTF-8, but there is one further step to choose locale.  We can do as he did and choose the en_US.UTF-8.  First show the options with eselect locale list and then finalize our choice with eselect locale set 4 if that is en_US.UTF-8 or your desired locale.  Verify the setting like before with eselect locale list which indicates the selection with an asterisk (*).

[1]	C
[2]	C.UTF-8
[3]	POSIX
[4]	en_US.UTF-8 *
[ ]	(free form)

I chose to copy what was shown on the handbook wiki in the video, it may be the same now but I did not verify.
env-update && source /etc/profile && export PS1="(chroot) ${PS1}"

Now we add the firmware kernel patch file, which actually involves three files for my situation.
emerge --ask --verbose sys-kernel/linux-firmware

The three packages are shown as their file and version and I believe the sort of dependency configuration that relates to it.

app-arch/cpio-2.15::gentoo USE="nls" 1,613 KiB
app-alternatives/cpio-0::gentoo USE="gnu -libarchive (-split-usr)" 0 KiB
sys-kernel/linux-firmware-20260519::gentoo USE="initramfs redistributable -bindist -compress-xz -compress-zstd -duplicate -dist-kernel -saveconfig (-unknown-license)" 608,343 KiB

The recommendation to use a binary kernel seems like the best option for me, since I am very unlikely to play with a custom or gen kernel, plus it is the most foolproof for my needs.  Once again, I had to do things a little bit different in order to finally succeed.  The command that I issued is prefixed with the USES assignment again, and there is the --autounmask-write as well.  As confusing and challenging as this is, there are messages in the feedback when things fail, that instruct me to what needs to be adjusted.
USE='>=sys-kernel/installkernel-68 dracut' emerge -av --autounmask-write sys-kernel/gentoo-kernel-bin

It seems like we are nearly done with the bulk of the preliminary 'get it to boot on its own' setup stuff, but the next step is to check the symbolic link to the installed kernel so other things can find it.  First we need to show what the kernel is that is presently in use, and then we look at what the link currently looks like, and if its correct that is done.

eselect kernel list
[1]	linux-6.18.35-gentoo-dist-bin *
ls -lah /usr/src/linux
lrwxrwxrwx 1 root root 29 Jun 27 23:59 /usr/src/linux -> linux-6.18.35-gentoo-dist-bin

We need to edit the /etc/fstab file, to be sure that all partitions are automatically mounted correctly.  My install onto four partitions for my setup means that I add four new lines.

/dev/sda1		/efi		vfat	defaults	0 2	
/dev/sda2		/home		ext4	defaults	1 0
/dev/sda3		swap		swap	sw		0 0
/dev/sda4		/		ext4	defaults	1 0

We set the hostname by simply echo VirtualGentoo >/etc/hostname and then we need to get the dhcp service, although it is spelled slightly different and I had to re-enter the correct name so that dhcpcd would be installed.  Once that is installed, we need to update the rc scripts, or as it says to add service dhcpcd to runlevel default.  For the network interface we need to add netifrc and finally configure to use the network interface itself.  The command ifconfig is the same as for FreeBSD and it gives us the ethernet interface to use, enp0s3.

emerge -av net-misc/dhcpcd
rc-update add dhcpcd default
emerge -av --noreplace net-misc/netifrc
ifconfig

We create the /etc/conf.d/net file to add the line config_enp0s3="dhcp" so that the gentoo vm can obtain an IP address.  Next we change to the /etc/init.d directory to create a symbolic link from net.lo to net.enp0s3 and then we add the interface so that it starts with default runlevel.
rc-update add net.enp0s3 default

We modify the /etc/hosts file to add our chosen hostname to the left of localhost on the 127.0.0.1 line.

Since we are setting up the root password, we must be getting close to finished with all of the initial boot requirements for the gentoo virtual machine.  It is the same command, passwd, and it should be a reasonable password though this is only a virtual machine afterall, though the conditions of the password seem outdated as it expects different characters or classes of character as a function of security while true security involves length as being most effective.  Making a password difficult for the owner to remember will promote possibly insecure ways of remembering like carving it into the frame of the keyboard.

We need to add a system logger by first choosing and installing and then adding it to the default runlevel so it will start at boot.
emerge -av app-admin/sysklogd
rc-update add sysklogd default

The cron daemon is skipped but could be added.  I agree that locate is a very useful tool, so I will be installing the gentoo equivalent, mlocate which means I may be adding an alias later so the name difference won't trip me up.  The one thing that is simpler on gentoo, which I could just as easily ease on FreeBSD with an alias, is that the command is just updatedb, but his quick test tells me that I won't need an alias since its also locate.

emerge -av sys-apps/mlocate

I might want the flexibility of secure shell into the virtual machine so I will add that to the default (boot) runlevel.

rc-update add sshd default

Just in case I will add the time synchronization tool, and then add it to boot.
emerge -av net-misc/chrony
rc-update add chronyd default

I agree with him that is would be useful to have the filesystem tools, just in case, installing them now if not already present.

emerge -av sys-fs/e2fsprogs
emerge -av sys-fs/dosfstools

Finally we reach the point of configuring the bootloader.  Since I chose to use an efi boot, the step described to ensure it functions correctly, is an adjustment to the make.conf with an echo.  And after that is set we need to add grub itself, since I did not typo to add an extra quote (") I have nothing to scrutinize.
echo 'GRUB_PLATFORMS="efi-64"' >> /etc/portage/make.conf
emerge -av sys-boot/grub

Now that everything for the boot loader is setup, we just need to finalize it with the last few steps, first the efi portion and then make the configuration.
grub-install --target=x86_64-efi --efi-directory=/efi --removable

This line seems wrong, only because in the video for an efi booted system, he named the partition /boot rather than /efi.  This line refers to a different location in the install, so this is accurate.
grub-mkconfig -o /boot/grub/grub.cfg

We are done.  The last step is to reboot, but I think I will remove the iso from the virtual machine first.  The steps I should follow are below.

exit
cd
umount -l /mnt/gentoo/dev{/shm,/pts,}
umount -R /mnt/gentoo
reboot

Hmm.  Shortly after I typed exit in the virtual machine to leave the chroot, sylve lost access to the console but the machine was still running.  I could see no way to reinitiate the console, and the only options were either shutdown or reboot.  I chose to shutdown, and so I will remove the installer iso, then see what I get when I start it back up.  Whoops, I was dumb.  In order to see more of the console, I collapsed both sidebars to the left.  Since those were collapsed, I was unable to see the console icon or anything else, which magnified the strangeness of what happened after I typed exit.  I have no way to undo what I did, so I will still remove the iso and start up to see what I get.

A simple click on the storage icon, then select the iso from the list, and choose detach and agree to the action.

Success.  Everything worked for me to boot VirtualGentoo and login as root.  Now I have an option to explore the linux side of things to see how those things work when I struggle to solve a problem with porting software to FreeBSD.

Afterthoughts

One thing I noticed while I was configuring the Gentoo virtual mashine install, was that sylve reported only 1GiB of RAM, which I was sure I had set to much larger.  Now that everything is finalized so that I am not stuck in a place that I cannot interrupt, with the vm shutdown I can modify the RAM to 40 GiB and then after I boot VirtualGentoo I can adjust the process number.  Since I gave the virtual machine 40 GiB of RAM, I can increase the MAKEOPTS="-j4" to -j16 since the rule of thumb is 2 GiB per job, which still leaves 8 GiB allocated to the VM that is unused.  Be sure to double-check your Virtual machine configuration in sylve before you commit to the long install process for Gentoo.  Certainly if I had set RAM to more than 1 GiB, all of those emerge steps would have been much speedier, even the 4 jobs I set would have been more efficient.

Gentoo is interesting.  My first install or attempted install was in a VirtualBox.  This install was much the same except for the setup, the interface, and likely the speed.  I began following a newer youtube video but felt that the older video worked fine for me and seemed more familiar with the choices or options and methods described.  My own discussion about what I did, as well as I could annotate the step by step process, hopefully will help those who wish to do the same as I just did.

It seems there is no such thing as either xlibre or true real actual vi, so I will have to make due with what is available to me.  The Gentoo wiki mentions vim and using a symbolic link to it for the same vi function.  I think I can do the exact same thing but with the better yet neovim and a symbolic link.  I am installing FVWM3 which is version 1.1.4 and is only slightly behind as I just discovered that 1.1.5 has been released.  I made my first contribution to FVWM3 just prior to this release! I doubt it could have been much smaller, just one character in one file, but it was a coordinate for an svg image.  Contributions start small, I don't know what the future holds, I am also hoping to contribute to Mudlet to make it more FreeBSD friendly or to help it build more properly for it.  I am not sure if the emerge for FVWM3 on Gentoo is working faster but I expect that it is.  Of course there is much more than just FVWM to get it up and running.  The next emerge is xinit and I will keep at it until I get this VM perfectly usable.  I still have plenty to learn.  Surely following another video (about xorg install) may grant me more success than trying to do it all myself based on what I know on FreeBSD.

About sylve

I definitely can continue to use sylve to open my virtual machine but I might consider a very bare-bones light weight web browser for the purpose, or I may use another method to access the bhyve VM for my use.  Sylve is definitely well featured for making the virtual machine setup an easy task to complete.  The clipboard feature needs to be improved, I saw white on white text and it was not a helpful tool for me the way I hoped it would be.  Sylve did not crash, it was easy enough to understand, and overall it seems to have all of the features necessary for working with a bhyve VM.

Revisit for clarity

Although I succeeded to get a gentoo VM working, when I attempted to get FVWM3 to function, I succeeded to break the install shortly after.  I took it as a learning experience and an opportunity to try to follow my blog post above to set it up again.  What I discovered were a few omissions that may have been in the video but should have been written out here too.  I have added those and a note about VM processor configuration.  I have also had a bit better luck and did not need a weird
USE='-wayland' emerge --autounmask-write --verbose --update --deep --newuse @world
command to succeed.  Also, when adding the kernel, it is somewhat simpler, I did not need the --autounmask part I wrote previously, and had
USE='>=sys-kernel/installkernel-68 dracut' emerge -av sys-kernel/gentoo-kernel-bin
instead. I am not sure if this was because I goofed and did the emerge --sync before the emerge-webrsync (which made doing the emerge-webrsync superfluous), or if it was because I avoided the install of the mirrorselect tool, or maybe even the choice of a desktop profile openrc stage3.

It is also a good idea to add ccache soon after the emerge --sync and any other things like neovim. The gentoo wiki explains how both can be configured, but especially to add ccache to the FEATURES variable in the make.conf file.