An encrypted system (with multiple partitions) using UFS filesystems

[hybridscientist]

I am trying to setup an encrypted UFS-based desktop system with 14.2-RELEASE by doing partitioning and encryption by hand in shell before running the installer.

I am not at all interested in using ZFS for a variety of reasons, including the fact that I have a single disk and my automated encrypted backups, using duplicity, are all over the network and work beautifully. I am not here to start a flame war about the merits of ZFS. You like it - that is great. I just don't see the point in a single disk desktop system that is being setup for running heavy software that will need the RAM, and I have no desire to needlessly age the disks. This is not a server, and I trust the backup system I have. Color me an undying fan of minimalism and pure functionality.

So, please focus on my question below instead of suggesting ZFS.

The problem is that after I create the EFI partition and the boot partition, followed by the remaining space as a geli container, there is no viable way to do a geli attach, followed by creating (inside the decrypted block device) separate partitions for swap, root, var, tmp and home, before returning to the installer to finish the job.

While disklabel might work after geli attach, this nice BSD feature will get removed in FreeBSD 15 as this is deprecated. I plan to use this system for at least another 5-6 years. That is why I am not doing it that way.

gpart create etc obviously don't work on /dev/gpt/ENCRYPT.eli after attaching.

Is FreeBSD not too subtly telling UFS users to migrate to ZFS even if they don't need to and have better uses for their RAM (like doing actual work) with the single disk they are working with?

On Linux, this is ridiculously easy because of LVM. But I don't know what is the equivalent in FreeBSD after the upcoming removal of bsdlabels.

Is this a reflection of the fact that the desktop isn't a target for FreeBSD? If I were running a server only system, this would make sense.

Edit: I have edited the title and the post as many responders (my thanks to everyone trying to assist) are providing links to HOWTOs with a single encrypted partition, or are assuming that I am not using the shell.

 

[adorno]

I am trying to setup an encrypted UFS-based desktop system with 14.2-RELEASE (I am not at all interested in using ZFS for a variety of reasons, including the fact that I have a single disk and my automated encrypted backups, using duplicity, are all over the network and work beautifully). I am not here to start a flame war about the merits of ZFS. You like it - that is great. I just don't see the point in a single disk desktop system that is being setup for running heavy software that will need the RAM, and I have no desire to needlessly age the disks. This is not a server, and I trust the backup system I have. Color me an undying fan of minimalism and pure functionality.

So, please focus on my question below instead of suggesting ZFS.

The problem is that after I create the EFI partition and the boot partition, followed by the remaining space as a geli container, there is no viable way to do a geli attach, followed by creating separate partitions for root, var, tmp and home, before returning to the installer to finish the job.

What's wrong with running geli on partitions created before? (Sure, your way would conceal the partitioning, but how relevant would this really be?)

 

[weberjn]

You'll have to shell out early and do the partions by hand. See these guides:

FreeBSD 10 with Full Disk Encryption on UFS Filesystem |

FreeBSD: Full-Disk Encryption + UEFI

How to install FreeBSD using a GELI-encrypted UFS root partition on UEFI.

www.c0ffee.net

Bug 281735 - Installer Auto (UFS) should offer GELI encryption

281735 – Installer Auto (UFS) should offer GELI encryption

bugs.freebsd.org

But having to enter a Geli password at boot is acceptable for a server only rebooted after freebsd-update but not for a laptop.
There I prefer to boot a non-encrypted root partition and from there unlock a data partition or reboot -r into an encrypted system:

Thread 'outerbase: install script for remote-unlockable geli-encrypted root-on-zfs'

Apr 25, 2021

Many people have wondered how to have a system with full encryption-at-rest, and be able to unlock it remotely on boot, without being physically next to the machine.

You can't really have both: If the system does an unattended boot far enough to accept SSH connections, a lot of it needs to be unencrypted (bootloader and kernel, some of userland, some home data like ~/.ssh/authorized_keys). On the other hand, if the system is fully encrypted, a passphrase needs to be entered by keyboard before the system can get going at all.

Common solutions (apart from virtualization) include...

• mtu
• Replies: 2
• Forum: Installing and Upgrading FreeBSD

• 

Also, from the first non-encrypted partition you can check (similar to Android smart lock) if your smartphone is plugged in, or reachable via bluetooth, or in presence of a know Wlan, and then go to the second partition.

