whats a secure place to store a zfs encryption keyfile for use in migrating a unencrypted root dataset into an encrypted one. Since I am using zfs-send | zfs receive I can't just specify keylocation=prompt and I can't pre-create the dataset with keylocation prompt and try to replicate the streams into it.

secure as in, temporarily stored simply for the migration then deleted

I think a tmpfs mount point is how you caould do that

sig`: yea I was thinking of that, even though it seems mdmfs is also doable?

freebsd machine to freebsd machine?

sig`: yes all drives are on the same machine

*freebsd machine

either of those would work, tmpfs or mdmfs

I would need to read more on it

but I think tmpfs would be easiest/convenient

it's not possible to migrate an unencrypted zfs pool into an encrypted pool such that one is not receiving into a child dataset? I want to migrate poolA/<root dataset and children> into poolB/<root dataset>.

noobaroo: You can snag the tarballs, unroll them, and set up various bits of configuration. You'll need to look at "gpart bootcode" if non-UEFI.

It's how I do jails, which are most of a system.

What you need for fstab and rc.conf will vary based on what you're setting up.

I've not used a jail other than what poudriere does for me

so at times I feel left out

sponix2ipfw: They can be pretty useful. You can treat them like VMs, but they're amazingly lightweight.

mason: I saw there is some type of podman support attempt going in with FreeBSD Current

haven't tried it yet though

mason Thanks

Last time I used GhostBSD for easy install, so this would be a huge jump for me

Are the tarballs easy to find?

they are on download.freebsd.org

what's this about btw? my znc log cuts off at 3.5 hours ago :\

noobaroo: but why switch from the GhostBSD installer to installing FreeBSD manually? why not use the installer?

Hi, people. I was wondering about very high RAM usage on my system. Usig Firefox, my RAM slowly fills up, even if I close it it never goes back to pre-starting it. After some hours or days it starts eating SWAP

sudo shutdown -p now

I'm looking to build a little custom freebsd repo to host 2 or 3 software packages that I can use to install onto my OPNSense (Freebsd 14) box without enabling a repo with loads of things it's been YEARS since I built freebsd packages, certainly nothing near FreeBSD 14, is there any good docs I can read to build a small package repo

ikonia, have you looked at

ikonia, have you looked at docs.freebsd.org/en/books/handbook/ports/#ports-poudriere ?

why does freebsd require real name for contrib now? jc not complaining

where have you read this?

Earlier discussion here,

I don't think this irc channel is a great source for information about the project

2.1 of the committers guide is the only part that mentions real names: docs.freebsd.org/en/articles/committers-guide/#pgpkeys

and its only really to do with gpg keys

tl;dr: per kevans, github.com/freebsd/freebsd-src/blob…NTRIBUTING.md#author-name-and-email is applicable.

"Authors that use pseudonyms will be considered on a case by case basis." under what criteria?

kerneldove: feel free to read the rest of that conversation which had discussion about it

is there a log? not sure my client was online the whole time. and shouldn't that be clarified right in the doc not in an irc buffer?

kerneldove: ah, fair, I figured you were in scrollback from the messahe

kerneldove: in that case I'd refer you to bugs.freebsd.org/bugzilla/show_bug.cgi?id=285833#c15

still not seeing the rationale tho?

i don't know why it's worded like that but in practice i think it's very unlikely a change would be rejected because its author uses a pseudonym

as in, i've never heard of this happening and there are many changes in the git log that are clearly pseudonyms

(also, i would personally be strongly opposed to rejecting a change for that reason, but it's not me who makes these policies)

ivy: this started because one committer took things a little too literally and did require it

but there's since been some clarification, we won't be accepting patches from a Shitface McGee, and this kind of conversation has a high chance of being blown out of proportion so I'm quite weary of continuing it in a scattered fashion like this (not that that's anyone's fault in particular, just async communication channels)

do we not have an rc.d milestone for 'filesystems mounted'? i notice forgejo failed to start after i moved its storage to nfs, adding 'mountcritremote' to its REQUIRE fixed it, but i feel like there shiould be a better solution there

maybe it should depend on DAEMON

kevans: do you mind if i tag you on a couple of open bridge diffs? related to what i mentioned the other day, but there's only a couple and they're all pretty trivial

oh, i was asking because of D51243 but you're already on that one

ivy: yes, please. i'll try to find time later today

shoot me a list here or on slack and i'll carve out some time

kevans: tyvm

hmm

kevans: to avoid merge conflicts, i think it's just D51600 and D51243 for now - also D51185 but that's just a doc update and i plan to land it along with D51600 as it's already reviewed

we really need D51227 and probably D51231 before 15.0, but i'll rebase those and probably merge them into a single commit later

hello there

ahoy there

hey

hello, is anywhere aware of any type of benchmark projects that are done on FreeBSD? For example outputs like this page here: wiki.freebsd.org/BenchmarkMatrix?hi…ghlight=%28%5CbCategoryStale%5Cb%29

anywhere aware I'm not

thank you