Migrating from Linux - looking to see if it's possible in my case

[AmarildoJr]

Hi there!

I'm currently on Windows for a quick 3D/VFX job, but I mainly use Linux. However, I'm seriously considering upgrading from Linux to FreeBSD, mainly because of systemd.

I'm looking for guidance on where to research the topics I need in order to make this transition possible. Here's exactly what I need:

USE CASE #1 - I have 5 storage devices:
- nvme for boot (512 GB);
- nvme for work (2 TB);
- HDD storage, for files that don't need to be in the 'work nvme' (4TB);
- two 480 GB S-ATA SSDs for miscelaneous storage that don't need nvme speeds but need to be faster than the HDD.

I encrypt everything. On Linux I usually use the default full-disk encryption schemes, which is LUKS on LVM. This leaves me with the following partition scheme:
* EFI boot partition (512 MB) unencrypted;
* /boot partition (1 GB) unencrypted;
* / partition (free space left) encrypted.

Recently somone on Linux decided that it was a good idea to encrypt GRUB as well. This wouldn't be a problem if it weren't for the fact that decryption takes 30-40 seconds, and that I need to type the encryption password twice, once for GRUB and once for the drive. I simply don't want this, so the usual scheme above is fine for me.

For the other drives, I do manual LUKS on LVM, with commands such as:
- cryptsetup -c aes-xts-plain64 -y -s 512 luksFormat /dev/sda1 (example)
- cryptsetup luksOpen /dev/sda1 4TB (example)
- pvcreate /dev/mapper/4TB
- vgcreate 4TBvg /dev/mapper/4TB
- lvcreate -l 100%FREE 4TBvg -n 4TBlv
- mkfs.ext4 /dev/mapper/4TBvg-4TBlv
- mount /dev/mapper/4TBvg-4TBlv /mnt/4TB

Then I just edit /etc/fstab and /etc/crypttab to have those devices automount on boot.
Final step is to rebuild the initramfs image.

What do you guys recommend for such setup?


USE CASE #2 - I absolutely need a GUI and the proprietary NVIDIA driver.
I do 3D for work, so sadly AMD is out of the question for now and so is the nouveau driver.
What is the best way to install the proprietary NVIDIA driver on FreeBSD? I don't need the latest, just something like v550 or above is fine.
XFCE is also fine for me.


USE CASE #3 - I need Steam for work as well, because I've purchased the Adobe Substance Painter program on there, which works on Windows/Mac/Linux.
Is it possible to run Steam on FreeBSD, while also running Linux programs/games?


USE CASE #4 - I think all other programs I need work fine on FreeBSD, like GIMP, Inkscape, some Flatpak programs, KDEnlive, etc.

Thanks for any assistance!

 

[SirDice]

I encrypt everything.

Chapter 20. Storage

This chapter covers the use of disks and storage media in FreeBSD. This includes SCSI and IDE disks, CD and DVD media, memory-backed disks, and USB storage devices.

docs.freebsd.org

Other than that, the installer can take care of encryption with geli(8) for you.

I absolutely need a GUI and the proprietary NVIDIA driver.

Install x11/nvidia-driver, which is the actual FreeBSD driver from NVidia.

I need Steam for work as well

That's honestly a bit of a hit or miss. Generally the steam client works, it's the various games and/or applications that might be problematic. This is typically due to the fact the Linux binary compatibility isn't 100% compatible.

Chapter 12. Linux Binary Compatibility

FreeBSD provides binary compatibility with Linux, allowing users to install and run most Linux binaries on a FreeBSD system without having to first modify the binary

docs.freebsd.org

games/linux-steam-utils

GIMP, Inkscape, some Flatpak programs, KDEnlive, etc.

We don't do Flatpak, but graphics/gimp, graphics/inkscape and multimedia/kdenlive are all available 'natively'.

 

[T-Daemon]

USE CASE #1 - I have 5 storage devices:

* /boot partition (1 GB) unencrypted;
* / partition (free space left) encrypted.

There is no need for an unencrypted /boot partition. The FreeBSD loader can boot the kernel from a full encrypted Root-On-ZFS [1] or Root-on-UFS [1].

geli(8)

     init       Initialize providers which need to be encrypted.
     ...
                -g                Enable booting from this encrypted root
                                  filesystem.  The boot loader prompts for the
                                  passphrase and loads loader(8) from the
                                  encrypted partition.

[1] Root-on-ZFS - If the whole disk is the installation target: the entire process is menu guided. If the target is a partial disk installation: manually (partitioning, geli provider initialization, zpool, zfs dataset creation, fstab, loader.conf creation, the rest automatically)

