Warning: there may be occasional oddness due to css and blog edits. **remodel of posts done. Overhaul of pages (distilled) in progress 3/9

Friday, July 10, 2026

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.

Monday, July 6, 2026

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.

Frequently viewed this week