FreeBSD Desktop – Part 20 – Configuration – Unlock Your Laptop with Phone

I really do not like the smart card ecosystem – probably because it will be a big PITA to setup such subsystem on FreeBSD to make it lock/unlock my laptop with a smart card – not to men…

vermaden.wordpress.com

 

[bsduck]

the fact that the desktop isn't a target for FreeBSD

... is not a fact.

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.

Is FreeBSD not too subtly telling UFS users to migrate to ZFS even if they don't need to and have better uses for their RAM (like doing actual work) with the single disk they are working with?

Why this passive aggressive tone? FreeBSD is not telling you anything, it's just that nobody has yet implemented to the installer an easy way to do an encrypted UFS install. Feel free to add this feature yourself, it would be welcome.

 

[VladiBG]

Here's an example for UEFI system. You will need to enter geli password at boot. There's TPM2 patch to store geli key in the TPM (gkut2). Look for it in github.
Select Shell to manually partition the disk during the install

gpart destroy -F da0
gpart create -s gpt da0
gpart add -t efi -a 4k -s 260M da0
gpart add -t freebsd-swap -a 4k -s 4G da0
gpart add -t freebsd-ufs -a 4k da0
newfs_msdos -c1 -F32 /dev/da0p1
mount_msdosfs /dev/da0p1 /mnt
mkdir -p /mnt/EFI/BOOT
cp /boot/loader.efi /mnt/EFI/BOOT/BOOTX64.efi
efibootmgr -a -c -l /mnt/EFI/BOOT/BOOTX64.efi -L FreeBSD
umount /mnt

kldload cryptodev
geli onetime -d da0p2
geli init -s 4096 -B /tmp/bsdinstall_boot/meta_da0p3.eli -g da0p3
geli attach da0p3
newfs -U -S 4096 /dev/da0p3.eli
mount /dev/da0p3.eli /mnt

ee /tmp/bsdinstall_etc/fstab
--
/dev/da0p3.eli / ufs rw 1 1
/dev/da0p2.eli none swap sw 0 0
/dev/da0p1 /boot/efi msdosfs rw 2 2
--

ee /tmp/bsdinstall_boot/loader.conf
--
geom_eli_load="YES"
cryptodev_load="YES"
--

exit

note:
metadata for restore will be in /boot/meta_da0p3.eli

 

[Maturin]

There is no need to ferociously defend yourself against prejudices preventavily.
Nobody urges you to use ZFS or think less of you if you chose UFS.
UFS is a great, mature, and reliable FS. Just because most talk here is about ZFS neither means nobody is using UFS, nor you have to use ZFS. On my laptop I also use UFS, 'cause I see no much sense in ZFS on a single drive system, either. Sure, ZFS's capability of doing snapshots is a nice thing, though. But if you don't have no use for it (yet), so what? UFS. System runs as good without the effort with zfs.

I don't know where you experienced what before, but in all the years I'm participated this forums I've never seen no-one looking down on anybody for no reason. Often there are arguments, of course. But I never observed somebody was decremented because of chosing its personal way. This is FreeBSD. 'Chose your own way' is the headline of what this is all about. Especially if someone is doing, or trying something extraordinary, "out of the box", the really interesting threads start; sometimes even people join the discussion I've never read before - including ideas, tipps, and tricks I'd never dreamt of.

FreeBSD is NOT a server-only-system.
It seems to me that it's not installing a GUI by default is sometimes misunderstood as it's ment for servers.
That's wrong.
It simply means FreeBSD is a multipurpose OS. That means: for servers AND for desktops AND other things.
If you think it through it makes pretty much sense, at least to me, NOT to have some GUI installed by default.
If so anybody wants to set-up a headless server, or a desktop with another GUI - yes, ~20% love KDE, which makes KDE the most popular DE. But it also means 80% don't like KDE (including me) - had to deinstall the whole rubbish directly after installation again, instead of chosing the wanted DE/WM - or none at all - in the first place.

So, relax, install your encrypted UFS-partition, which is not even remotely rocket science, and for which you'll quickly find a lot of stuff in documentations, and here in this forums, already, cause it's pretty much a very common task, at least for laptops, and ask specific if some thing is not working, and you'll get all the help you need.

Don't panic!
You're using FreeBSD. There always is a way - as long as you not lose your cool and fuck up the things.

 

