does anyone know sysctl tuning generator for freebsd?

a _what_?

futune: welp. I got the pool transferred onto the new drives ok, but I must've messed something up with the loader/boot sequence because I can't boot into the system now. I get stuck in the loader and can't load/find a kernel from the loader.

I created the msdos fs in the efi partition and copied the existing files from '/boot/efi/*', updated '/etc/fstab', updated 'efibootmgr' with an entry pointing at 'gpt/efiboot1' (the label I gave the efi/msdosfs partition on one of the drives) and double checked everything I had read/found and hit it with a good ole reboot

I can see in the server's BIOS the UEFI listing I created with 'efibootmgr' and it will boot until it fails to find the kernel I believe - then drops me in the loader cli. I can see my drives and partitions with 'lsdev', and the efi files are there, but that's where I get stuck.

radhitya: Nothing automated, but: man.freebsd.org/cgi/man.cgi?tuning

I've never seen tuned(8) outside of RHEL or I guess Debian.

Is anyone using the aarch64 build of FreeBSD? pkg seems to be broken on fresh install, and there are a lot of bug reports I see on forums, it's still happening on aarch64 after a few days.

This error, except for aarch64 and not solved forums.freebsd.org/threads/pkg-erro…-failed-packages-path.101121/page-3

arch-nemesis: this problem is not architecture-dependent

okay, I assumed there might be different package databases for different archs

yes, that's true, but this bug is common and hits randomly

arch-nemesis: been working for me just fine on my 15.0 VM

smth is wrong with ports

I can give it another shot in a bit. Now I'm kinda just curious what causes that issue. Seems like a schema migration thing.

i checked out the 2025q4 branch, but it wants gettext 0.26, while only 0.23 is available in the repository

it's updating my plasma desktop after updating itself to 2.5.1 just now

i thought the bug was just on quarterly, latest is fixed now

i checked out the 2025q4 branch, but it wants gettext 0.26, while only 0.23 is available in the repository

wtf I compiled a program but it segfaults due to �privileged opcode�

debugger shows the opcode �ud2� being 0F 0B, wtf is that?

that is a kind of undefined error opcode

you should never execute ud2 in correct operation

the compiler may emit ud2 in places that should never be reached

you need to work out what you have done to reach an ud2 opcode

i ran the executable

what is the program?

an app

if you'd like help be less of a dork

since there are 37000+ programs in ports, let me get my crystal ball for sjjd

which program that is is completely irrelevant to my question

it was compiled in freebsd with the default port build settings

and it produces that error

no it isn't, since the majority of ports (I guess ~37000+) compile just fine

there is some error in the program makeing it execute something it shouldn't execute, maybe a jump to some computed address and it computes the address wrong, but more we can't say without knowing the program in question

say, seeing as freebsd-update has all the code necessary to make sure it's not about to clobber a configuration file that you've altered, do we have the inverse – a tool that'll let you grab everything you _have_ altered, eg, to make it quick to reproduce a configuration on another machine?

or at least as a starting point for an ansible config

zip: that's handled by etcupdate, not something in freebsd-update itself. i don't know if etcupdate can do that, but the manpage might be informative. for pkgbase, i believe there is a pkg command to list modified configuration files, but i don't remember what it is

I'll have to have a dig later. That's useful to know!

hm, pretty sure pkg compares config files with the default one installed with a .sample postfix

nimaje: that's for ports. pkgbase uses @config which doesn't use .sample files

(ports could use @config too, but they are not allowed to by policy)

/8/8

err

sjjd, which programme is it? seriously.

the binary must not be stripped and must be built with debugging symbols to allow successful debugging

my understanding is that the symbols could, technically, be separate

another reason I'm waiting for subpackages being production ready, I could just activate the DEBUGINFO feature for my bulks and have installable debug symbols for my packages

Trying to mount root from ufs:/dev/vtbd0p2 [rw]...

/etc/rc: find_system_scripts: not found

don't think i've seen this one before

% grep -r find_system_scripts /etc/rc*

it is mysteriously missing from rc.subr

would you like me to share?

i have another 15 system to copy it from

oh ok, im on 14.3

i dont know why you cant bulk merge rc.d, merging all those by hand is brutal

bulk merge is brutal, file-by-file merge is ... cruel.

I'm stuck in the loader.efi - "Failed to find bootable partition". How do I point it at my ZFS pool?

