it seems the "zpool" service is also required. so i enabled it in rc.conf. but it doesn't get executed for some reasons and the logs don't contain anything about it… doing "service zpool start" manually on a shell properly imports the pools and doing "service zfs start" after it properly mounts them, too…

man, even when trying to get rid of it, zfs keeps being a royal pain @_@

there is no zpool service

does `zpool import` work once your geli devices are attached?

phryk: ^

rtprio: /etc/rc.d/zpool, i.e. service zpool start

yes, manual import works, no issues.

and you're trying to mak this work automatically on boot?

rtprio: yes, but after the bootloaded. pretty sure it'd work if I add zpool_cache_* to my /boot/loader.conf again, but that's imo the wrong way to go about it. i want my early boot stuff independent from zfs and want the zfs service to just take care of importing/mounting the old pools whenever it gets run by init.

if it wasn't on top of geli it would mount on boot if it was imported

the geli part isn't a problem. damn thing just isn't getting imported. i.e. /etc/rc.d/zpool start isn't getting executed.

and you said zfs_enable=YES is present in rc.conf

yes, and zpool_enable, too.

that's not a thing

yeah, script says rcvar is zfs_enable for that, too, but as it obviously wasn't getting executed it was worth a try.

i bet you'd find that it was getting executed, just not doing what you'd like

yeah, that's why service zpool start does exactly what i am expecting…

also doesn't hard coding your geli so your it unlocks at boot without intervention somewhat defeat the point of having them encrypted ?

that's not what i'm doing and i never said it was.

then i'm not sure how you expect zfs to suddenly recognize there is a pool it should mount

exactly the way running 'service zpool start' does it? just that i want the script to *actually be executed* by init?

i don't see why the zpool cache would change if geli were attached or not

what are you even talking about?

first real line of /etc/rc.d/zpool:

for cachefile in /etc/zfs/zpool.cache /boot/zfs/zpool.cache; do

sounds like you should put some logger(1) lines in /etc/rc.d/zpool and see what's happening

yeah, both exist. both have the pool definition. i don't see the issue.

if it's not really being run, or it is being run and not finding the pool

do you load the module in loader.conf or no?

no.

you might try that

no. i'm migrating away from zfs. the basic boot should work without it. and it does. all i want is for the damn zfs service to actually import the damn cachefile.

ok, no need to take a tone. you can remove it when you're migrated off.

rtprio: it doesn't strike you as wrong, that automatic import/mount of zfs is just fails silently if you don't already activate zfs in loader? mounting it through init is just not valid anymore? o_O

phryk: it's weird but not wrong.

and again, you don't know if it's failing silently yet, you seem to avoid doing any of your own debugging

yes, i did.

it's not being executed.

i just fixed it by adding a prestart command to rc.d/zfs that checks for zpool_enabled and executes zpool start.

🤷

Is there a port target to re-generate the packing list? (It would be nice to not always have to clean + rebuild after a successful build but a slight modification to the packing list)

there is a target to make the plist, but it's not reliable

Oh, probably should have been clearer. I meant re-generate the temporary packing list that gets generated after stage but before package. (unless you meant that, then disregard, but after re-reading I realized it could be interpreted as the `make makeplist` target, which I do use sometimes).

oh. no.

you can run stage again without redoing build if you like, though

(make restage)

okay, it's 12 hours after i wanted to be finished, but i posted stuff: bugs.freebsd.org/bugzilla/show_bug.cgi?id=271384 bugs.freebsd.org/bugzilla/show_bug.cgi?id=271385

Title: 271384 – zpool not imported if zfs isn't enabled in loader.conf

phryk: did you look at the geli configure options?

RhodiumToad: the ones for loader.conf yes, or are you talking about some obscure compile-time options or somesuch thing?

no, the per-partition ones

is it loader that's prompting for passwords, or the rc script?

loader. or rather, geli itself.

geli-inside-loader and geli-inside-kernel aren't actually the same thing, quite

Title: g_eli.c « eli « geom « sys - src - FreeBSD source tree

this is the place, far as i can tell.

RhodiumToad: oh, is it implemented twice?

stand/libsa/geli is where the loader-specific parts are

it may pull in some of the files from sys/, haven't checked

Mhh, that doesn't seem to be what's used tho… The passphrase prompt in libsa/geli is "GELI Passphrase for…", but what I get when booting is "Enter passphrase for…" as in g_eli.c.

do you have a screenshot or transcript?

I guess since I have a vm handy I could attach a couple of disk images to test

May 13 02:06:14 phlogiston kernel: Enter passphrase for ada0p3: GEOM_ELI: Wrong key for ada0p3. Tries left: 1.

guess that at least definitely settles whether this is kernel or loader geli

basically there are at least 4 stages at which geli can require a key, though one of them only applies to non-EFI boot

where was that message?

RhodiumToad: /var/log/messages

is / on a geli partition?

and if so is it the same partition as /boot/loader ?

and is EFI in use?

yes and no and yes.

is /boot also on geli?

