What is geli polarian?

nimaje Really, an EFI partition can hold multiple boot loaders?

notably both grub and freebsd's loader support chainloading another loader

On my EFI partition I only have 1 file that is not plain-text, its called BOOTX64.EFI.

I have no idea how I would go about adding another bootloader to this same EFI partition, without creating another ESP.

right, that's the 'default' path for the firmware to load for removable media on x86, though most honor it for nonremovable as well

freebsd would create efi/freebsd and plop its loader.efi into there

you could do the same, then decide how you want to manage it: the firmware can be configured with different boot options to point to the different loader, or you can add a menu option to grub to chainload freebsd's loader

What do you mean by "firmware" ? You mean the BIOS?

yes

with uefi these are usually controlled with efibootmgr(8)

How common is it for BIOS to support multiple .efi files? (Without chainloading)

i would guess that most machines you've touched with UEFI would support it just fine

Oh yeah, ive used efibootmgr program before on Linux. But never had 2 EFI entries on one EFI partition before.

another option to consider is rEFIn

rEFInd

it can be used to manage selection of different loaders on an ESP, which may be a bit better since firmware options may need to be re-done on, e.g., firmware updates

rEFInd's config is either on the ESP itself or autodiscovered, I don't recall which offhand

Okay, so if you're saying that firmware options might need to be redone on updates, you must be talking about a way of putting an EFI entry into the BIOS the permanent/persistent route that stays visible in efibootmgr(8) even with the drive unplugged

My bootloader is installed the removable way. All I did was format the ESP, and then drag the BOOTX64.EFI file onto it. So if I put 2, I have no idea what would happen. I'd assume only the 1 named BOOTX64.EFI would work.

you'd use efibootmgr(8) to create a menu option that points to the other

Oh okay, thanks for specifying. Im not exactly new but I'm also not the brightest

If I use rEFInd then I don't need to create persistent entries with efibootmgr(8) right?

why in tzsetup on freebsd 14 release are there no U.S. cities ?

