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.
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.
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. 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.
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.
He explains how to make a new directory like mkdir -p with the gentoo equivalent, mkdir --parents to create a mount point for our root filesystem to be able to install files upon it. 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 stage tarball is downloaded using links 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"
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
mount /dev/sda4 /
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 locale 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 with rc-update add net.enp0s3 default so that it starts with default runlevel.
The /etc/hosts file needs to be modified to add the 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>br>
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
rebootHmm. 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.