[hybridscientist]

What's wrong with running geli on partitions created before? (Sure, your way would conceal the partitioning, but how relevant would this really be?)

Multiple (4, 5 if I encrypt the swap) encrypted partitions mean that everytime I boot the resulting system, I would need multiple geli attach commands. Given that needs of encryption require a single password, isn't that needlessly complicated?

Also, since I am using passphrases, it may even require the user to enter the same password 5 times (for each of the 5 geli containers) at each boot. This is pointless (not to mention, has an irritation value).

I grant that I could potentially use keyfiles, but that either exposes me to the risk of potentially rapid failure (or just loss) of a USB stick, or defeats the purpose of encryption if I store the key on an unencrypted partition (say boot).

Further, in case someday FreeBSD acquires a hibernate implementation, having a separate encrypted swap will likely add complications to the resume process.

So, subpartitions/logical partitions inside a single encrypted geli container make the most sense. But it seems that with the deprecation of bsdlabels (why?), it has become possibly impossible to do.

 

[hybridscientist]

You'll have to shell out early and do the partions by hand. See these guides:

FreeBSD 10 with Full Disk Encryption on UFS Filesystem |

FreeBSD: Full-Disk Encryption + UEFI

How to install FreeBSD using a GELI-encrypted UFS root partition on UEFI.

www.c0ffee.net

Bug 281735 - Installer Auto (UFS) should offer GELI encryption

281735 – Installer Auto (UFS) should offer GELI encryption

bugs.freebsd.org

But having to enter a Geli password at boot is acceptable for a server only rebooted after freebsd-update but not for a laptop.
There I prefer to boot a non-encrypted root partition and from there unlock a data partition or reboot -r into an encrypted system:

Thread 'outerbase: install script for remote-unlockable geli-encrypted root-on-zfs'

Apr 25, 2021

Many people have wondered how to have a system with full encryption-at-rest, and be able to unlock it remotely on boot, without being physically next to the machine.

You can't really have both: If the system does an unattended boot far enough to accept SSH connections, a lot of it needs to be unencrypted (bootloader and kernel, some of userland, some home data like ~/.ssh/authorized_keys). On the other hand, if the system is fully encrypted, a passphrase needs to be entered by keyboard before the system can get going at all.

Common solutions (apart from virtualization) include...

• mtu
• Replies: 2
• Forum: Installing and Upgrading FreeBSD

• 

Also, from the first non-encrypted partition you can check (similar to Android smart lock) if your smartphone is plugged in, or reachable via bluetooth, or in presence of a know Wlan, and then go to the second partition.

FreeBSD Desktop – Part 20 – Configuration – Unlock Your Laptop with Phone

I really do not like the smart card ecosystem – probably because it will be a big PITA to setup such subsystem on FreeBSD to make it lock/unlock my laptop with a smart card – not to men…

vermaden.wordpress.com

I am sorry if I didn't make it amply clear at the outset.

I *am* using the shell to do it by hand. Love doing it this way since it gives you full control. Problem is that it doesn't work for the reasons I described.

I read that guide you refer to. It uses a single partition for /, /var, /tmp, and /home. Not my use case. It is a very bad idea to dump everything in the same partition for so many reasons.

Relying on smartphones, bluetooth, or wlan to unlock the encryption is unrelated to my question.

 

[hybridscientist]

... is not a fact.



Why this passive aggressive tone? FreeBSD is not telling you anything, it's just that nobody has yet implemented to the installer an easy way to do an encrypted UFS install. Feel free to add this feature yourself, it would be welcome.

I wrote that here because I see thread after thread hijacked by ZFS afficianados who think it is a silver bullet, never mind the end user requirements.

I need answers relevant to the problem. Hence the borderline testy comment about possible ZFS suggestions, before they occur and the thread goes sideways. Based on responses so far, I have edited my original post (and title). I would appreciate it if you could give some helpful pointers. That bsdlabels are now deprecated is creating a serious complication because it was the most logical way to do what I am trying to do.

I am not looking for *easy*, since I am (and prefer) doing all this in the shell before launching the installer. I am looking for *possible*.

 

[hybridscientist]

Here's an example for UEFI system. You will need to enter geli password at boot. There's TPM2 patch to store geli key in the TPM (gkut2). Look for it in github.
Select Shell to manually partition the disk during the install
View attachment 21363



