not sure if it's a bug, but i've noticed if i have an iov virtual function, e.g., iavf1, to a jail, and i restart the jail, sometimes the virtual function isn't ready when the jail tries to start and so it fails. bug worthy?

markmcb: i'm guessing it's due to other jail lifetime issues

iirc all of 13.x is affected, where a jail will stay alive for some seemingly random (but not actually) period of time after it's killed

ah, good to know. sounds like there's no need to report it then. thanks!

maybe- but, there is a way to know

one second

I think the problem I'm thinking of

bah, sorry. was fixed in cgit.freebsd.org/src/commit/?id=5fd…67e885e834cda8f1d122e9b0f9d47977e54. If you can try a -CURRENT snapshot after late April, that should tell you whether it's worth reporting or not

just so that you're not taking my word for it, you can observe if it's both the same problem and fixed in upcoming versions

markmcb: ^ even

thanks. i'll check it out

kevans: why isn't that an MFC candidate?

I have a broken disk (da0) in a zraid2 pool (with no free slots), am I correct to use: 1) zpool offline zroot da0p3 2) remove da0 disk / insert new disk at the same place 3) gpart backup da1|gpart restore -F da0p3 4) zpool online zroot da0p3

mage you also need zpool replace after online.

ok :) and couldn't I use detach/attach rather than offline/online/replace?

for mirror, you can detach and attach instead - if you are replacing in the same disk slot, that can make sense.

something like: 1) zpool detach zroot da0p3 2) remove da0 disk / insert new disk at the same place 3) gpart backup da1|gpart restore -F da0 4) zpool attach zroot da0p3

if you have free slots, I would attach new disk first, when resilver is complete, detach old one.

I don't have free slots unfortunately

yes, in that case, you have to do disk swap.

(it's a dell r340 with a HBA330 and 4x3,5 disks)

and what would be the difference between offline/online and detach/attach?

offline does not change pool configuration, detach does.

ok, so in my case offline/online is better

thanks :)

in your case, actually, it doe not really make much difference:)

both methods do work.

do you have spare?

with 2-way mirror the obvious risk is about good disk going bad while resilvering (or discovery of checksum errors/bad blocks).

zpool scrub before replace may be good idea if the broken disk is not dead or blocking the IO

tsoome: no I don't have space, it's a raidz2 over 4 disks

it is not dead but I have a bunch of:

(da0:mrsas0:1:0:0): READ(10). CDB: 28 00 33 9f ac 48 00 00 f0 00

(da0:mrsas0:1:0:0): CAM status: SCSI Status Error

(da0:mrsas0:1:0:0): SCSI status: OK

with some CKSUM: da0p3 ONLINE 0 0 30

ou, you do not have mirror, but raidz?

yes

with raidz, you only can use zpool offline, no detach for raidz

ah.. ok!

this is because detach will change pool layout, but we can not do that with raidz

sigh. disk replacement at home in raidz1 is waiting for me also. good that you reminded me.

anyhow, since you do have raidz2 (2 parity), scrub before replacing the disk is not that critical.

i, I am trying to build latest opensmtpd 7.3.0p0 with libressl 3.7.3. I have build it with -g3 -O0. Package is build ok but smtpd crashes. I need core dump but for some reason is not created. What could be wrong? When I try run simple C test program dereferencing null pointer core dump is created. Thanks

is the binary installed setuid?

RhodiumToad, no, it's not -> -r-xr-xr-x 1 root wheel 568080 Jun 19 19:59 /usr/local/sbin/smtpd

is it started under a resource limit that disables cores, or does it use setrlimit itself to disable them?

or perhaps it is running in a directory that it doesn't have permission to write to?

that last one can be worked around by setting kern.corefile to an absolute path

RhodiumToad, it's started under jail so it's possible there are some limits ..... i have run it by hand from /root so core dump should be there

RhodiumToad, kern.corefile: %N.core

that means the core dump is named progname.core in whatever dir is current for the process at the time it dies