sig`: They're there, under America.

But IIRC the default is the US/ zone set.

are there .zfs directories on each dataset?

yes

hmm seems like no snapshots were being taken on the zroot/usr/home dataset

any caveats using dlopen on freebsd?

kerneldove, BSD is a mature system and unless things are Linux kernel specific or require something from systemd the assumption is that everything works.

ok ty

was cool to see even dlclose is supported. not all platforms support that

The best mode of operation is just to do normal things as one would normally do. If one hits something that is not working then that is a good trigger to go, hey I was trying to do X and I got this error, and then work through it.

I don't know what FreeBSD does with dlopen but I've experienced a very nasty issue due to a compiler change in GCC on Linux

The question is whether calling dlclose really does clean up everything or not

The problem we had was with a function static C++ object. If the object needs a constructor call the compiler will also create a global mutex to make sure that the C++ file static object gets created in a thread safe manner.

paulf but dlopen on freebsd works fine? or did gcc change on linux somehow spill over into how freebsd does it

I'm fairly sure that dlopen is fine. The problem is more a lack of clear specification. dlopen is POSIX (and so only covers C). C++ says nothing about POSIX. You end up with grey areas like this when you mix C++ and POSIX. Probably also other languages that have automatic object lifetime controls.

im gonna try rust but dyn link with the C ABI so that should be fine

Hi all, I'm going to RMA a drive (ada3) from my ZFS array. I'm planning these steps: zpool offline -f zroot ada3p3; dd if=/dev/zero bs=1M of=/dev/ada3; Physically replace the drive; partition the drive (gdisk(8), by reusing the same partition table as that of e.g. ada0); zpool replace zroot ada3p3 /dev/ada3p3 # ? That's it ?

moviuro, Those steps should do it. I don't think you need the offline -f as I think offline by itself will take one drive offline.

If you have the replacement drive already then it is better to "replace" the new drive as the first step.

That way it has the old drive (even if it is having some errors) for the silvering to the new replacement drive. For the blocks that can be read there is no need to compute an answer as it can simply copy the blocks. It will verify that the data is correct using zfs hash checks.

Then personally myself I would remove the device and put it in a different system for wiping. That way there is no possibility of wiping the wrong disk in the array.

Also if you do remove and wipe the drive first then I don't think you an "replace" it anymore because it is already removed but you would add in the new drive into the array. Is that "online"? I would need to look up the command but it's simple and then it would re-silver it into the array.

Since it looks like you have at least four devices let me recommend using GPT labels moving forward. The device names adaX for SATA devices are dynamically assigned and change from boot to boot. It can be confusing. Use a tool like "camcontrol devlist" or "diskinfo -v /dev/ada3" to verify serial numbers to make sure you are operating on the desired drive.

thanks rwp , I only have 4 SATA plugs I believe, but I'll check.

moviuro, I should also say that I presume that "zpool status" shows errors from that drive. If after you have replaced the drive and all is good that status shows errors you might need to clear residual errors from the counters with "zpool clear zroot". Then the counters are zeroed. Any new errors will be logged starting from zero afterwards.

At that point I would run a scrub and let it check everything. Should be good at that point.

only smartctl(8) is reporting errors. Check the log of that channel (Jul 22nd)

scrub repaired 0B in 19:29:54 with 0 errors on Tue Jul 15 20:46:54 2025

Ah... So you are getting to things before any I/O errors to the system have been reported. Gotcha.

No hurry then. I'll note that I have had drives in non-critical roles that have been reporting SMART errors for at least 3 years now (Seagate! It's always Seagate drives) and I am confident that if the drive actually fails that I have redundancy and backup okay so I am just letting it run and ignoring those SMART reports.

if i have an executable file running and i want to replace it with an upgraded version, is there anything wrong with rm the file, cp the new executable into the original path, ctrl-c the original exe, then starting the new exe at the same path?

or similarly, mv newexe originalexe (using rename to overwrite)

well, that will terminate whatever it is doing and the new executable will potentially start from the beginning, so it depends on what it is doing (what do you think how pkg upgrades stuff?)

if i overwrite an executable while it's running with another executable, it'll terminate the running executable? are you sure?

it will not

ya didn't think so

but what you are describing is not overwriting

you said you want to do ctrl-c

if I recall right, if you rm a binary that is currently running, its inodes will still be busy and they cannot be reused until they are release

d

./exe; mv newexe exe; ctrl-c (in terminal where exe is running); ./exe

inode will be removed when all of its instances are closed

kerneldove: in there you are not overwriting, you are unlinking the old one

but is the exe file not being overwritten? not trying to be dense just confused by that

cp newexe exe can cause trouble *if* you are overwriting bytes in place *and* the file is mapped to memory *and* code pages are allowed to change.

is there a safer way to do it?

kerneldove: rm exe && mv newexe exe

is POSIX and safe

but cp shouldn't override bytes in place

nimaje why?;)

Remilia oh we can rm an exe while it's running?

this isn't Windows

rm unlinks inodes

nimaje thats file system specific. with ufs it may, with zfs it never will.

because it should only affect what is addressed by that path after the copy, not already opened files

how do you think `rm -rf /` works

nimaje: I think cp and mv can overwrite open files and things can and will go wrong

though with mv it is probably between filesystems only?

(when it becomes cp and rm)

ill rm exe && mv newexe exe; ctrl-c; ./exe

when you open a file you've opened an inode. sort of like a dns record lets you access an ip. it doesn't matter if the record changes once you have it open unless you close and reopen it again. that's why you may come across things like deleting a large log file and not having any space free until you restart the app holding it's inode open.

it's also why syslog rotation often requires prodding processes

btw it is possible to 'carry over' stuff from old running process to the new one for almost seamless updates but your binary needs to support this — you exec the new binary from the old, passing environment and FDs

prone to wild breakages if you are not careful

how do you exec a new binary from the old?

kerneldove: as I said it needs to support this, and you use one of the exec() calls

passing FDs in exec is quite common in general (see postfix), this is just an extension of that practice

how can it wildly break?

how can it wildly break?

at a guess: because the old process and new process could have completely different ideas of what FDs are expected to be open and what state the environ is expected to be in

hodapp: yep

ok ty

going to guess it's akin to C/C++ software going to lengths to maintain binary compatibility between versions in their struct definitions

Just setup audio bookshelf in a jail, had to use a slightly older version but working perfectly. gemini.8by3.net/x/8by3.net/~sbr/oth…ech/2025-07-29.audio-book-shelf.gmi

I have snapshots on zroot/ROOT/default but I'm not sure how they were enabled. The com.sun::auto-snapshot property has no value on it.

I'm curious how the snapshots are getting done.

I'm running on FreeBSD 14.3-RELEASE, but the snapshots date back from 2022

noobaroo: geli is FreeBSD's Full Disk Encryption (FDE)

do all patches to freebsd have to include a a real name?

polarian: github.com/freebsd/freebsd-src/blob/main/CONTRIBUTING.md

> Do note that your name and email address will become a permanent and immutable part of the public Git history of the FreeBSD source tree. Authors that use pseudonyms will be considered on a case by case basis.

you can't use a nick for contributions?

kevans: thx

scottpedia: well I did by default

the commit that added that notes:

but I was told to redo my patch to use my real name

> Not all psuedonyms are created equal, and we may disallow a PR based on that

so I did

but a friend of mine refuses to contribute unless he can use his username

which commit / PR?

how do they verify if that's your real name?

what is considered a real name?

that's draconic. they have no right to force people using real names

Linux kernel doesn't

there's the case of trans people who identify using a different name than their legal name

i think you folks are reading too much into this

kevans: bugs.freebsd.org/285833

parai: indeed, nobody is policing for preferred names vs. 'legal' names or anything like that. if you say your name is "John Smith", sure, that's an identity

if you say your name is "Shitface McGee," alright, go away

(i'm not an authority on this matter, but I know for a fact that there are no 'witch hunts' associated with these kinds of things or whatever you might be imagining)

oh, i wasn't implying anything, sorry for the misunderstanding. it was purely a question addressed out of my curiosity

fair

i think that section in the CONTRIBUTING guide should be rewritten, as there isn't always a clear distinction between a name and a pseudonym

but that's just my opinion

i agree on not accepting commits from Mr. "Shitface McGee" or his friends

:)

what did mr shitface mcgee ever did to you!?

i think it's hard to write these kinds of things without coming off as exclusionary or negative, so he went with kinda-vague

imo it's similar to how the linux kernel won't accept anonymous contributions, we just need some kind of identity attached that will persist to some extent

kevans: so why did I need to give my real name

my patch was rejected on grounds of real name

"Polarian" is not an offensive username

I rather not reveal my real name and it has not sat well that I have given my real name to get my patch through

also in my case my username is my indentity, in many cases people will use my username instead of my real name in person (in all honestly I dont even like my real name)

an indentity can be anything which sticks with people, I get you wouldn't include some burner nickname which will likely change a week later, but for someone which keeps the same username for decades, whats the problem ?

also git commits have email addresses attached to them for a reason

polarian: imo it's a volunteer project, and it's hard to herd all of the cats in the same direction some times. I can't really offer any comfort for what's happened, but at least now you would be able to point to a document in the project repo as an appeal

that was added only four days ago or so

appeal what?

not you specifically, but future people with the same problem

'hey, we need your name' 'well, this says you probably do not -- can we talk about it?'

kevans, now you've made me curious (and interested). Which document?

CONTRIBUTING.md that I had linked before: V

My bad for not paging up.

no worries

the bit discussing pseudonyms is quite short, but it's enough to give a reasonable committer pause to maybe question their ask

i would think

mns: maybe freebsd-update created those

 

i hadn't heard about pkgbase, not understanding that'd be applying to the core system

i added myself to the mailing list to watch now =]

I need to get a hold of a bit of eth just to give status the college try and set up a node on my vps to see how that works out.

Pretty interesting stuff.

IMO at least. Not a bad use of crypto nonsense.

is there a good use of crypto nonsense

rtprio: If your laptop ends up being stolen, there's less of a chance of sensitive information being recovered if you have full-disk encryption

Still, it's good practice to reset all passwords and revoke all keys if that does end up happening

Oh, I'm silly, I misinterpreted eth as an additional ethernet interface for the VPS :P

i read 'a bit of eth' as 'a bit of ethereum cryptocurrency'

fde != eth

Yeah, that's no doubt what they meant

rtprio: it is crypto though :P At least the old meaning of the term

but yeah, unless you're a criminal, live in a country under sanctions, or enjoy gambling away your life savings, I don't really think there's much of a use to them

I guess if you live in a country with a cold climate and cheap electricity, it might be a way to sell off that electricity for a higher cost

ya

oh, php 8.4 removed imap from bundled extensions and it now has to be pecl'd…

kevans: parai bugs.freebsd.org/bugzilla/show_bug.cgi?id=285833#c15

imp has clarified it, they read my email :D

I hope this helps

especially parai

polarian: yeah, he's a reasonable person that cares that our policy is understood and followed; I was going to shoot a message to him when I got a minute, but glad to see that I don't have to =D

yeah I shot an email

I am disappointed my commit is there now

the misunderstanding means my name is now cemented into the git history

which pisses me off a lil

but at least now this is clarified others hopefully will not feel forced into it in the future :D

is your concern that it's in the repository at all, or just that it would appear via normal browsing of the repo/history?

i'd note what he mentioned about dead names; there's a mechanism in git to remap so that, e.g., `git log` would show the corrected name, but it would be enshrined in the mapping file as a consequence

kevans: lets just say I know of certain people who like to hoard personal info

ok, so overall privacy concern and remapping wouldn't really help there

my real name isnt the biggest deal, for example if you have met me at a conference you will know my name

but when it comes to online where search engines index shit

and a quick search can bring up lots of info on you

I try my hardest to keep mine as minimal as possible

yeah, that's fair

its also the fact that I dont use my real name often, so people using it is uncomfortable...

i understand (though I can't relate, since my first and last names are both quite generic)

the whole idea of a name and email on a commit is so someone can contact you and know who you are

so by that use case, I would want my username + email because thats what I go by...

imo i'd stew on it a bit and consider sending a patch to .mailmap along, might help some with damage control / maybe the trade-off is worth it

kevans: wdym send a patch to .mailmap?

a patch for what?

mapping your e-mail address to your preferred name

so that git log, etc. would show the right stuff by default

polarian: I also do not use my legal name as long as it is possible not to, haha

kevans: oh I have never heard of .mailmap before, just searched it and its a git feature...

sorry now I understand

yeah: cgit.freebsd.org/src/tree/.mailmap

this hurts my brain

nimaje: thanks will look at that so see if it does do that.

polarian: yeah, the last entry is the e-mail that appeared, some combination of the first two are optional because you can fix either e-mail or name + e-mail

polarian: thanks for the update!

kevans: so if I add Polarian <polarian⊙pd> it will change realname <polarian... ---> Polarian <polarian...

I added the ... cant be bothered to type my email out twice

polarian: that's my understanding, yes; you should be able to test it by commiting it locally and then searching through `git log --pretty=fuller`

or maybe the default was author, sorry; no --pretty

hmmm I will experiment, thanks for the suggestion

the file currently seems to just be freebsd committers, are contributors allowed to edit it?

yes

it'll get reviewed and pushed by a committer, maybe good to tag imp to give it the explicit OK in case anyone tries to hassle you

I assume this should go to... fuck whats the name

not bugs.

the other one?

you can do bugs, phab or github

which is preferred usually phab or bugs?

phab > bugs, though we're having a bit of heartburn with a phab upgrade at the moment it seems

well, not phab itself, but the system

I have heard of other projects abandoning phab now...

never used it personally

hey all - trying to recover a crash using zfs snapshots. i have partitioned disk and can zfs send/receive ok from backup server, but am having trouble getting zpool set up correctly for reboot.

jpb, can you elaborate? What happens when you try to reboot?

V_PauAmma_V: i get one of two errors on reboot: "no pools available to import" or "cannot import 'zroot': pool already exists" and i don't know what i am doing to cause either one.

rwp: actually... One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. [...] 1.41M repaired, 64.09% done, 05:46:29 to go [...] ada3p3 ONLINE 0 0 6 (repairing)

right now, i'm back to square one: newly partitioned disk and newly received snapshots.

9

...

jpb, can you pastebin the output of "zpool import" and "zpool list"?

(Not sure I'll be able to help, but these are what I'd look at if I had a similar problem.)

it sounds like jpb is trying to the running system to zfs recv snapshots of datasets, which I wouldn't think you can do for datasets that already exist on the running system, because they don't share a common ancestor with the snapshots

but maybe a separate system with a differently named root pool could mount the pool from the problem disk, destroy any datasets that need to be brought back from snapshots, and then do the zfs recv

this time around i'm going to use: zpool create -o altroot=/jpb -O mountpoint=none zroot vtbd0p3 instead of altroot=/mnt i think there's a conflict there somewhere

Don't call it "zroot"

i'm recreating my exact steps and will pastebin shortly.

Thanks.

scoobybejesus_tl: usually you'd just boot from FreeBSD install media, create an empty zpool, mount it with altroot, and zfs recv

good to know... errr... hopefully i don't find myself in that predicament! but interesting!

I tying to replicate a dataset using zrep. I have added permission to my user in the origin and destination datasets (create, mount, snapshot, send, receive,...) however I get the following error "cannot set property for 'mypool/backups/ubuntu2': permission denied" mypool is located in the destination server and later "Error: zrep_expire Internal Err caller did not hold fs lock on

mypool/backups/ubuntu2" is there any permission to allow setting permissions?

how is it connecting to the destination server?

V_PauAmma_V: ok, here is my step-by-step procedure that fails with "no pools available to import".

i'm sure it's something really, really simple that i am missing.

i'm hoping someone here has a solution.

jpb: you're restoring your whole system to a qemu?

What do you have in the restored system's /boot/loader.conf? Specifically, do you have a line reading zfs_load="YES" ?

yes, zfs_load="YES" is in the /boot/loader.conf on the (not yet)restored system.

rtprio: i'm testing getting zfs restores working with two qemu vms first, just to get my head around the procedure.

right now, my head is only three quarters around... :-(

What matters is you're learning.

usually /zroot is mounted, but it's empty?

yeah, but i'm losing my hair at a faster rate :-)

i don't think that would ruin the boot tho

> mount: /usr: unknown special file or file system

is there an fstab?

ok, i do see a discrepancy in the pastebin. /mnt is referenced in some places and /jpb is reference in others.

i'll recreate all steps with the corrections using /mnt

On the offchance that's it: in DATASETS='...' at step 80, you have a leading space on the first line. I don't think it matters since you have "zfs send $source" in that loop, so the extra space should be ignored, but if you recreate all your steps, maybe also try removing that leading space?

the shell eats extra spaces during tokenization, but i'll check it anyway.

1pkg: An error occurred while fetching package: No error

super cool, whatever this is

kevans is there a way to bootstrap FreeBSD by extracting a root tarball onto a partition? Similar to debootstrap or arch bootstrap or void bootstrap

noobaroo: daemonology.net/depenguinator