note:
metadata for restore will be in /boot/meta_da0p3.eli

Your example above uses a single partition (da0p3) for everything. Not my use case.

Using a single partition for /, /tmp, /var, /home is a very bad idea. Further, your swap is unencrypted. Granted that FreeBSD doesn't have a hibernate implementation in the current version, but in case it develops one, that will by itself defeat the whole point of encrypting anything, as anyone with physical access to the system will simply read the contents of the RAM saved to the swap partition while the system is in a supposedly secure S4 hibernate state.

 

[ralphbsz]

Color me an undying fan of minimalism and pure functionality.

The highlighting above is mine.

Seriously, what type of attack are you trying to guard against? Encryption of data at rest (on disk) on a home system is of very dubious value. You think if a burglar comes to your house, they will steal the hard disk? On a laptop that you might lose at a coffee shop, encryption may have some value; but there it needs to be really well integrated into more complex things, for example making sure that an attacker can't get into the system while it is running, or can't restart it from sleep or hibernate.

If all the above is just an intellectual exercise ... well, then carry on.

 

[hybridscientist]

The highlighting above is mine.

Seriously, what type of attack are you trying to guard against? Encryption of data at rest (on disk) on a home system is of very dubious value. You think if a burglar comes to your house, they will steal the hard disk? On a laptop that you might lose at a coffee shop, encryption may have some value; but there it needs to be really well integrated into more complex things, for example making sure that an attacker can't get into the system while it is running, or can't restart it from sleep or hibernate.

If all the above is just an intellectual exercise ... well, then carry on.

Thanks for not answering the question, and descending to name calling.

Yes, some of us have sensitive data, and yes, our encrypted backups are adequate. Hardening a workstation against someone stealing the disk and walking off with data is a sensible precaution. And no, I don't have to explain all the details of the use case to you as I may not be at liberty to tell you.

In any case, trying to question an experienced user about why he or she wants a certain capability instead of either saying a) this is how you do it, or b) it is technically impossible, is diversion of a thread from the technical question.

If you are curious, send me a direct message instead of making the forum unhelpful for the next user who needs a solution, by filling it up with noise. Or you can start another thread about philosophy of encryption itself. Why hijack this one?

 

[monwarez]

Multiple (4, 5 if I encrypt the swap) encrypted partitions mean that everytime I boot the resulting system, I would need multiple geli attach commands. Given that needs of encryption require a single password, isn't that needlessly complicated?

Also, since I am using passphrases, it may even require the user to enter the same password 5 times (for each of the 5 geli containers) at each boot. This is pointless (not to mention, has an irritation value).

You just need to put all your geli devices in the same groups, see the usage of geli_groups in /etc/rc.conf.

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"

As for a valid reason for encryption at rest, there is an obvious one: recycling your hard drive. You just do a single wipe and you can be mostly sure that nobody would take the time to try to recover from it and to break the encryption.

Also for the swap, you usually use onetime keys. But of course by default, if you encrypt your swap, then you cannot get the kernel dump easily.

 

[VladiBG]

Your example above uses a single partition (da0p3) for everything. Not my use case.

Using a single partition for /, /tmp, /var, /home is a very bad idea. Further, your swap is unencrypted. Granted that FreeBSD doesn't have a hibernate implementation in the current version, but in case it develops one, that will by itself defeat the whole point of encrypting anything, as anyone with physical access to the system will simply read the contents of the RAM saved to the swap partition while the system is in a supposedly secure S4 hibernate state.

Why did you say that the swap is not encrypted?
You can create multiple partition and store they geli keys in the root.

 

[hybridscientist]

There is no need to ferociously defend yourself against prejudices preventavily.
Nobody urges you to use ZFS or think less of you if you chose UFS.
UFS is a great, mature, and reliable FS. Just because most talk here is about ZFS neither means nobody is using UFS, nor you have to use ZFS. On my laptop I also use UFS, 'cause I see no much sense in ZFS on a single drive system, either. Sure, ZFS's capability of doing snapshots is a nice thing, though. But if you don't have no use for it (yet), so what? UFS. System runs as good without the effort with zfs.

I don't know where you experienced what before, but in all the years I'm participated this forums I've never seen no-one looking down on anybody for no reason. Often there are arguments, of course. But I never observed somebody was decremented because of chosing its personal way. This is FreeBSD. 'Chose your own way' is the headline of what this is all about. Especially if someone is doing, or trying something extraordinary, "out of the box", the really interesting threads start; sometimes even people join the discussion I've never read before - including ideas, tipps, and tricks I'd never dreamt of.