is it bootfs problem?

for example, zpool set bootfs=zroot/ROOT/default zroot

Not necessarily, yesterday I was migrating my existing zpool (single disk) to a mirror on 2 new drives. I successfully partitioned my two new drives to match the original and got the pool to use those drives as a mirror cont..

then i copied over /boot/efi/* to the partitions on the two new mirrored drives

and updated with 'efibootmgr'. Then hit a 'reboot' and I must've missed something because the loader isn't loading the main zfs filesystem to find the kernel

is bootfs property set?

interesting

bootfs=zroot/ROOT/default shouldn't have changed since I simply changed around the drives underneath the pool

I tried setting 'currdev=disk0p4' (the partition of one of the mirrored disks) but loader didn't like that and "unable to open '/'"

i think i've never set currdev or somthing except bootfs, can you check it again?: zpool get bootfs

my zroot is single disk

yeah mine was previously - that's why I'm where I am. Threw this system together with a cheap ole ssd for a pet project. Bossman liked the project and gave me 2 newer ssd's so I was trying to put my zroot from a single disk to a mirror using these new disks and get rid of the old one

thermos: is efi partiton on the same drive that ZFS pool exists ?

yeah, I put the efi partition on both of the mirrored disks - each partition with the same contents

my efi partition: /boot/efi/efi/boot/bootx64.efi (loader.efi)

i don't need to create efibootmgr entry manually

+Boot0001* UEFI OS

nxjoseph: yep same

I only created a efibootmgr entry because I needed to point it to an entirely different disk/partition since I was getting rid of the original disk for this mirrored set

i see

for shts and giggles I just tried force booting via BIOS instead of UEFI and I get messages like "cant find /boot/kernel/kernel" or "/boot/zfsloader"

not sure what step I missed but it seems that in both UEFI and BIOS, the loaders are failing to be directed to the ZFS filesystem/pool and therefore are not able to find '/boot/kernel' and the like

atp I am wondering if I could just boot from the FreeBSD installer and try to import my pool? I could care less about figuring out where I went wrong and fixing it if instead I could just install fresh and import my pool/data

yes you can

mount -o size=1m -t tmpfs tmpfs /mnt && zpool import -o altroot=/mnt poolname

okay let me try that quick, thanks nxjoseph

ok, you're welcome

Do you know, should i grab the '*-bootonly.iso'?

yes if you want to download it faster, compressed ones with xz is smaller

but you'd need internet for fetching the sets

while doing the installation

word, thanks

nxjoseph: do i boot into the installer, single user or loader to get the shell that I need?

installer, so normal boot

then you could be able to pick between 3 options, installer, shell and root system.

nxjoseph: so efi loader can't find zpool ?

okay yeah I can mount my pool after 'geli attach <partition>' do I need to make an entry in the /tmp/bsdinstall_etc/fstab then?

is your efi loader recent enough ? is zpool on encrypted device (geli) ?

now it seems to be encrypted

that changes things i guess

encrypted, on geli

OK

mzar: should be, yes it is geli

OK, that's clear now

so as far as i understood in the past, to use geli encrypted root, the boot parititon must continue the whole /boot things like kernel etc. correct me if im wrong, im not sure

do you see a problem that i odnt? still wasn't sure why it wouldn't find it though since loader.conf loades the kernel modules for geli

nxjoseph: yeah that would sound about right...

in the efi/boot partition, does it only have the loader.efi?

i think it should contain the kernel, modules etc too

yep.

my /boot is 190M, i hope your efi partition was already big enough, i'd try copying the whole /boot from the installation live medium to the your boot partition

I don't know, I am not using full disk encryption, but most likely not

yeah this makes sense. all the resources I found within forums, manpages etc. all referred to the msdosfs efi partition just needing the efi/freebsd/loader.efi

i don't know much about geli, so....

it's advanced topic

my efi partition is 260M so I should be good, I'll try copying from live install into the partion and see what happens. Thanks for this insight nxjoseph.

i hope it would work

yeah disk encryption seems great but on nearly every system I've used it on it seems to come back to bite me - could chalk it to skill issue etc. but anyway, I'll try this new idea

follow this xyinn.org/md/freebsd/zfs_manual_partition_encrypted

load required modules

mzar: thanks, this is what my system and these files looked like before this fatal 'reboot' but I might need to do this anyways if copying from the installer to my boot partition doesn't solve the problem

thermos: what happened to them ?

boot from they thumb drive, attach encrypted partion, import zpool, fix loader and you will be fine

you can also upgrade loader on the efi partion, 15.0 uses OpenZFS 2.4, 14.x uses 2.2, but if you have not upgraded zpool it shouldn't be issue

import pool temporarily, with -R option

not entirely sure, perhaps since I installed initially to a single disk with geli zroot from the bsdinstaller they are in that disk's efi partition - cause they aren't in my mounted zroot

sure. mount them by hand and upgrade, one by one, using the most recent /boot/loader.efi

mount_msdosfs /dev/efipartion /mnt

you can fix it

no worries

yeah yep workin on that, thanks. i mounted zroot via 'zpool import -o altroot=/mnt zroot' - how do i unmount it? X'D

zpool export

zpool export zroot

thanks

but zroot/ROOT/default isn't mounted

yes, mount -t zfs zroot/ROOT/default

you have to mount it by hand

nxjoseph will guide you thermos, good luck guys !

im afraid i won't be able to

not much experienced in geli

no worries, now you are gaining experience

so 'zpool import -o altroot=/mnt zroot' and 'mount -t zfs zroot/ROOT/default' are completely different mounts? 'zroot/ROOT/default' is where stuff like /etc was written then

I have to go, bbl

mzar: thanks for the help

the root (/) resides in the dataset zroot/ROOT/default, when you do zpool import, this won't get mounted automatically

you should mount it by hand manually

yes, /etc may be there

zfs mount zroot/ROOT/default - if you have imported poool with -R you should be fine

i think -R equals to -o altroot

oh okay, so a mount of my entire system back to it's previous state would be both 'zpool import -R / zroot' and 'mount -t zfs zroot/ROOT/default'

wrot

wrong

yes but mount to /mnt instead, on live media, you can'tr mount it to the /

-R /mnt or sth like this

nxjoseph: word, but on a normal system it would look like that^ so that the datasets are mounted from '/' then, since when I do it with '-R /mnt' the datasets are mounted as if '/mnt' is root.

yes right

Good afternoon! Forgive me if this is trivial. I noticed when I installed 15 release and chose to encrypt my home directory when using ZFS. If you enter a password too short it does not allow you to retry. It just finishes creating the account.

rtj, so you've got an unencrypted home directory?

okay gimme a few minutes to try sorting out my efi partition and ill get back with what happens

thermos, ok

nxjoseph: Can it print a warning if it goes through saying it's not encrypted? I don't think my system booted that time but it was 2am and could have just been user error.

the command "zfs get encryption" should show "on" value for an encrypted zfs dataset, for your home

Yes I am aware of that. I have read the manual for that part.

i didn't get the question sry

No question. It was an observation.

idk if i ever used the word "observation" as a non-native speaker

I did not figure it was worthy of a mailing list post. So I just put it in here. Thank you for trying to help.

no worries you're welcome

nxjoseph: weird. I mounted my original disk's efi partition and it too only has efi/boot/bootx64.efi and efi/freebsd/loader.efi - not sure what magic it did to load the geli/zfs pool to get the rest of the /boot with the kernel and whatnot... Aware that you probably aren't sure either, just reporting what I found

one sec

maybe you need to use geli(8) configure command because you switched disks?

can you see the manpage, like setting a BOOT flag?

possible i may have missed something, but yesterday I did thouroughly read the manpage and reference it as I setup the new freebsd-zfs partitions on these new disks.

does geli ever store something related to the root partition?

store some files for record?

so they have the same flags as the original geli partition: BOOT, GELIBOOT, AUTORESIZE

hmm, i'm like run out of ideas.... :/

yeah i think it stores a 'backup' somewhere in var

hmmm

are they keys that stored in /var ?

I think keys can be stored anywhere - don't quote me as this is just off the top of my head. regardless I just use geli with a passphrase.

i see

sl

just copied /boot/* into the efi partition to see if this the loader can then find the kernel. Since my original drive only had the loader in it's efi partition, this is probably not the correct thing to do. But i'm curious

hmm let's see

nxjoseph: any idea what the manpage is that documents the loader commands?

there is loader.conf and loader manpages

found it, used 'boot kernel/kernel' and now I am at a new prompt 'mountroot>'

there are 2 .eli devices right?

correct, 'mirror da0p4.eli da1p4.eli'

did you had any geli configuration in /etc/rc.conf or /boot/loader.conf?

i don't know if this is right but just asking

yeah the 'geom_eli_load="YES"' was put in loader.conf from the original installation

this is what happens when I let the boot process playout

when you do `geli list`, does it show the same flags BOOT,GELIBOOT for both .eli devices?

yeah yep.

with the original single-disk pool, it would prompt me for the geli password before doing anything like load the kernel. This makes sense since the kernel was in the zfs geli-encrypted partition of the disk

yes but why current loader doesn't do same i don't know

do you still have geom_eli_load in your loader.conf?

yeah I do. This is the root problem I think I'm having:

the loader is for some reason not detecting the zfs zroot pool and filesystem which is made up of a mirror vdev of da0p4.eli and da1p4.eli. Since it isn't detecting this, it doesn't prompt me for the geli passphrase to open the partitions, which is where the '/boot' directory lives, where the kernel lies.

yeah, very weird, i wonder what is the culprit herfe

also where loader.conf is.. So if I could just figure out how the heck the single drive did this under the same circumstances.

after including the kernel in the efi partition I was able to type 'boot kernel/kernel' at the prompt shown in that imgur link. Bringing me to this 'mountroot>' prompt, where I tried to mount zfs:zroot/ROOT/default and it doesn't see it.

:/

XD at least I feel better knowing that no one has said something like "well you obviously just do ..."

the mirror is a clone of the original single disk zfs layout right?

i mean im trying to ask how did you migrate

yeah ill walk you through:

thank you

first I copied the partition layout from the single disk to both new disks 'gpart backup da2 | gpart restore -F da0 da1'. Then I made 'msdosfs' on the efi partition da[0|1]p1 and copied /boot/efi into the partition. Then used 'geli init' and 'geli attach da[0|1]p4' with the same passphrase as the original disk to make the freebsd-zfs partitions da[0|1]p4 into *.eli

is that it?

then I 'zpool attach zroot da2p4.eli da0p4.eli' and then 'zpool replace zroot da2p4.eli da1p4.eli'

hm

and at this point it resilvered and the original disk was no longer in use. Also, before 'replace' and after 'attach' i ran 'gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 da0' and then again after 'replace', subbing 'da0' for 'da1'

I then ran 'efibootmgr -a -c -l da0p1:/efi/freebsd/loader.efi'

jjjjj

seems fine

do you have an account on forums.freebsd.org?

maybe some poeple there can help

no, I can post there, do you think it seems like a "Base System>Storage" thread

it seems right topic

okay. Will do, in the mean time I think I am going to just use the installer and tell it to use my existing zfs pool. do you know where I could find resources on how to do this correctly from the installer?

i think this guide can help you about this

the point is, prepare disk and parititons and keep the root dataset mounted to /mnt so the installer can handle the rest

but wouldn't this overwrite everything?

if i followed the guide exactly then yes, can perhaps just recreate the efi and gpt partitions

i think just wait for a solution

honestly I wish I could just get rid of geli but I would need another pair of disks to send/receive

you may lose data

okay, I'll get to writing up a post. Thank you very much for your help, I hope I didn't cause any major headaches

okay, you are welcome, no worries. i'll follow it up there.

you can actually exchange data between disks respectively but risky tho

'dd' XD - I read elsewhere online that ~"the only way to un-geli a zfs pool is to zfs send/receive to new disks", not sure if it's entirely the 'only way' but probably one of the sanest

yeah better but

very similar issue to what I'm having: forums.FreeBSD.org/threads/changing…eli-encrypted-zfs-pool-howto.101074

although they aren't having the same boot issue

you detach one of the disks from the mirror, make it a pool on it, send current pool to newpool, boot from newpool and attach the other disk to newpool, got rid of geli now. just a way guessed by me

in hindsight, that is probably what i should have done... I thought doing it this way I would be able to avoid any zfs boot configuration.

thermos, sorry to hear it's not going smoothly :(

is it currently a geli problem, and efi problem, or a zfs problem?

futune: ah you made it! no worries, it'll get sorted out eventually

i think it is both a geli/zfs problem. just restating my last summary: the loader is for some reason not detecting the zfs zroot pool and filesystem which is made up of a mirror vdev of da0p4.eli and da1p4.eli. Since it isn't detecting this, it doesn't prompt me for the geli passphrase to open the partitions, which is where the '/boot' directory lives, where the kernel lies.

I just inserted my old disk that i replaced with this mirror and now I get the GELI passphrase prompt back, but then get ZFS io errors (expected) since that partition is not part of the zroot pool anymore

thermos, the loader can not see the zfs pool until geli is unlocked, that's just impossible...

that makes sense, I don't know why it doesn't prompt for the geli passphrase for these new disks like it does with the old disk.

yeah that's the issue... I was expecting it to prompt, as well

if you can see the history and see the forum i linked where u/holm is trying to add/replace .eli disks to his pool, I did all the things that are mentioned in the thread (minus bringing the pool offline since I had slots available)

although he isn't completely replacing all the disks of his pool, he reported no issues with booting..

thermos, from reading man geli (8), it seems like which geli providers are unlocked before root mount is set by the geli providers themselves, not by loader config

thermos, from reading man geli (8), it seems like which geli providers are unlocked before root mount is set by the geli providers themselves, not by loader config (sorry to others for the repeat message)

so the geli init needed the -b flag, when you initialized them. But it's possible to set the boot flag on a geli provider after the fact with "geli configure -b devicename"

and the loader is supposed to try to unlock all geli providers that have the boot flag

yeah I had used both '-b -g' flags to get "Flags: BOOT, GELIBOOT, AUTORESIZE"

weird.

I see. That config sounds correct then. :(

useful to know how the sequence works though, thanks for finding that

hello

hi

anyone know any good resources for kernel customization?

futune: in the freebsd installer's live-system, can i create a pool with a single disk, mount my actual pool, zfs send to the single disk, then install fresh system using the mirror since the data would be backed up to that single disk - and post-install mount that single disk pool and transfer it back to my mirror

thermos, all of that should be possible

there are three ways to accomplish the last step though

okay, reading over zfs send docs it looks like the command would be 'zfs send -R zroot/ROOT' ?

Has anybody had trouble after upgrading emby-server? I'm trying to downgrade to dotnet8 however pkg install would install also compat13x-amd64, compat14x-amd64, dotnet-host 9.0.9, and dotnet8: 8.0.20.

thermos, are you familiar with datasets? a zfs pool contains multiple filesystems. Your command there would send the dataset named zroot/ROOT, and all its children, to stdout

the problem now is that I suspect you have multiple pools named zroot

yes, however, the default zroot/ROOT/default heirchy has been confusing to me, so I wasn't sure if all of the datasets are typically created as children of the ROOT/default and therefore the -R would properly capture all of them

negative, just created a pool named zbkp to send to

copy that. The zroot/ROOT dataset is typically an empty dataset used for organizational purposes, and then your boot environments will live as its children (such as zroot/ROOT/default)

the default is the one that actually gets mounted to / in this situation

oh okay so its just for boot environments, therefore the default /usr dataset is not it's child and 'zfs send -R zroot/ROOT/default' would not capture the 'zroot/usr/*' datasets

typically a lot of other datasets that do not live under zroot/ROOT are also important though

precisely!

like zroot/home, zroot/var

gotcha, then I will need to 'zpool import -R /mnt/zroot zroot' and 'zpool import -R /mnt/zbkp zbkp' and transfer between them, and then explicitly 'mount -t zfs zroot/ROOT/default /mnt/zroot-root' to get at those datasets for sending

It's important that these names are not the important bit - datasets have properties such as mountpoint, canmount and others

if you do "zfs list -o name,mountpoint,canmount" you'll get a good overview

thermos, no, you do not need to mount anything for sending. In fact, it might be better if you don't. You just decide which datasets are important on (old) zroot, and then "zfs send zroot/dataset | zfs recv zbkp/dataset"

the reason it's better if you don't is that one ordinarily sends snapshots of datasets rather than datasets, but if the dataset is unmounted, then you can send it without making a snapshot first, which saves a few keystrokes

okay thanks, but I do need to import them somewhere, otherwise zpool list shows nothing

ah, yes, sorry... there is a difference between importing and mounting, you can import with the -N flag to manipulate the pool without mounting any datasets. So, for what you are doing, you want to import both pools with zpool import -N

zpool import -N zroot to prevent from mounting

precisely

ha yeah you beat me to it, okay thanks for this