(which might not be the current dir it's started from)

unless you change kern.corefile setting to a predictable location

ah, RhodiumToad already mentioned. sorry.

you could for example do sysctl kern.corefile="/var/tmp/%N.%P.core"

thanks, I try it

but dmesg show > pid 31929 (smtpd), jid 102, uid 257: exited on signal 11 .....and for test -> pid 91544 (test), jid 102, uid 0: exited on signal 11 (core dumped)

did you check whether smtpd is itself calling setrlimit() to disable cores?

and if so, whether it has some runtime or compile-time option to have it not do that

i have ktrace it and in kdump is no mention about setrlimit

is there any chdir in the kdump?

no, it's not .. my another try was -> lldb -o run -- /usr/local/sbin/smtpd -dv -f /usr/local/etc/mail/smtpd.conf ... but nothing useful is displayed when it crashes

what actually is displayed and can you get a backtrace?

oh, your message said uid 257 not uid 0, so something called setuid() ?

any successful call to set*uid etc. will set the SUGID flag, disabling coredumps unless sysctl kern.sugid_coredump=1 has been set

(which is a fairly major security hazard, so don't leave it enabled)

backtrace is what i want but i need coredump before ...smtpd in lldb crashes and 'bt' says anything about no process running

RhodiumToad, i will test sysctl kern.sugid_coredump=1 .....and we will see

remember that the location of the core file is still controlled by sysctl kern.corefile

btw there is no setuid call in kdump

might be seteuid, setreuid, setresuid, etc.

i searched for uid .....and there was many struct stat { ... uid=0 ... } and a few geteuid

well somehow it got to be uid 257 rather than 0

I also notice this:

_smtpd:*:257:257::0:0:OpenSMTPD:/var/empty:/usr/sbin/nologin

RhodiumToad: can you explain why kern.sugid_coredump=1 is a security hazard?

note that /var/empty is a directory which has its immutable flag set, so not even root can put files there

meena: it allows data read by root to be written to a file owned and readable by non-root

*nod*

the SUGID flag basically indicates whether the current process image may contain data belonging to more than one user/group, or belonging to some user/group other than the one that would own the core file

it's cleared by an exec() of a non-setuid/setgid program, since that replaces the image

it's set by exec() of a setuid/setgid program or by any successful change of credentials

RhodiumToad, running user is compile time option -> ./configure --with-user-smtpd=_smtpd --with-user-queue=_smtpq --with-group-queue=_smtpq ....so somehow it changes uid, you are right

i will try sysctl kern.sugid_coredump=1 and sysctl kern.corefile="/tmp/%N.core"

RhodiumToad, but interesting fact is I have opensmtpd 7.3.0 working builded with openssl base, openssl30 from ports too,...but with libressl not

so my buildworld, run with /usr/bin/time -h make buildworld came out to 1d5H21m53 Real, 1d4H13m User and 56m49 Sys. du -s shows 16938560 or 16G. Good times. it finally finished overnight

hey folks, how can i enable permissions to write to a mounted disk drive? i am trying to install a bootloader into it with extlinux64, but a mounted drive cannot be written to via raw-device

as root ? you can shoot yourself in the foot with kern.geom.debugflags=16 and assuming vfs.zfs.debugflags= does the same thing but haven't used it

i am root, that is why i am asking

if i do `echo 1 >>/dev/da0` or `echo 1 >>dev/da0s1` on a disk that is mounted in /mnt i get 'Permission Denied'

sysctl kern.geom.debugflags=16 and try again

keep in mind you are turning restriction and checks nearly completely off

i understand, i just need this for 1 usb drive

think thats why that was there in the first place

sidecases need a little extra help

still nothing

you very well may just need to unmount it first

nope

could it have anything to do with the filesystem being msdosfs with FAT32 ?

no it shouldn't

if its a usb disk could there be a switch on the side to make it read-only ?

if anything you should be able to also boot into single user mode attach the device and write to it there too

there is but i switched it off already, its an SD card attached via USB adapter. Its not read only because i can write files to it, i can also write to it IF its unmounted

but i need to run a script from within the usbdrive where i extracted a debian-slax distro and have it properly install its bootloader into the device

which requires the drive to be mounted AND writable via raw-device

maybe some mount flags ?

that im unsure of. why not just copy the contents off the disk to a obj directory and then unmount the device so you can worth with the raw dev ?

s/worth/work

because it uses extlinux64 and that needs a directory path

could be also be because i made the layout with gpart instead of fdisk?

kern.geom.disk.da0.flags: aa<OPEN,CANFLUSHCACHE,DIRECTCOMPLETION,CANZONE>

maybe i could do soemthing with these flags?

that im unsure of. they could follow the kern.geom.debugflags=16

alright, gonna try in single user mode

++

didnt work

same errors, fbsd just wont allow me to do this

i suppose there isnt a super-root kind of mode

meena: I don't know, maybe it is

not explicitly mentioning it doesn't mean it can't/won't happen, just that the author didn't mention it

you'd have to ask him if there's some kbi implication in that stack that might prevent it

is it possible to write to a raw disk while it is mounted

gzar: how are testing that you can write?

that 'echo >>' does not seem to be a valid test

mounting it an writing to it works fine

i can do a dd if=/dev/zero of=/dev/da0 as well

if its unmounted of course

whats the proper way to start dbus? i have `dbus_enable="YES"` in /etc/rc.conf and i see dbus pids running on background, but without DBUS env vars stuff available and some programs returns errors like "no connection to bus"

also, i have /var/lib/dbus/machine-id available

service dbus start

cpet: returns "dbus already running? (pid=963)."

kevans: I'm always surprised to re-realise that TV project has no head / hat of MFC

solved dbus issue starting X with dbus-run-session on xinitrc

I am having problems booting FreeBSD in a VM (actually I'm trying to boot from OPNsense .iso) normally it works, but in a definite environment (the one I need, of course) it bombs with a very suspicious: "Timecounter "TSC" frequency 0 Hz quality 800" followed by "kernel trap 18 with interrupts disabled" What can I check? (note I'm *not* a *BSD expert, but I can do *nix)

mcon: what hypervisor? also "kernel trap 18" doesn't say much, may be provide a screenshot of the panic?

Underlying is qemu, but I'm using it through LXD. I can provide the full log. Just a moment...

yuripv: Full log (including useless blank lines) is at bpa.st/75WGK

Title: View paste 75WGK

yuripv: my guess is kernel is trying to compute something using "TSC" (whatever it is) and bombs because it doesn't expect a zero there. Why the Timecounter is zero is beyond my depth.

yuripv: note: I'm still at debug prompt, so I *could* (if directed) try t to dig some more info

mcon: which FreeBSD kernel is that? what platform is it running on?

ah 13.1

mcon: at bug should be fixed in 13.2

mcon: freebsd/freebsd-src #664 / bugs.freebsd.org/bugzilla/show_bug.cgi?id=269767

Title: apic: prevent divide by zero in CPU frequency init by igalic · Pull Request #664 · freebsd/freebsd-src · GitHub

meena: I have two problems now: 1) convince OPNsense guys to upgrade to 13.2+ 2) understand why Timecount is zero in exactly the setup I need ;(

is there still no way to boot a native zfs encrypted freebsd root? I thought I read about 13.2 having added functionality built into loader or perhaps there was just a round-about way to get it working? I was hoping to install FreeBSD14 on the same encrypted zpool as linux is using but I cant find any info about what needs to be done to boot it anymore

did i mistake a dream for reality again?

mcon: what platform are you running on?

Also, 13.1 will be EoL soon.

meena: i don't really understand what you mean

i don't know what TV project you're referring to to start with

s/TV/the/

and head/hat of MFC? that's a really individual thing to decide

there's not really going to be one person qualified to say what can be MFC'd

but a lot of things are said to be MFCs and then forgotten

not without wasting way too much of their tim

time

we have tooling that's supposed to help there, sometimes it falls through the cracks anyways

we get an e-mail after the MFC period ends if we mark it, for instance

sometimes you get busy, sometimes you realize it's not feasible, sometimes you decide it's not a good idea or needs more bake time

aye

meena: I am running LXD under Linux (Debian Bookworm, if it matters) and I'm trying to run OPNsense (FreeBSD based) in a qemu VM; host is a rather small intel x86_64... admittedly not the cleanest situation.

mcon: so you're hitting exactly the same bug i did, and fixed

mcon: if you can change LXD's default profile to not be Q35, you might succeed

mcon: note that you won't be able to benefit from running under LXD, because lxc/lxd #11761 and bugs.freebsd.org/bugzilla/show_bug.cgi?id=271793

Title: Make LXD-Agent run on FreeBSD by igalic · Pull Request #11761 · lxc/lxd · GitHub

I'm working on those, but not there yet

mcon: i had a weird old system which picked the wrong time counter, that system ticked so fast ntp couldn't keep it on time

meena: Thanks. If I get you right this means OPNsense will not work right under LXD even if I move to 13.2+ and until you finish implementing virtio-vsock, right? I fear this means I will have to drop OPNsense, at least for the time being :(

mcon: no, it'll run, poorly, until you devmatch_blocklist="virtio_random.ko". but you won't be able to lxc console into it, and lxd won't know what's going on inside

you'll still be able to use ssh

meena: I found this: discuss.linuxcontainers.org/t/run-f…-2-7-0-and-newer-under-lxd-vm/15799 Do you think it's relevant?

Title: Run FreeBSD 13.1 / OPNsense 22.7 / pfSense 2.7.0 (and newer?) under LXD VM - Tutorials - Linux Containers Forum

mcon: you can try it, but that doesn't disable Q35, which I secretly suspect to be at fault here

meena: Thanks, I'll try it tomorrow. I'll report my findings. (BTW: what is "Q35"?)

A Transistor?

A Car?

Intel chipset? :-D

Part number for the ashtray in a '73 Pinto?

I am still looking for a replacement center brake light lens to replace the broken one in my old Ford.

lol

Red tape

But Q35 is an Intel chipset. Two references, both less than useful: en.wikipedia.org/wiki/List_of_Intel_chipsets and wiki.qemu.org/Features/Q35

Title: List of Intel chipsets - Wikipedia

Yeah. I guess I never had a board with that chipset.

Was X58 X79 etc.

Hail broke it out a while back. It has two lamps beind it. I removed one so there would be no white showing. It's acceptable with one lamp but no redundancy.

Q35 is a qemu profile, named after the above Intel chipset. it's essentially "modern" virtio

From the QEMU Q35 page: "Add emulation of the ICH9 host chipset as an alternative to the current I440FX emulation. This will allow for better support of PCI-E passthrough since ICH9 uses a PCI-E bus whereas the I440FX only supports a PCI bus."

What's the PCI bus bandwidth? IIRC it was 32-bits at 32MHz?? Who would ever need more bandwidth? :-)

weirdly, some people started demanding their virtual machines to be fast