FreeBSD is NOT a server-only-system.
It seems to me that it's not installing a GUI by default is sometimes misunderstood as it's ment for servers.
That's wrong.
It simply means FreeBSD is a multipurpose OS. That means: for servers AND for desktops AND other things.
If you think it through it makes pretty much sense, at least to me, NOT to have some GUI installed by default.
If so anybody wants to set-up a headless server, or a desktop with another GUI - yes, ~20% love KDE, which makes KDE the most popular DE. But it also means 80% don't like KDE (including me) - had to deinstall the whole rubbish directly after installation again, instead of chosing the wanted DE/WM - or none at all - in the first place.

So, relax, install your encrypted UFS-partition, which is not even remotely rocket science, and for which you'll quickly find a lot of stuff in documentations, and here in this forums, already, cause it's pretty much a very common task, at least for laptops, and ask specific if some thing is not working, and you'll get all the help you need.

Don't panic!
You're using FreeBSD. There always is a way - as long as you not lose your cool and fuck up the things.

Thanks.

I am asking for pointers at the point where I am currently stuck. I have decades of experience with Unix like operating systems but admin experience only with Linux, specifically with Debian and Slackware.

I don't care much one way or another about people who leave name calling as their business card as has happened in this thread. However, preventing a highly likely source of thread hijack is sensible IMO. It keeps noise at minimum.

I would appreciate it if you could focus on the question posed as a pointer there would be the most helpful thing going forward from someone more well versed in FreeBSD admin than I currently am.

 

[hybridscientist]

Why did you say that the swap is not encrypted?
You can create multiple partition and store they geli keys in the root.

My bad. I missed the geli one-time command for da0p2. However, that creates a second container to worry about.

I have responded to another person on this thread about why multiple geli containers isn't the most logical choice.

 

[hybridscientist]

You just need to put all your geli devices in the same groups, see the usage of geli_groups in /etc/rc.conf.


As for a valid reason for encryption at rest, there is an obvious one: recycling your hard drive. You just do a single wipe and you can be mostly sure that nobody would take the time to try to recover from it and to break the encryption.

Also for the swap, you usually use onetime keys. But of course by default, if you encrypt your swap, then you cannot get the kernel dump easily.

Intriguing. I will need to read up more on this. Would this work with a user supplied passphrase to unlock the partition that contains the keys?

I have a single disk, so a geli backup may not be sensible for me. My backup strategy is network based with encrypted chunks, using duplicity. I dry run the restore once in a month as a cron job on an unused disk to ensure that the backups are fine.

 

[VladiBG]

My bad. I missed the geli one-time command for da0p2. However, that creates a second container to worry about.

I have responded to another person on this thread about why multiple geli containers isn't the most logical choice.

Start by reading the geli(8). The onetime encrypted geli is temporary and you are not asked to provide any password when you attach it.
Did you try to create multiple geli partition and store they keys into the first /boot partition which is encrypted with password? In this way you will be asked only to decrypt the first partition and all other will have access to they keys.

 

[T-Daemon]

Multiple (4, 5 if I encrypt the swap) encrypted partitions mean that everytime I boot the resulting system, I would need multiple geli attach commands. Given that needs of encryption require a single password, isn't that needlessly complicated?

Also, since I am using passphrases, it may even require the user to enter the same password 5 times (for each of the 5 geli containers) at each boot. This is pointless (not to mention, has an irritation value).

If the geli(8) providers are initialized with the appropriate option, the passphrase only needs to be entered once to decrypt all providers, no need to group geli(8) devices to decrypt them with keyfiles.

Here an image of the loader, before the boot menu is loaded, asking for the geli(8) passphrase, when entered (once), decrypting all providers.

Steps: Create the partition table, initialize all geli(8) providers with the -g option (this option enables booting from encrypted root filesystem).

Partition table example:

Label  Device Name
efi    ada0p1
swap   ada0p2
root   ada0p3
home   ada0p4
var    ada0p5
tmp    ada0p6

Initialize the providers:

 # geli init -g  -l 256 -s 4096 ada0p3 ada0p4 ada0p5 ada0p6

