You can boot from anything if EFI is there

rtprio: during installation. encrypted and in wheel group

debdrup: may I PM? Re: FreeBSD Docs

Good morning! I'm having trouble installing FreeBSD on an UEFI only system. Searching the web suggest one needs to fiddle with repartioning the memstick image. Is that really the case these days?

|cos|: no. I have installed on an UEFI only system a few months ago, using the default memstick image. I don't recall having to do anything at all

Hi, usually not. The default image should work fine.

Thanks! I found some kind of legacy boot option hidden in the bios after all, thus getting it booting.

...and the machine seems to at least be able to UEFI boot the installed system... (That's what the graphical beastie means, right?)

jauntyd: I'd prefer it if you just asked here..

what's the way to find out what module a sysctl is in? like security.bsd.see_jail_proc

man sysctl.conf "named /etc/sysctl.kld.d/<modulename>.conf" but how do we figure out that modulename

it talks about kernel module specific sysctls there, I would expect that security.bsd.see_jail_proc isn't kernel module specific and even if it where it would be in a module compiled into the kernel and not loaded by rc in normal use cases

so what's the way to know if a sysctl is module specific or not, and what module it's from if so?

polyex: just grep the source code (or better yet, use ctags), and look for those sysctl declaration macros

the sysctl for security.bsd.see_jail_proc is declared in sys/kern/kern_prot.c, around line 1434

(not a module btw)

oprs tyvm! so does that mean security.bsd.see_jail_proc CANNOT be in /etc/sysctl.kld.d/<somefile>.conf?

I would expect so, yes, since it's not bound to any specific kld. You can still set it in /etc/sysctl.conf though.

ya but that's an inconsistency in freebsd design. usually we can put config in /etc/file.conf, or /etc/file.conf.d/<itsownfile>.conf. like how loader.conf.d can work and any other number of examples

that really sucks tbh no hate

I'm not sure what exactly you're trying to achieve here. And tbh you can probably set any sysctl (assuming it's already available) from any of the /etc/sysctl.kld.d/*.conf files, but that sounds like a misuse, since those files are supposed to be reserved for module-specific settings.

security.bsd.see_jail_proc is defined in kern_prot.c, which deals with general process protection; it's just part of the kernel (not a particular kld), so it only makes sense to use /etc/sysctl.conf for that right ?

oprs no because sometimes ppl like to build configs compositionally in multiple files instead of combined into 1 file

just get to the bottom question please ;-) what are you trying to achieve ?

oprs it's what i already said. to organize contents of sysctl.conf into their own files

i guess i just abuse sysctl.kld.d for that since there isn't a generic sysctl.conf.d like there should be!

well, you could argue for that on the mailing list or bugzilla

I had four FreeBSD 12.2 installations virtualized by KVM-QEMU-libvirt stack in Linux for few weeks. During that time the so to say virtual power cord of the VMs was pulled multiple times, i.e VMs were shut down with "virsh destroy". At some point I noticed that both pwd.db and spwd.db databases on all fours installations are corrupt. The FreeBSD machines were in idle state, no users were logged in, etc. Just

out of curiosity, any ideas what might have caused the corruption of /etc/pwd.db and /etc/spwd.db databases? There isn't a process constantly/frequently writing to those databases, is there?

Hi! I am facing this problem here: bugs.freebsd.org/bugzilla/show_bug.cgi?id=275760 and the patch works for me. How can I install the fixed version of bhyve?

is this patch available in 14.1?

Ronis_BR_ it looks like it's allready in the 14.1 Release: cgit.freebsd.org/src/tree/usr.sbin/…8a994bba45597c995c5ea76eec9cf3#n157

it was commited to stable/14 in january and releng/14.1 got created in may, so it should be in 14.1

mrtnt: no i would not expect those files to be open unless login is in the process of authenticating

but they should be able to be rebuilt

rtprio: ok, strange

no channel log?

wanna see if ober or anyone else replied to me after i d/c earlier. like 4-5 hours ago

about abusing sysctl.kld.d

did you see my message? (it was before your disconnect according to my client) there was no reaction of anyone else to that

ya about arguing with ppl on mailing list ty

I expect that extending where /etc/sysctl.conf is handled to load /etc/sysctl.conf.d/*.conf too is simple (but I haven't looked at it) and would guess that when you provide a patch, that it will get applied

what lang is the sysctl loading in?

seems to be handled in libexec/rc/rc.d/sysctl so sh

polyex: quick hack, in rc.d/sysctl, replace line 29:

for _f in /etc/sysctl.conf /etc/sysctl.conf.local; do

with:

for _f in /etc/sysctl.conf /etc/sysctl.conf.local /etc/sysctl.conf.d/*.conf; do

then you should be able to create /etc/sysctl.conf.d/, and populate it as you like

if it's actually that easy would you PLEASE submit a patch so everyone can benefit?

keep in mind that if you change /etc/rc.d/sysctl directly, your modifications may get reverted next time you run freebsd-update thoufh

ya exactly

oprs my argument for why everyone would benefit from this is it makes freebsd more consistent. ALL types of config can either be in a single file, (loader.conf) or in multiple files (loader.conf.d/)

it's the only exception i found so far

ty so much

anyone can submit patches, you're welcome to do it yourself ;)

if you do, don't forget to update the manpage for sysctl.conf

oprs how can i submit a patch?

make an acccount on bugs.freebsd.org, create a patch and write a problem report on bugs.f.o with your patch attached

need an email?

i just want to submit the patch info

oprs btw can't abuse sysctl.kld.d and use arbitrary somefile.conf with foo=bar

can someone with bugzilla account pls ad patch?

you would need to use a name of some kernel module you load via kld_list probably

ya but what module is "security.bsd..." in?

oprs showed that not all oids are from a module, so you can't even define them in /etc/sysctl.kld.d/*, showing yet another hole in the sysctl config story in ADDITION to the inconsistency with other parts of freebsd which is what sysctl.conf.d/*.conf would solve

Can 14.1 be built from 13.2?

there any way using ~ in .login_conf is bad and absolute path should be used instead?

polyex, appears multiple places in mine: termbin.com/hcgi

Well, /etc/login.conf

CrtxReavr: likely not

question.. is there any bsd client for crowdstrike?

no, not looking to install

debdrup: I was wondering if I could resume working on doc bugs?

pretty sure -CURRENT should be buildable from all supported releases at that time and so 14.1 should be buildable from 13.2

jauntyd: I don't see what's stopping you?