deimosBSD: if you like ipfw, you might be interested in a primer i wrote for it a few months ago.

enjoy :-)

Guys, any way of testing a geli password on a running machine (/ and swap are encrypted)? I don't remember which of my like 50 passwords I used to do the disk encryption.. :) so ideally I'd like to find out which one it is before I do a reboot and have half an hour downtime guessing the password.

Onepamopa: you can backup data from these partitions before reboot

I know I can. There's not much to backup, it's a production server with a few services running.

So, there's no way to test passwords?

The F-ing chatgpt gives me geli attach -n -j /dev/stdin /dev/ada0p3  (-n without an argument) to do a "dry-run" without creating an .eli but from what I see on man geli ... that doesn't seem to be the case, at least according to the man..

don't trust chatgpt with your data

or with anything for that matter …

That's exactly why I asked here first...

you could try to change the password. it should ask you to give the current one before allowing to change to a new one ( from: forums.freebsd.org/threads/verifying-password-for-geli.58634 )

also found -C (dry-run)

chatgpt is endless source of false information that feels strangely true

btw, the encryption was done manually (UFS, not ZFS via the setup)

since the encryption is geli, the filesystem will not matter for this (imo)

dry-run only seems to work for `geli attach`, but it checks the password and informs if it's wrong. it did so for me with a wrong password (but currently can't test with the correct one)

So, geli attach -C -n 1 -j /dev/stdin /dev/ada0p3  should work for testing the password

(-n 1 because the key is 0x01 according to geli dump)

i lmfao'd when it told me who my parents are, gave a source too but there was nothing like that on that page!

lol :)

so why using it for geli...

I was waiting for a response here, so I decided to "give it a shot"

Wasn't about to do what it told me tho ..

how's 14.4 looking?

is beadm still something that i can use to create boot environments for rolling back?

Macer yes, but also make sure you have an updated boot archive.

bootadm list-archive

it's a fresh install. i haven't really done much to it yet. i'm just prepping it to use cbsd on it for jails/vms

yeah, beadm is still and will continue to be well-supported

xv8: did you mean beadm?

i don't see a bootadm

let me take a look at wiki.freebsd.org/BootEnvironments

Macer oh gosh, forgive me, I thought I was in the #solaris channel xD

Waking up and giving advice uncaffeinated is not recommended.

lol

Solaris, FreeBSD, same thing really... at least filesystem wise >:)

a piece of me is wondering if it would be possible to just zfs send the proxmox zvols of VM vdisks over and run them in bhyve untouched.

i'm pretty sure proxmox doesn't do anything special to them. they're just raw disk zvols.

why not try? :P

whats the worse than could happen, you have to zfs send them again?

i can't yet. no disks in the freebsd server yet

but i did manage to get freebsd on the ancient supermicro 1u in that picture. i had a hard time of it since i'm using usb drives connected in the two internal usb ports (on the motherboard) for booting freebsd and after the install finished it took like 10 minutes to shut down.

maybe flushing the usb drive cache? not really sure. i attempted to re-install like 4 times and this time waited at the end to see if it would eventually shut down.

probably

sync &

that's still valid command

so beadm looks pretty straighforward, but do you have to reboot for the new be to accept changes?

ie: you're still making changes to default until you reboot?

Seems like N = now and R = reboot?

seems so

Macer: we have bectl(8)

doh!

yeah.. lol

let me give it a read

beadm was deprecated, right?

I just set this up a week or two ago and it was my first time with boot environments

i really wish this 1u didn't take like 5 minutes just to post. i need to take a hard look at the bios and see if i can speed that up at all.

wip_01 NR / 1.80G 2025-05-21 08:49

nice

beadm doesn't give you a menu on boot does it?

i didn't have the ipmi console open when i reboot

IIRC, if you've more than one BE, you should see an option at the bootloader

#8 I think

i see. let me reboot and take a look

ah it sure does. nice.

though, fun fact: the BE is kinda only a suggestion, as I got myself into a situation where the bootloader was properly showing the BEs and letting me apparently boot into them, but FreeBSD was grabbing completely the wrong disk for the root FS

the 'old' root FS was on another disk and wasn't even ZFS

hi, i'm seeing a weird thing on freebsd

if i compile something that uses std::thread on linux it also pulls in -pthread

on freebsd it does not and i have to add it manually

i don't understand why it's required

this is with -static btw

so surely since i'm touching thread stuff it should pull in all the pthread, no?

what's a good filesystem to share between freebsd and linux (' ^ ' )?

ext2fs

Probably depends on what kind of storage medium it is. For large drives with file structures where UNIX permissions are important, ZFS might work, the implementation used on FreeBSD is also available for Linux

Granted, it's not shipped by default on Linux because of licensing concerns

oooh

... and actually moving a drive between those two systems is rather annoying, as you have to export it / import it each time

(a ZFS drive, that is)

how about xfs

unwrapped_monad: check what fuse fs are available, or use an nfs share?

DaliborFox: is linux just going to go forever without zfs then?

unwrapped_monad: I use ZFS even on USB disks, to share data between MacOS, Linux, Windows and FreeBSD. Works great! FAT32 is very common too, which what I used before.

johnjaye: Ubuntu ships it, NixOS ships it(with rootfs abilities) but yes it's not allowed in the kernel directly without a license change, which has roughly a 0% chance of changing.

probably the most annoying part about FAT32 is the 4GB file limit. Back in the 90s, it was no issue, but nowadays, you can't even store an uncompressed DVD image on that

I think exfat got rid of that limitation? Do we support exfat?

looks like it's in ports as FUSE: /usr/ports/sysutils/fusefs-exfat

so to get the ball rolling i'm going to put one 8TB platter in and set up mountpoints and add a mirror later. i'd have to create it as a stripe for now right? then just add a disk to the vdev as a mirror later?