Or use GPT label:

 # geli init -g  -l 256 -s 4096 gpt/root gpt/home gpt/var gpt/tmp

[EDIT] Tested in a VM, apparently GPT labels don't work here. [/EDIT]

Attach providers:

 # geli  attach  ada0p3  ada0p4  ada0p5  ada0p6

Create filesystem. newfs(8) -U is default from 14.2 upwards. If you want soft updates journaling, add the -j option.

Mount all providers, create loader configuration and fstab, exit shell:

 # mount /dev/ada0p3.eli /mnt

 # mkdir  /mnt/home  /mnt/var  /mnt/tmp

 # mount /dev/ada0p4.eli  /mnt/home
 # mount /dev/ada0p5.eli  /mnt/var
 # mount /dev/ada0p6.eli  /mnt/tmp

Edit /tmp/bsdinstall_boot/loader.conf
 geom_eli_load="YES"
 cryptodev_load="YES"

Edit /tmp/bsdinstall_etc/fstab

 # exit

 

[hybridscientist]

If the geli(8) providers are initialized with the appropriate option, the passphrase only needs to be entered once to decrypt all providers, no need to group geli(8) devices to decrypt them with keyfiles.

Here an image of the loader, before the boot menu is loaded, asking for the geli(8) passphrase, when entered (once), decrypting all providers.

View attachment 21366

Steps: Create the partition table, initialize all geli(8) providers with the -g option (this option enables booting from encrypted root filesystem).

Partition table example:

Label  Device Name
efi    ada0p1
swap   ada0p2
root   ada0p3
home   ada0p4
var    ada0p5
tmp    ada0p6

Initialize the providers:

 # geli init -g  -l 256 -s 4096 ada0p3 ada0p4 ada0p5 ada0p6

Or use GPT label:

 # geli init -g  -l 256 -s 4096 gpt/root gpt/home gpt/var gpt/tmp

[EDIT] Tested in a VM, apparently GPT labels don't work here. [/EDIT]

Attach providers:

 # geli  attach  ada0p3  ada0p4  ada0p5  ada0p6

Create filesystem. newfs(8) -U is default from 14.2 upwards. If you want soft updates journaling, add the -j option.

Mount all providers, create loader configuration and fstab, exit shell:

 # mount /dev/ada0p3.eli /mnt

 # mkdir  /mnt/home  /mnt/var  /mnt/tmp

 # mount /dev/ada0p4.eli  /mnt/home
 # mount /dev/ada0p5.eli  /mnt/var
 # mount /dev/ada0p6.eli  /mnt/tmp

Edit /tmp/bsdinstall_boot/loader.conf
 geom_eli_load="YES"
 cryptodev_load="YES"

Edit /tmp/bsdinstall_etc/fstab

 # exit

Thanks for a very detailed response. The information regarding geli passphrase being needed just once is useful

However, this method will make it very difficult to subsequently resize the partitions if needed, wouldn't it?

 

[T-Daemon]

However, this method will make it very difficult to subsequently resize the partitions if needed, wouldn't it?

It depends how you define difficult.

The process essentially consists of deleting a partition and extending the preceding partition into the free space.

geli(8) provider are capable of automatically expanding when the provider grows, which eases the process. This option is on by default (see "init -R" option for details).

Example information from geli(8) providers:

 # geli list | grep -e name -e Flags
Geom name: nda0p3.eli
Flags: BOOT, GELIBOOT, AUTORESIZE
Geom name: gpt/swap0.eli
Flags: ONETIME, W-DETACH, W-OPEN, AUTORESIZE

Taking the example partition table from post # 19

Label  Device Name  Size
efi    ada0p1
swap   ada0p2
root   ada0p3
home   ada0p4       400GB
var    ada0p5       200GB
tmp    ada0p6

suppose the home partition requires an additional 100 GB. "var" remains with 100GB.

- backup /var
- umount -f /var
- gpart delete -i 5 ada0
- gpart resize -i 4 -s 500g ada0
- growfs /dev/ada0p4.eli

- gpart add "var" partition, geli -g ... -B /path/to/var_backup/var/backups/ada0p5.eli ada0p5, attach, newfs, mount, restore from backup.

“Shrinking" a provider is done in a similar way: backup, delete, restore

If it's possible, I suggest to practice in a virtual machine before operating on the target machine.

HAPPY NEW YEAR TO ALL