/ is geli, /boot is unencrypted other partition (far as i know encrypted /boot isn't possible), efi boot.

encrypted /boot has been possible for a long time even without EFI, with EFI it's trivial

please tell me more. :D

ok, the standard configuration now for EFI is for loader.efi to be on the ESP as bootx64.efi or somewhere else managed by an efi boot manager

with ESP you mean the fat partition?

loader.efi has the geli implementation from stand/ compiled into it, so it can decrypt a partition to find the rest of /boot to get loader.conf, modules, etc.

yes

with that configuration, there's also no need to separate /boot from /

I believe the installer even has an option for it

so the keyfiles go onto the ESP, too? how are they referenced in loader.conf?

do you want it to use a passphrase, or not?

wait. there is no loader.conf there… how do i tell it where to look?

yes.

keyfile + passphrase.

sec.

let me fire up the installer to check something.

sure, i'm in zombie mode anyhow^^

dammit, I have too many partitions

are you using zfs or ufs?

just migrated from zfs to ufs^^

ok, installed, rebooting

/* XXX TODO: Support loading key files. */

well, um, that answers that question

ok, so loader can only do passphrases

what it'll do is prompt for passphrases only for geli devices it finds with the boot flag set

and not any others

yeah, that's what the kernel version does, too. that's not where the issue lies, tho.^^

so what is the issue?

that i can't limit it to ask for passphrases for the gpt labels to which the keyfiles are associated.

do you have a requirement for all of these devices to be open in order for / to be accessible?

not strictly, but they are needed for services and jails.

Naruto meets Samuel Garcia Sepulveda, governor of Nuevo Leon in Mexico! They hit it off and start an intimate and sexual relationship! Naruto does a sexual jutsu on his rectum and later donates his cum so that Mariana, Samuel's wife, gives birth to either green or blue eyed babies! Read about this hot love story here! justpaste.it/Naruto_Makes_Love_Samuel_Garcia

Title: Naruto Has Ninja Sex with Nuevo Leon Governor Samuel Garcia - JustPaste.it

phryk: then surely you should set the boot flag only for the minimum you need to get / working, then use rc.conf to handle the rest

why would someone advertise their horny weeb fanfic here of all places?

Maybe they wanted FreeBSDM instead ;-)

RhodiumToad: that lessens the problem, but doesn't solve it. also, not really finding docs on rc.d/geli[2]. it seems to execute `geli_make_list`, which doesn't exist…

geli_make_list is in rc.subr

basically it tries to get only those devices which are either mentioned in fstab or explicitly in rc.conf geli_devices="..."

ah. that helps.

so it's all going by provider name, _not_ by metadata flags

anyhow sleps now

if there is any freebsd-audio expert here i'd love to get some help with my mic. cant get it to work still

gzar: you can try the multimedia mailing list or forums. i've had contact with the guy who wrote virtual-oss on there

alright, i think i'll try the forums first, since gmail doesnt play well with mailing lists

works ok for me on gmail

anyone aware of a tool that could transform files on-demand/in-memory before rsyncing them over? maybe something FUSE?

I've got ~10TB of .wav files I want to ship over to a last-resort backup storage box semi-regularly -- they come down to about ~800G as 320kbps .mp3, but I don't want to make space for or keep the .mp3 files :-)

domlaut: what is your plan to handle interrupted transfers? and how will rsync know what has been transfered or not

+f

im drunk.. +r

well, same way it usually handles it and knows. checksumming/ctime/filesize

I'm trying to build a pkg repo, that instead of relying on ${ABI} (which has the major version, but not the minor), relies on the ${OSVERSION} (which ends up looking like this 1203000

Never mind, looks like there's VERSION_MAJOR and VERSION_MINOR that I can use.

For a user whose preferred shell is csh, I can add to ~/.cshrc to work around a bug that can bite desktop environments such as Budgie:

setenv LIBGL_DRI3_DISABLE 1

Which one file should I edit for all users to benefit from the variable, regardless of their preferred shells?

/etc/login.conf

then cap_mkdb /etc/login.conf

Ah I forgot cap_mkdb

thanks

yw

otis: not yet effective, have I written to the wrong part of the file? <bsd.to/9e6z/raw>

Title: 9e6z

grahamperrin: see "setenv" record

so it will read :setenv=BLOCKSIZE=K,LIBGL_DRI3_DISABLE=1 \

Ah, so:

:setenv=LIBGL_DRI3_DISABLE=1:

Yes?

:setenv=BLOCKSIZE=K,LIBGL_DRI3_DISABLE=1

eh, :setenv=BLOCKSIZE=K,LIBGL_DRI3_DISABLE=1: \

thanks again

then also cap_mkdb ...

yup

hi people !

interesting the default ix module on FreeBSD 13.2 lets me download at 120MB/sec but the intel-ix-kmod package increases the nics speed to 600/700MB/sec

is that a known issue ?

Are both configured the same?

No, nevermind; I misread that "ix" being faster

i usually do a clean reinstall even for new minor versions but i'm wondering how safe is 13.1 -> 13.2 upgrade?