zie: i'll try sharing a zfs partition (⁠◍⁠•⁠ᴗ⁠•⁠◍⁠)

just beware that ZFS is more than just a filesystem, which means there's a bit of a learning curve to all of the tools and such

since it's also a software raid solution

ooh (⁠・⁠o⁠・⁠;)

unwrapped_monad: Good Luck! If it's a network share, it will be NFS or SMB(via samba) probably. Otherwise you have to do the export/import thing to physically move the disk between machines.

well that wasn't good lol

i think my sloppy method of migrating unwanted zfs datasets off the usb boot drives was not the best way to go about doing it

hopefully they pop back up when it reboots

oh yeah. that's totally broken now

guess i'll have to pull that thing out and start from scratch. i don't think there's really any recovering from it

lattera: congrats ! I have just read about this cool initiative !

mzar: thanks!

i really wish the fbsd installer gave you the option to create secondary pools and ask if you'd like to create mountpoints. ie: if you use usb drives or maybe smaller nvmes to boot but want to put the meat of fbsd on SSDs or platters

seems like the only way to do that is to either use the advanced partition section which really doesn't help for that or drop into a shell after install and do a lot of manual work for it

in my case i'm booting from mirrored usb drives but want /usr et al on a mirrored platter pool

Macer: you can create pools by hand, install bootloader and extract kern and base

so it's completely supported

yeah. i managed to get it going and i get that it's supported. but it definitely takes a lot more elbow grease than being an option in the installer

neat

in my case i just let the installer install on the usb drives then set the mount points by hand after sending /usr over to the new pool

the only option in the installer that's automated is using disks in whatever vdev method you choose and it's all or nothing without an option to create more than one pool to change mountpoints. like there should probably be a boot/root pool and data pool option in the installer for that

so i have a single disk pool and i want to take that single disk and add another drive to mirror it.. that should be zomething like zpool add pool mirror gpt/disk1 gpt/disk2 right?

do i have to force that since it's in an active pool?

oh i guess you just have to attach it. haven't done that in quite a while.

I read that and knew something was wrong because the add command cited was adding two disks not one.

yeah. i just had to attach it to the existing disk. i have a mirror now.

Woot! \o/

i just dug up 2 8TB platters to give this a go

what happens if i replace disks with disks that are too small. like for instance i find cheap 8TB SSDs and want to just swap them out?

but they're slightly smaller or something

does zfs have any tolerance for that sort of replacement?

i want to give cbsd a spin to see how well i can run jails and VMs

You can change to larger data slices. You can't change to smaller data slices.

You have a bucket that is full. You want to put it into a smaller bucket and use the smaller bucket. What do you do with the water that does not fit?

what if the bucket is only 1/3 full though? :)

i guess i can swap out the 8TB for 10TB SSDs if that ever becomes a thing

Let's assume the feature you want worked. At some point you would need to have both the old large disk and the new small disk online at the same time to do the copy. Which means that you can simply create a new array using the small disks as you want, mount them up ("import" them), and then simply copy the files. And by copy I mean "zfs send|recv" the datasets.

figured if the disk was larger then zfs autoexpand would kick in and eat up the larger size

i thought a way to do it if you wanted to grow was to replace each disk one by one with larger ones and it will fill the space on the last resilver depending on the vdev

yeah going smaller. yeah i can see that being an issue. i was just curious if zfs had any tolerance to a disk being a little smaller. for instance the difference in size between a platter an SSD where it's like 1GB smaller because of some manufacturing nonsense

You can GROW the disks to larger ones. But you said "what happens if i replace disks with disks that are too small

i guess they're supposed to be "the same size" but i can see something being slightly smaller

At one time in the far distant past it was typical use the entire raw disk for one of the zfs devices, for various reasons. But now I will just state that the best practice is to partition disks with GPT partitions, add GPT labels to the partitions desired, and then use the partitions for zfs devices. That's best.

Doing that means that partitions used for zfs will always be slightly smaller than the entire disk. The partitions should always be aligned. And then you will have some slop factor available.

I have a bunch of FreeBSD machines. I ssh into them from a Mac laptop. There is one machine the connection stays up forever. There are some other machines that I notice they all seem to lose their ssh connection and I have to log in again. I notice the machine that keeps its connection is 12.1 and the others are like 14.1. I looked in /etc/ssh/sshd_config but didn't see anything different, any suggestions?

Macer you can drop into a shell before the install and manually create and mount zfs partitions as you'd like them to be and then exit the shell and continue the unzip part of the install and post configuration. I do that all the time as I just want one large partition with all of FreeBSD installed clean including the /var directories. I just keep my homes directory separate and reuse that from install to install

crb, My first thought is that the connection between drops such as due to a NAT table timing out or something. I always set ServerAliveInterval 200 to keep a keepalive/makedead running. Maybe??

rwp: machines on both sides are inside the firewall so I doubt it's NAT

rwp: I don't see that option in either the machines that drop connection or the one that doesn't

"man ssh_config" look for ServerAliveInterval

Also check /var/log/auth.log and see if there are clues there.

rwp: nothing in my /var/log/messages except the usual failed attempts to log in

rwp::rwp: ServerAliveInterval does not appear in man sshd_config

crb: it's in ssh_config.

as he said

you typo'd

Right! :-)

ok

since I'm ssh'ing from the same machine the same options should apply to the machines that drop and the one that doesn't if it's a client side option

have cbsd working but that took some doing as well considering it automagically creates zpool/jails .. not sure if there is an option to change the default pool there

or maybe it puts it on zroot because nothing else exists

not sure why it sends me to /var/empty when i just type cbsd though. i wonder if i missed something or if that's normal

cbsd sure feels a lot like smartos