[2] Root-on-UFS - Full disk or partial disk installation: only manually (partitioning, geli provider initialization, fstab, loader.conf creation, the rest automatically.

Don't worry about the exact steps, there are users in this forums, including myself, who will be happy to help you, just ask for help.

Then I just edit /etc/fstab and /etc/crypttab to have those devices automount on boot.

FreeBSD provides the necessary logic to automount encrypted devices.

In both of the following options, it is assumed that the key files are located in the encrypted root file system.

Option 1, from /boot/loader.conf:

geli(8)

Spoiler

EXAMPLES

     The example below shows how to configure two providers which will be
     attached on boot, before the root filesystem is mounted.  One of them is
     using passphrase and three keyfile parts and the other is using only a
     keyfile in one part:

           # dd if=/dev/random of=/dev/da0 bs=1m
           # dd if=/dev/random of=/boot/keys/da0.key0 bs=32k count=1
           # dd if=/dev/random of=/boot/keys/da0.key1 bs=32k count=1
           # dd if=/dev/random of=/boot/keys/da0.key2 bs=32k count=1
           # geli init -b -K /boot/keys/da0.key0 -K /boot/keys/da0.key1 -K /boot/keys/da0.key2 da0
           Enter new passphrase:
           Reenter new passphrase:
           # dd if=/dev/random of=/dev/da1s3a bs=1m
           # dd if=/dev/random of=/boot/keys/da1s3a.key bs=128k count=1
           # geli init -b -P -K /boot/keys/da1s3a.key da1s3a

     The providers are initialized, now we have to add these lines to
     /boot/loader.conf:

           geli_da0_keyfile0_load="YES"
           geli_da0_keyfile0_type="da0:geli_keyfile0"
           geli_da0_keyfile0_name="/boot/keys/da0.key0"
           geli_da0_keyfile1_load="YES"
           geli_da0_keyfile1_type="da0:geli_keyfile1"
           geli_da0_keyfile1_name="/boot/keys/da0.key1"
           geli_da0_keyfile2_load="YES"
           geli_da0_keyfile2_type="da0:geli_keyfile2"
           geli_da0_keyfile2_name="/boot/keys/da0.key2"

           geli_da1s3a_keyfile0_load="YES"
           geli_da1s3a_keyfile0_type="da1s3a:geli_keyfile0"
           geli_da1s3a_keyfile0_name="/boot/keys/da1s3a.key"

     If there is only one keyfile, the index might be omitted:

           geli_da1s3a_keyfile_load="YES"
           geli_da1s3a_keyfile_type="da1s3a:geli_keyfile"
           geli_da1s3a_keyfile_name="/boot/keys/da1s3a.key"

Option 2, from /etc/rc.conf:

/etc/defaults/rc.conf

Spoiler

# GELI disk encryption configuration.
geli_devices=""         # List of devices to automatically attach in addition to
                        # GELI devices listed in /etc/fstab.
geli_groups=""          # List of groups containing devices to automatically
                        # attach with the same keyfiles and passphrase
geli_tries=""           # Number of times to attempt attaching geli device.
                        # If empty, kern.geom.eli.tries will be used.
geli_default_flags=""   # Default flags for geli(8).
geli_autodetach="YES"   # Automatically detach on last close.
                        # Providers are marked as such when all file systems are
                        # mounted.
# Example use.
#geli_devices="da1 mirror/home"
#geli_da1_flags="-p -k /etc/geli/da1.keys"
#geli_da1_autodetach="NO"
#geli_mirror_home_flags="-k /etc/geli/home.keys"
#geli_groups="storage backup"
#geli_storage_flags="-k /etc/geli/storage.keys"
#geli_storage_devices="ada0 ada1"
#geli_backup_flags="-j /etc/geli/backup.passfile -k /etc/geli/backup.keys"
#geli_backup_devices="ada2 ada3"

 

[MrBSD]

I will be brutally honest with you. Stick with linux. There are too many things that may, or may not work. If the systemd is the problem (and it is), switch to non systemd linux distro.

 

[ngnicholson]

Install FreeBSD in a virtual machine & play with it, read the handbook to see how it ticks. FreeBSD is a great OS see if it can do that you want & then install on your bare metal if it does.

 

[freezr]

If you need 3D and NVIDIA you need CUDA and other tools that are so unreliable and complicated to get working on FreeBSD that is not professionally-wise.

Use a spare laptop to play with FreeBSD, it is a great OS but doesn't have the same hardware and drivers support as Linux and Windows, unfortunately...

 

[ralphbsz]

I'm seriously considering upgrading from Linux to FreeBSD, mainly because of systemd.

Can you explain why systemd is a problem for you? All Unixes (and all other OSes too) have some sort of init, process management, and configuration system. FreeBSD's (using init, rc, and files in /etc and /usr/local/etc) is particularly simple and traditional. But it also needs to be learned, and dealt with.

USE CASE #1 - I have 5 storage devices:

From a storage point of view, ZFS is hard to beat for most use cases. It's a very good file system, which has durability and reliability built in. It particularly shines when using RAID (multiple storage devices for redundancy in a file system). It also has encryption integrated into it. It's also available as a second-class citizen in Linux, but in FreeBSD, it is built into the core (although not the only option).

But ZFS uses different concepts and different commands. So you'll have to relearn things like mkfs and mount.

USE CASE #2 - I absolutely need a GUI and the proprietary NVIDIA driver.
...
USE CASE #3 - I need Steam for work as well, ...

That where things get difficult.

That's honestly a bit of a hit or miss. Generally the steam client works, it's the various games and/or applications that might be problematic. This is typically due to the fact the Linux binary compatibility isn't 100% compatible.

I will be brutally honest with you. Stick with linux. There are too many things that may, or may not work.