i'm running unifi in a 13.2-RELEASE VNET jail. i reach the unifi webif through a caddy jail, also 13.2-RELEASE, where it reverse proxies to the unifi jail at port 8443. i upgraded the host to 14.0-release. now i can't reach the unifi webif because caddy can't reach the unifi jail. the logs show it's timing out. i didn't change my pf rules. i'm now trying to figure out why pf is blocking caddy from getting to the unifi jail

14.0-release notes don't indicate any related change

Title: FreeBSD 14.0 Is Delivering Great Performance Uplift & Running Well In Early Tests Review - Phoronix

wow, impressive

it's a vnet jail, and it will load fine if accessed directly, which is I convenient because I need to add the port to the url, and it's a self signed cert. So, it seems it is some caddy/pf interaction.. I guess

Wellp, pkgbase upgrade from 13 -> 14 worked pretty well. I just had to fix up pkg on my end (my internal repo doesn't have it built, apparently). I also had to remove FreeBSD-sendmail-dev and FreeBSD-iscsilegacy, both of which were leftovers from 13.x.

Much faster and simpler overall though. Definitely prefer it and I'm glad that I setup pkgbase for 13.x a few months ago.

I wonder when pkgbase will become the default.

i want to try quBSD on FreeBSD UNIX 14

_xor: I suspect the main problem is that statically linkeing pkg will break the plugin design completely

linking

Hmm, I wonder if inverting that dependency chain would solve it while still allowing static linking (assuming that's the issue).

i don't really know what this means

That is, plugins depend on pkg instead of the other way around, probably through something like libpkg.

So libpkg would be the main statically linked object with a generic interface, which would then be used by a thinner pkg executable to do what it does now, and then also by plugins to implement their functionality.

Er, that was worded oddly ("plugins depend on pkg instead of the other way around"). What I mean is that plugins are executables that load pkg instead of being shared libs that are loaded by pkg.

kind of adds a whole new layer of complexity

It's a decent amount of work, sure. Main added code though would be splitting pkg into executable + lib, no? ...or alternatively, there's also the rpc route which is popular these days.

i don't think it's actually feasible

plugins can do more than provide subcommands

Good point.

they're able to, e.g., hook into different stages of the process

we'd have to lose a lot of functionality or add a lot of overhead to make this work

Decent number of projects are using the ol' RPC approach, though packaged into new spec + tooling, for plugins. Something like gRPC or Avro or msgpack that implements a known interface and is invoked by the host process.

Yeah, just musing out loud mostly, don't expect it happen, though it's interesting.

hi, I ran into a compilation issue while building mysql80-server - pastebin.com/raw/vDM1QtWz - regarding _mm_crc32_u16 inline. my cpu might be too old, but normally there'd be workarounds. I don't know if I built the OS wrong or what the deal is.

This may be a stretch of a question, but is there a way to get the bhyve VNC server to support copy/paste? I'm actually not even sure what the VNC server even _is_ or if it's something bespoke for bhyve

Hey i have a question realted to sound. I have optical S/PDIF sound happening when I have dev.pcm.5.play.vchans=0 set...but when I set to to a non-zero number I cannot hear anything.

I think vchans are necessary, so how to get it working?

hello

rtyler: yeah, custom implementation: cgit.freebsd.org/src/tree/usr.sbin/bhyve/rfb.c -- not sure what's missing to do copy/paste

Title: rfb.c « bhyve « usr.sbin - src - FreeBSD source tree

thanks

there's a CUT_TEXT message from client -> server, but it suspiciously looks like the handler is just discarding it

reverse the order of suspiciously and looks there please

i'm actually not sure at all how you'd integrate that with the underlying machine

Don't most clients literally just simulate keyboard input for that as a fallback?

ultramage: I haven't built MySQL/MariaDB in a long time, but try building with gcc and see if the works.

AumShivaya: Are you using virtual_oss or in-kernel oss?

_xor: yeah, that seems reasonable; I suppose with a hypervisor framebuffer you're only going to get the one-way clipboard, need finer OS integration to be able to go the other direction

Yup, remote would have to support clipboard APIs on target platform and get notified to copy buffer contents and send it over the wire.

I think that's one of the things VirtualBox guest integrations does (though I'm not sure, haven't used vbox in quite a while).

thats what am running bsd on is vbox

yeah, that makes senses for something like a guest addon package

bsd has come up since the last time i use it

_xor: I really don't want to install the entire gcc bundle just for this...

ultramage: You can probably get the compiler as a package, rather than compiling it.

it worked half a year ago with 8.0.32 and fbsd 13.1, don't know if it had gcc in base

ultramage: Yes, it's unfortunate, but not everything compiles with llvm. There's still a decent number of projects that rely on gcc-specific extensions to build (e.g. Node.js). I'm not sure about mysql, but it wouldn't surprise me.

Wait, how are you building this? Manually from source or are you using the port?

I didn't touch any knobs last time, so I assume it used the default compiler, which on 13.1 was clang I think

port

Do you have /etc/make.conf?

yes, with some basic stuff

pastebin it

I found a bunch of previous cases of various packages failing like this, from what I gathered, it happens when the software force-targets a new enough intel cpu, or does hand-crafted asm/intrinsic shenanigans without compatibility checks.

I'd either try commenting out CPUTYPE and ALLOW_UNSUPPORTED_SYSTEM just to see if it makes a diff (quick to check), or I'd try installing gcc and setting CC=gcc12 CXX=g++12 for the compile.

I saw one mention of -mno-crc32 so I'm doing a build just to see if that does anything.

unsupported system was just a temporary thing while I was on 13.0 past its support date

Uhhhh...

not sure why I needed it. I don't remember if it blocked port building entirely, or if it was just a nag message that repeated a million times during port upgrade

kevans: So I was just getting a repo signature verification failure on my internal repo just now after upgrading to 14.

kevans: Triple-checked the signing key + pubkey and they're fine (as they should be, nothing was changed on that side).

kevans: On a hunch, I decided to re-sign the repository over NFS using openssl@3 on the newly upgraded system (repo host is still 13.x with openssl111)...and it works now.

Even though it's a major version difference between 1.1.1 & 3, I wouldn't have expected that to break.

(likely unrelated, but after upgrading to 14.0 my ssh login stopped working because my old PuTTY was still relying on rsa, and that algo was disabled)

_xor: hmm, specific consideration went into exactly that scenario

(see the commit mesage for the 1.19.2 update: cgit.freebsd.org/ports/commit/?id=6…85a56d7e3b907de7c38f051f05efb45996a)

any version of pkg should have still been able to validate the old signature

Yeah, apparently signing using openssl⊙1 on 13.x with the same key fails verification on 14.x using openssl@3 and the corresponding pubkey.

Was about to ask you for a discussion link :P

Hmm, I wonder...one minute.

i was taking things for granted. none of my thin jails have internet access. they can't phone out. `host freebsd.org` just hangs. what the heck changed... hmm

Yup, guess it might be a bug, though I would suggest not underestimating my stupidity and exploring that with caution.

_xor: I don't recall, does inserting `-d` before the subcommand with some number of d characters >= 1 say anything about signing?

Is that a debug toggle?

yeah

more d == more debug in theory, iirc

DBG(1)[61490]> PkgRepo: extracting packagesite.yaml of repo xorander

DBG(1)[61967]> PkgRepo: extracting signature of repo in a sandbox

<dump of public key>

: rsa signature verification failure

Re-signed it over NFS using my builder system and now it verifies again ok.

_xor: oh, hold up

_xor: what version is the pkg client-side?

1.20.9

that's tnot the right answer, try again =D

What am I missing?

there was a fix for the compatibility bits in 1.20.0 and I was hoping you'd say 1.19.x

oh

Yeah sorry, it's 1.20.9 :/

omg

hmm, that fix seems to have just been to rewind the fd position because the 'correct' signature type that it would have failed read to the end

?

"Would build 3401 packages using 5 builders"

oof

I just wanted to kick off this poudriere build before hitting the sack in a bit.

I wonder why so many packages. I think I remember a full build being ~2000 packages last time. Must have been some new ports I added that pulled in a bunch of deps or something.

Looks like upgrading the rest of the system is going to have to wait a few days until this 14.x repo is built.

*systems

kevans: If a new issue is created regarding the pkg problem, link me.

I read that 14 has some bigger performance improvements. Maybe I'll be lucky and those will impact this build queue too.

_xor: I'm not sure which I am using. how to tell difference?

well, that is a bummer, I did get spotify installed in a linux jail, but...it won't let me play music says I'm offline, weird. oh well

solved. bastille had no pkg notes alerting to the new variables in bastille.conf. the jails were not getting added to the <jails> table in pf. once i added the missing vars and restarted the jails, all was kosher again

scoobybejesus: what variables ? which version of bastille ?

0.10.20231013. namely bastille_network_pf_table="jails". do diff -u bastille.conf bastille.conf.sample from /usr/local/etc/bastille

thanks scoobybejesus

14 update failed : pasteboard.co/X3yUquChInqF.jpg - Hello, tried to update from 13.2 to 14, new kernel crashes upon reboot but all is fine when I reboot on old kernel - not sure how to go from here, any ideas on what's wrong?

Title: Pasteboard - Uploaded Image

well that's less than ideal

looks like you probably just need to stop loading the nvidia module in loader.conf, move it to rc.conf

oh

not even that. just drop to loader prompt and write: toggle-module nvidia

then boot the system and upgrade that pkg, and hopefully it's not an issue of just running out of space to stage modules in loader

The "module 'kernel' exists but with wrong version" seems like a problem too.

that's the ^ "upgrade that pkg" reference

great, thanks a lot, will try the toggle-module nvidia, didn't know that one. will be back "soon"

good luck

re, so the toggle-module didn't prevent those modules from loading (nor the crash) - I guess next try is commenting those in rc.conf and loader.conf (somehow I have it in both :s)

You might need nvidia-modeset.ko instead of just nivida.ko, though I'm not sure if that causes a crash like that. Also, the nVidia driver...ummm...should be on an improvement plan, to put it mildly.

I'm not talking about the FreeBSD ported version as much as I'm talking about the upstream. I know this because out of everything on my main workstation, it's probably been the most annoying.

kld_list+="nvidia-modeset nvidia-drm" is what I have in /etc/rc.conf, and I have linux_enable="YES" in /boot/loader.conf. For whatever reason, that was required for me (couldn't just put explicitly required modules in /etc/rc.conf and let everything else auto-load).

omg

@kevans, thanks a lot it all worked out nicely, am in 14.0 now ;)

Yeah whatever, I helped too.

ah, thanks too then ^^ sorry was rebooting didn't see ^^

Lol np, I was just kidding. Kernel-module version mismatch is the obvious issue, but if you run into other problems later, you can reference my comments.

toggle-module didn't work, so I removed it from rc.conf and loader.conf - did the upgrades/updates, then reenabled it only in rc.conf and now it works well

I guess the entry in loader.conf was from when I installed a while back

Do you folks know if I can mix and match a single NFSv4 server with and without uidtostring mapping?

because for my servers, they use LDAP with SSSD, I don't need UID mapping

but I would like to have it on my mac

hi, I tried rebuilding mysql80-server without setting cputype in make.conf, but the outcome is the same - the thing is building for a 2016+ intel cpu feature set

should I post it on the bugtracker?

ultramage: seems like it used a default

is there any ETA for 275308? I upgraded our poudriere machine to 14.0 (with block cloning enabled) and wondered if some packages could be broken? Now I've set vfs.zfs.dmu_offset_next_sync=0, should I rebuilt everything to be sure?

Currently I've bcloneused and bclonesaved to 0

I was also wondering if 12.4 is also affected (our production machines are still running 12.4)

12.x has no openzfs-2 ( unless backported )?

I hope a fix will be released soon

mage: What's "275308"?

tercaL: PR regarding the ZFS data corruption bug

BTW I'll have to revisit my backup procedures after this bug ... (currently using zrepl) as ZFS cannot be 100% trusted (which I assumed)

so FreeBSD 14 was released with a buggy zfs and the dev knew about that?

the problem is within OpenZFS

*with a buggy OpenZFS

you can't blame the FreeBSD RE

oh no I don't, just wondering when the bug appeared

before or after release?

it was opened 2 weeks ago, but it's only since a few days ago that the situation is understood

getting 'no route to host' on freebsd when sshing from outside. I am on same LAN. SSHD is active. What can I do to debug?

$> route get host ; sockstat -4 |grep :22

Beladona: traceroute / tracert from outside ? if you get that error then your host is not reachable whatsoever, not just for sshd. Or you're ssh'ing to a hostname that resolves wrong

check pf config

and after all of that check with tcpdump

and if you just upgraded the SSH host then you may have to service sshd restart

pf would be bouncing with port unreachable or such, probably not it... try ssh'ing to the host's ip address instead of hostname. (no route might happen if the hostname resolves to ipv6 or a vpn ip or something)

looking at my dmesg, I get a lot of getswapspace failed, out of swap space, even tho my ram isn't even full?

a process was also killed with this message: `pid 18168 (GameUpdate), jid 0, uid 0, was killed: failed to reclaim memory`

the machine has 16gb ram, and 2 gb of swap

swap can be used preemptively and efficiently as a reserve, without having to spend memory.

should I increase swap size?

unless someone has a better idea. I'm kinda surprised it would be killing like that though, when it has ram. maybe it needs a knob to tell it to not be stupid about it?

ultramage: imgur.com/DeiP336.png

my host runs without a swapfile, so I haven't had the opportunity to figure this out

Beladona: hmhm are you bridging VMs via virtual switches, by any chance?

ultramage: the left one was host debian and right one was freebsd guest

yes

I have no idea about this, but I see you have enp6s0 at 192.168.1.101/24 and virbr0 at 192.168.1.200/24. not sure if this overlap is okay.

well virtual switch? not sure but the ...1.200 is virbr0 (qemue bridge). I wonder why that is there in tracerout

my lan is ...1.101

why it went to 200

routing table priority I guess?

ultramage: where did it started?

ultramage: do you use qemu?

nope I'm clueless about this.

try traceroute -s 192.168.1.101 to force it to go over the physical lan

-s not anoption in freebsd

o rits a s S?

that's straight from the 14.0 man page for traceroute :/ it's a small s

alternatively, -i enp6s0

er, you need to put in the destination i ptoo

there is no i either

can you paste full command.?

ffs.... traceroute -s 192.168.1.101 192.168.1.104 from the ssh host. or, in reverse from the clien

ultramage: imgur.com/BzTriRW.png

huh.

oof this system uses a swap partition

!H is host unreachable. is it possible that the ssh host's firewall is blocking outbound tcp/udp port 33434-33534

I assume resizing the zfs and increasing the swap partition size would be annoying af right?

ultramage: ok how do I allow firewall in freebsd?

yourfate: you can just add a swapfile to the mix, if you don't wanna go thru that hassle

can I have a swap partition and a swap file at the same time?

yourfate: if I assume that freebsd won't just kill processes because swap space ran out when it has plenty of ram left. is it possible you ran out of ram as well?

or can i just disable firewall?

ultramage: possible bun unlikely

but

ipfw is not enabled.

Beladona: I don't know what the default firewall configuration is - or if one is enabled at all - but I assume it wouldn't be blocking outbound stuff.

why I can't get in? ultramage do I still need to enable it and add rules?

try that command again, but use -i <interface> instead of source ip, maybe that'll be more informative

the fact that you have two interfaces targeting the same subnet might be the cause, but it also might not be. idk. I couldn't find info on how exactly freebsd prioritizes routes in case of overlap

ultramage: traceroute 192.168.1.101 -i em0?

oh yea, also try -I parameter, to make it send icmp pings instead of udp packets.

standard freebsd traceroute sometimes needs help (inbound firewall rules) to make it succeed all the way.

ultramage: ok I figured its not a freebsd issue as I can now ssh from another system on same lAN

LAN

hope you can narrow down the cause

yourfate: I don't know if you can trust 'top' to give you a proper breakdown of allocated memory, with all the fancy memory management that goes on.

i'll just watch this another day

I don't know enough to tell if you're running into a complete out-of-memory situation, or if freebsd really is killing jobs because of no swap even though there's still ram.

I first assumed it just crashed, but dmseg tells me it was killed

it was a gameserver (factorio) running in linux compat

if dmesg says something was killed, it should also have mentioned why

but it was killed in the middle of the night when nobody was online, in that case the server is paused and uses like no memory

RhodiumToad: see above: `pid 18168 (GameUpdate), jid 0, uid 0, was killed: failed to reclaim memory`

ok, but that could have been caused by memory demand on the part of some _other_ process

tried looking up what that means, but web search is full of people just reporting the error

and around that I get a lot of `swp_pager_getswapspace(7): failed`

swap_pager: out of swap space

swp_pager_getswapspace(17): failed

pid 18168 (GameUpdate), jid 0, uid 0, was killed: failed to reclaim memory

swp_pager_getswapspace(7): failed

swp_pager_getswapspace(23): failed

swp_pager_getswapspace(20): failed

swp_pager_getsw

oops

sorry I copied too much

the machine only has 2GB of swap, 16GB of ram, and ist basically idle

right, the swp_pager messages mean that the swap space is full

middle of the night... perhaps when one of the daily jobs was running?

no timestamps in dmesg

or can I see the somehow?

see /var/log/messages

hmmm 03:01

looks like a candidate, I think some backup job runs then

ultramage: it was the bridge from virtmanager

what's the baseline memory usage? if it's like 4GB, then going from 4 to 18 and capping out is pretty volatile

fixed when it was disabled

thanks!

ooh so the virtual cable was unplugged? ;o

yes :)

right, at 3:00 the restic forget job for the minecraft server is ran

that might use some memory

I was thinking of hyper-v and how it might have its own firewall/routing rules that decide which vms can talk to which other vms, and how that could cause unreachability. but the answer was simpler.

03:01 is the default time for daily periodic jobs to be started

ooh so I should maybe not also run the fairly big daily backup pruning then

so both the default ones (security scan etc.) and any daily jobs you installed in /usr/local/etc/periodic/daily

vm_pageout_oom(VM_OOM_MEM)

I moved the backup job, we'll see

of the default jobs, some of them sleep a random time before running to avoid congestion on things like the pkg vuln list download

dang, for periodic maintenance to eat all the OS memory, that's kinda unstable

periodic usually doesn't need much memory.

however, it can generate a lot of i/o

I just manually ran the backup pruning, it didn't use a lot of memory, but for a short time used all CPU cores 100%

(setting the nosuid flag on any large data disks is a good idea, since that saves the security jobs from needing to scan them)

maybe you have a memleak somewhere that eventually eats all ram?

would be noticeable at all times of the day as it gradually grows, tho'

m_pageout_inactive() - Attempt to reclaim the requested number of pages from the inactive queue.

so I guess that's why it's saying 'failed to reclaim', because there's a last effort attempt to scavenge memory before OOM is raised. And the wording of that error message that gets logged is too specific to the code it's from.

the getswapspace errors help to disambiguate

not really, if I were using swap I'd be looking into muting those.

what's supposed to happen is that under memory pressure, inactive pages get sent to the laundry, which writes the content out to disk and returns them as clean pages

however, if swap is full, then it has nowhere to write them to

I recall one practice was to stretch your swapfile so that it oculd fit all expected workload. then again, in a runaway scenario it would just prolong the thrashing period

so the inactive queue can be full of dirty (and hence non-reusable) pages, and when a page is needed to satisfy the demand, and one can't be found after waiting a reasonable interval,

right, I usually had about 50% of my memory as swap, which worked fine. this machine on ly has 2gb of swap for some reason

with 16gb of memory

then eventually it gives up and triggers the OOM-killer to free something up

imo swap is just a gimmick to squeeze out a bit more spare ram from over-enthusiastic allocations. if you have enough ram, it doesn't really need to be there, or it can be as small as you want

not so

even with overcommit, there are cases where lack of swap turns what would otherwise be an edge case (such as forking a large process) into an OOM condition

yourfate: incidentally, are you using zfs?

I run freebsd on 4gb ram with no swap. When I was doing buildworld -j4, llvm code required 600mb-1gb per cc job, and hit oom. That told me to drop down to -j2 to not overload the system. Having a swapfile in this case would first shove the entire OS into the swapfile, and then the jobs too.

I do builds on vms of around that size, but with plenty of swap.

what gets pages out first is not "the entire OS", but pages which are sitting unused for long periods

RhodiumToad: yes

swap is good, but I think works best for a server with many smaller background processes that mostly sit idle. if a heavy job comes in that consumes all available ram and even goes beyond that, it'll cause a mess

yourfate: worth noting that zfs arc is non-swappable, and the default size limit is quite high, which can lead to the amount of pageable memory being unexpectedly small under conditions of high filesystem activity

the arc is supposed to shrink under memory pressure, but may not do so fast enough

huuh... can file i/o cause oom because the i/o buffers have no limit?

if you look at the stats for top, zfs arc contributes to the "Wired" category

file i/o on zfs may lead to zfs trying to increase the arc size, which reduces memory available for other purposes (there's an arc_max setting to bound the size though)

outsize of zfs, file i/o goes via the VM system

*outside

ooh so my full system backup job would possbile use a lot of memory

with the ZFS memory + the backup tools compression, encrypted, dedup on top

*encryption

I have moved some jobs away from the 3am maintenance time

we'll see if this helps. thanks for the help, i'm afk, making lunch

you may want to look at what the zfs arc size looks like under normal workloads,

and set an arc_max limit that's not too much higher than that

I posted 275404 as my mysql issue, now I wait :B

I'm trying to do a remote copy via nc instead of scp and I'm using this command

ssh host 'nc -w 2 192.168.1.5 8111 < /var/mfs/metadata.mfs.back' | nc -l 8111 > /ssd_bkp/mfs/metadata.mfs.back.`date +'%H:%M'`

this works fine, but the local listen 'nc -l 8111' doesn't actually exit

it just stays there even after the copy is complete

am I missing anything here? this is my working freebsd drive imgur.com/3Ly72L3.png

it exits once the other side closes

wildeboskat: freshports.org/sysutils/fusefs-mhddfs ?

Title: FreshPorts -- sysutils/fusefs-mhddfs: Multi HDD [FUSE] File System

maybe try 'dd' instead of piping? I use that because it can handle big blocks instead of passing 1 byte at a time. maybe it also exits once it reads the whole file?

fixed. had to include p4

if you notice it runs slow, use dd instead of <>. especially for big stuff

but wouldn't this close once the file has been fully read ? nc -w 2 192.168.1.5 8111 < /var/mfs/metadata.mfs.back

am.. I am on freebsd. zroot of course. but mounted another drive that has zroot. How can I know the id of later and import it? It has same pool name 'zroot'

I mean, I am on the remote side and I see no nc process anymore, it has exited, but there is still an nc listen process on the receiving end

hm I think it should close

unless it doesn't, and you have to add some flag to make it do it. hmm.

it doesn't close by itself when I try it

I guesss that's the nature of pipes? I never really looked into the basics. you would think reading the last byte from stdin would signal eof

I think I figured it out

nc -w 2 -N 192.168.1.5 8111

I added the -N flag

on the sending side

oh. so I was right, it needs an extra flag to do it.

I switched to dd bs=10m when I noticed the transfer was running 10x slower than it should, and never tried piping again.

but maybe current OS and nc doesn't have that problem anymore. try it and see what sort of transfer rate you get

very good ones, 500mb/sec

but how do you plug dd into nc ?

well its not important anymore.. nevermind

dd if=file bs=10m | nc target

wait, why is -N not the default? like yeah, you don't always need it, but why wouldn't you just do it?

nimaje: my first guess is if the piped data is dynamically generated, it might signal eof after the first batch, and close prematurely? though I don't think that's how that works...

when there's no more data, it either blocks, or signals no data when polled; eof only happens on close(). so idk.

maybe the -N flag is there so that the thing can wait for a reply from the other side

really can't think of a scenario right now

but I also had the -w flag, right ? I thought that would take care of it

-w timeout Connections which cannot be established or are idle timeout after timeout seconds.

ah, yeah iirc with pipes it isn't easy to diffrent between eof and just no data currently

the question is, does it timeout and sends an EOF/EOT or it just dies

I thought it was?

maybe it doesn't, hence the explicit EOF sent by -N

err, no, socket shutdown on file EOF

anyways, my guess is that without -N, the sending client is able to keep the connection open, so that the listening server can send a reply, which it then can pipe somewhere or something. but then a script would need to be driving nc, otherwise it'd just be sitting there forever

or perhaps with that design, the server is supposed to close the connection. or it is up to the user on the client side to ctrl+c once everything is done

well, even without -N I can see that the client sending side has closed the process

but listening side keeps on listening ( and doesn't write the file )

pretty strange stuff

Hi! I've just tried to upgrade from 13.2 to 14.0R and I get zfs error after merging the config files. The datasets mentioned in the error are virtual disks for bhyve.

Creating snapshot of existing boot environment... cannot create 'zroot/ROOT/13.2-RELEASE-p5_2023-11-28_090341/bcbsd-ubuntusrv1-dsk1.vhd': 'canmount' does not apply to datasets of this typeerror when calling zfs_clone() to create boot env error when calling

zfs_clone() to create boot env

Failed to create bootenv 13.2-RELEASE-p5_2023-11-28_090341

failed.

How can skip be to skip those datasets?

you chose a pretty interesting time to upgrade

Title: Some late-breaking FreeBSD 14 breakage

also keep this in mind: bugs.freebsd.org/bugzilla/show_bug.cgi?id=275308

Title: 275308 – EN tracking issue for potential ZFS data corruption

Fortunately I don't use block cloning.

read the bug, block cloning just makes it worse

you can still have data corruption without block cloning

for now it's advised to set vfs.zfs.dmu_offset_next_sync to 0 until the official patch gets rolled out

last1 I was just reading that. :|

last1 I was about to change set that with systemctl and check it.

I changed vfs.zfs.dmu_offset_next_sync: 1 -> 0 ---> Same error.

How can I have 2-3 copies of metadata in zfs like btrfs has DUP? Note, I only want 2-3 copies of metadata. Not the real data in zfs

hm, seems like you can't control the number of copies of the metadata directly, but redundant_metadata defaults to all, which means you have two copies of all metadata

ok

thanks

\wc

Anyone up for getting my audio working through my speakers. i get audio through hdmi fine

pcm0: <Intel Kaby Lake (HDMI/DP 8ch)> (play) default is all i got and its sysctl -a |grep hda termbin.com/x2l9

im on 13.2-STABLE cause i read somwhere that i might have better luck there

i think you just have to set the default audio device

Hmm it's default already

i use virtual_oss to redirect my inputs and outputs on the fly

but firefox plays poorly

i have a hard time making it obey using virtual_oss

there's freaky setting in about:config to make that happen

hmm, it looks people over-dramatizing that zfs corruption issue

Demosthenex that for me ?

angry_vincent "your data is safe" is the selling point with zfs. so you can not over-dramatize that issue.

Demosthenex i've never got virtual_oss to play or work for me. ypu got a guide i will try it again

tsoome: i understand. but assigning CVE for it was kind of too much.

wi

jb1277976: just try in about:config setting "media.cubeb.backend" as "oss" and it is case sensitive

Thanks Demosthenex

I dunno, I mean, I learned about it from a hacker news post that had maybe 30 comments

so very low key

maybe assigning it a CVE would make it gather more attention, which it should

because there is no way to test if you have been affected

so the only sure way is to redo all your backups after the fix has been deployed

wasn't it only on really busy loads

gosh, using freebsd is such a breeze compared to linux

yep

it was a painless conversion for me

no more than distro swapping, a few paths changed, i had to reinstall some packages, thats it

yeah, all my linux apps work too with linuxulator

even discord and steam

at first it was busy loads, now it's lots of small files, slow io, etc

vlc: discord, bah. use a good os then run spyware.

Demosthenex: windows?

heh

i'm kinda forced to use discord because of my friends

everyone uses discord these days, you'd be fairly alone on alternatives :P

(many under duress)

No Discord here.

okok, most then :P

working on an image corruptor right now 0x0.st/HxiX.png

works purely on shell, ffmpeg and imagemagick

vlc why does it look like that ?

it passes the image through an audio filter

What is going on here? I spun up my regular Pourdriere run. The buildlists have php81 ports listed, but php82 ports have been built.

Schamschula: DEFAULT_VERSIONS?

Nope. I changed nothing, still running 13.2-RELEASE, i.e. no change in settings via OS upgrade.

user error then

I had no issues building 8.1 and 8.2 together and separately with 13.2

i hate discord

How so? It correctly built php 8.1.26 a couple of days ago (minus the php81-pecl-APCu issue that borked Nextcloud)

I generally don't want to upgrade php until I'm certain both Mediawiki and Nextcloud work under the new version.

rtprio whats wrong with discord ?

about everything?

jb1277976: you can't even sign up unless you have a mobile number that suits their arbitrary requirements

client is pretty resource intensive and the notification management is poor

their support staff are rude and dismissive

rtprio use your email ?

Schamschula: I upgraded to 8.2 and run 5 different mediawiki instances

one of them with 15-16 TB of monthly bandwidth

no issues so far

Remilia: thanks for the info

jb1277976: it requires a phone number that they can verify

jb1277976: plus anything you type in discord is not really removed even if you delete your account and select to remove your comments. Everything you say and do in there is recorded and can be used against you in some way.

then their support staff, suggested, of all things, use a different email address.

kenrap never thought about discord like that

How do you find the model number of your pc ?

its not undernath my laptop

sysctl dev.acpi.0.%desc

Does Poudriere respect /usr/ports/Mk/bsd.default-versions.mk for default versions? If so it should be building 8,1. There is nothing in /usr/local/etc/poudriere.d/make.conf

Default PHP was recently bumped to 8.2, wasn't it?

That still shouldn't twice override my local settings.

Where do you set your local settings?

found it also rtprio man.freebsd.org/cgi/man.cgi?query=dmidecode&format=html

Title: dmidecode

In /usr/ports/Mk/bsd.default-versions.mk and the poudriere buildlists for the specific ports.

jb1277976: here is an example: theverge.com/2023/4/13/23682097/dis…national-guard-classified-documents

Title: National Guard member arrested for leaking classified documents on Discord - The Verge

Schamschula: Can you show me the whole poudriere command you're issuing?

I'm curious if pkg will offer to upgrade everything when the build is done.

I see what you mean now kenrap

poudriere bulk -v -j 132amd64 -f /usr/local/etc/poudriere.d/buildlists/common

Anyway, I'll end it there. Sorry for offtopic.

Schamschula: And the ports tree it's using is the one in /usr/ports?

Nope: /usr/local/poudriere/ports/default/

Exactly, so anything you modify in /usr/ports will not be considered

poudriere will never ever look in /usr/ports/Mk/bsd.default-versions.mk

and you are NOT supposed to edit that

Good catch! It did get updated.

use /usr/local/etc/poudriere.d/jailname-make.conf

you put stuff like DEFAULT_VERSIONS+=php=8.2 in there

Sure. Manually editing that would cause issues with git.

in your case it would be /usr/local/etc/poudriere.d/132amd64-make.conf

For the next couple of weeks. I'll updating the server to 14.0 after I turn in the final grades at the end of the semester.

my poudriere VM does not have anything in /usr/ports because why waste 1 GB+

The /usr/ports is still there from the days I used portmaster

seems like samba413 is deprecated

so do i just pkg uninstall samba413;pkg install samba416?

that sounds like something that may cause an issue since it's joined to AD