hi! which vnc viewer should i use to connect to a bhyve vm ?

vnc pkg*

I use Remmina, but be aware that there's a bug that can cause it to crash on connect. There's also TigerVNC, TightVNC, and RealVNC.

Wait, scratch RealVNC. That was on Windows.

_xor: how do i list the vm ip to connect to it ?

vm info says its running

That depends on how you have your vm networking setup.

right

so FreeBSD has its own version of netcat installed by default, named nc ?

last1: yes

weird, most docs say to use nc -l -p <port> but FreeBSD version is just nc -l <port>

took me a few minutes to figure it out

Title: freebsd-src/contrib/netcat at main · freebsd/freebsd-src · GitHub

netcat is a program with a troubled history.

The original version had some significant deficiencies, some of which bugged the snot out of me!

And other people too, apparently. Because it has been forked and modified significantly at least twice.

I actually think the "socat" program is the better program. It does the same thing as netcat does.

With a different more powerful syntax.

It looks to me like the -p option was added to one of the newer forks and does not appear in the original version by hobbit.

So those docs that reference -p <port> are the ones that are using the non-portable syntax. FreeBSD is using the traditional form there.

nc(1) on FreeBSD says "-p" is for the source port. Destination port is an argument, not an option value.

But under the -l option part it says "It is an error to use this option in conjunction with the -p, -s, or -z options."

And also in the -p option section too.

yep, saw that in the manual

however, it's still a difference in syntax for specifying the port when sending/receiving

not sure which would be considered 'best' but I guess it doesn't matter

I was wrong. I looked at the original netcat and it does list the -p option there.

And in the original README it does show examples with "nc -l -p 1234" so I was wrong about it being the new fork. It was in the original.

I don't know about "best" but gratuitous incompatibilities are always bad.

IIRC the main thing that bugged me about the traditional netcat is that it intentionally ignored EOF. In order to let the transfer finish.

The FreeBSD version I know has the -N option to force handling of EOF.

And then one would need to interrupt it manually when done.

IIRC the OpenBSD version has a -q <seconds> option to quit after that many seconds in order to accomplish basically the same thing.

In any case, check out "socat" which has a powerful simple syntax and is I think the better utility than netcat.

alright, thanks

so could i run a jail manager and/or bhyve manager in a jail on the physical host? Im currently running Truenas on my host and have been looking to switch to Xigmanas, which I like, but they strip out so much of the freebsd base system that even many third party no longer work on the newer releases.

so id like to attempt running xigmanas in a jail on vanilla fbsd. any tips? Im guessing theres not any tools that can take an iso or img file as input and let you run through the standard install but in a jail?

Is a PCI device required to be reserved for use with bhyve passthru, or can certain devices get away without host reservation? From what I've gathered so far, pptdevs mainly prevents the kernel from probing the device at boot. Not sure if that means that once it's probed+initialized that it won't be "re-probe'able" by the guest VM. I get why the

reservation would be required though.

derzahl: if there's a jail manager that listens on a socket for remote access, definatly

but i don't know any that do

it's kind of a shame that some of these, like Xigmanas, pfsense, etc don't package up their webmin portion and let you install it on any freebsd system

Seems like a strange thing to do, a jail to boot an ISO installer. I mean you could make the ISO available via dev device in the jail, but booting it doesn't seem to make sense.

You can run a VM inside of a jail and boot it with that, which I've done before.

(I'm assuming derzahl means booting an ISO installer, so if not, then disregard)

rtprio: what about just have the jail manage the HBA card/zpool? Id probably be more interested in having that part of the webui working than the jail/VM management stuff

Jails are not VMs. They're more akin to containers.

_xor: I mean 'pseudo-booting' I guess. basically a wrapper that will run the bsdinstall stuff and fake an physical install

good to know running a VM in a jail is possible

derzahl: other than ssh'ing to your vm host and doing the stuff i have no idea

im just looking for the best way take the webmin from something like xigmanas or truenas but run it in a container

im open to suggestions on what the best way would be

Make the zpool available to your jail and then tell it to use that pool.

"good to know running a VM in a jail is possible", i think the answer was exactly the opposite

yuripv: "<_xor> You can run a VM inside of a jail and boot it with that, which I've done before."

_xor: RE:"Make the zpool available to your jail"... so give the jail access to my HBA card? is that possible?

yuripv: I meant that you can make VM devices available to jails and then create/start/stop VMs from within jails. It was years ago that I did it, but I did run Gitlab in a jailed VM, though I think I did it with VirtualBox. This was before the gitlab ports were available.

I think you essentially just have to make /dev/vmm available to the jail and make sure it has proper mounts.

derzahl: Assuming you have your HBA card in /dev/, then sure. Though I think you're misunderstanding. You would make /dev/zfs visible to the jail.

i usually do a clean reinstall even for new minor versions but i'm wondering how safe is 13.1 -> 13.2 upgrade? anyone have or hear about ppl having probs?

derzahl: i think you might be better off trying to steal the webmin code to run on frebsd propr