AmyMalik, We all are! Some are just luckier than others.

I mean, Xfwm4 and Fluxbox cause a memory leak on my Xorg, Openbox instead stands on the CPU core, and I just had to patch lighttpd so it would support `SO_SETFIB`.

Interesting that you mention a memory leak since I am hitting one in a tool (which I mentioned above and don't want to trigger the port maintainer by mentioning it again until I can spend some time looking into it). It does make me wonder now if something more deep is happening regarding memory.

Why does lighttpd need SO_SETFIB? That doesn't sound like the result of a curse though. No plague of locusts. No rain of toads.

rwp, It doesn't. I do, because I have two default routes.

rwp, I was offline for 15 minutes until 09:31 UTC due to network problems (self-caused); how "above" did you mention? Feel free to DM me if needed.

do you really need to set fib on socket level or is on process level via setfib(1) enought?

nimaje, Essentially it was easier, for me, to do it this way, than to try to run two copies of lighty, which would've needed me to maintain two entirely separate config files.

AmyMalik, Re: how "above" did you mention? "15:50 -0700 <AmyMalik> I think that I am cursed." But I didn't see anything cursed before that in the scrollback.

I have successfully avoided needing to deal with multiple upstream routes. I think if I did need to deal with it I would deal with it at the router level. Maybe use BGP for it.

rwp, I can't find out which tool you're hitting a memory leak in.

multitail on 14.3R tailing about 5 very active log files. Check out the swap use graphs: proulx.com/tmp/multitail-memory-leak.png

The saw-tooth is when I quit and restart it. In between if I leave it running then over the course of a week the program just eats up memory. Nom, nom, nom.

that's not ideal...

It does not eat memory on other systems. Easy workaround is to 'q' and restart it. So it is no big deal. And when I get some free time maybe this next week it should be an easy debug.

my first instinct is to think that it's either something about scrollback (if it stores that in memory) or something about how it accesses the files

It was really only a problem before I was aware of it happening. The system ground itself into a completely out of memory state and then had some failing processes. Now that I am aware of it I make sure I don't put it into that out of memory state. Since multitail is for me monitoring the AI Scrapers and other botnets hammering away.

confession: I just use base tail(1) -F pointed at my logs

i liked splunk.

i mean, centralized logging in general

makes sense

my only "centralized logging" is non-real-time reports (/etc/periodic)

pkubaj, hi! can you test build on ppc* sysutils/mods? bugs.freebsd.org/292305

Thanks!

VVD: go is currently not supported at all on freebsd

there's a wip for that

ok, thanks

if go ends up supported, it will be only 64-bits anyway on power

any guides on configuring a freebsd laptop for use in dual-stack, ipv6-mostly and ipv6-only networks with clat? so if the network has some NAT64 I want to use it, but if there is none then no client side translation should take place

nimaje: it just works

I mean FreeBSD in NAT64 + DNS64 environment

i think nimaje is asking about doing CLAT based on presence of PREF64 advertisement, which isn't (as far as i know) currently supported

i'm not sure we support CLAT in that way at all, actually... ipfw has some support for it, but from reading the manpage, i had the impression it was intended for use on a CPE router, not a single end node

it might be interesting to look at how Darwin implements this, perhaps there's some code we could steal

isn't darwin closed?

okay alright thx for the tip

mzar: exactly as ivy says, I want dynamic support for NAT64 based on what dhcp tells my system, as I understand the ipfw man page I could configure it statically to just always do CLAT, but then what if I'm in a dual-stack network that has no NAT64? (Or in a IPv4-only network, but I guess that is rare)

nimaje: OK, I am not using it, for me IPv6-only networks just work when I am using laptop with FreeBSD

I am implementing them with dns/undbound using its dns64 module and NAT64 on the gateway

probably configured with DNS64? and what about IPv4 literals? (that's why you want CLAT and as extra you don't need DNS64 any more) and what about IPv6-mostly networks?

has anyone tried the rtl8221ce driver on freebsd15?

You taking a poll, or did you have a question?

nimaje: please let me know if you try ipfw CLAT and get it working for local applications, because i was very confused about how you would do that based on the manpage

nimaje: i was thinking about adding nat64 prefix as an interface attribute (accessible via netlink/ifconfig, like on macOS) in the hope someone might write the necessary userland parts to make it work

ivy: My bad.

I wish there were an easy IRC-undo button sometimes

I think I'm in an ipv6-mostly network here, so I should try to statically configure CLAT for tests and the nat64 prefix as interface attribute seems like a good idea, I'm definitly on board for testing, not so sure about writing code

if ipfw can do this, we could potentially even add a new syntax to use the auto-configured nat64 prefix for it

wavefunction, IRC and e-mail have that advantage: you cannot unwrite your words.

nimaje: why do you want CLAT ?

AFIR CLAT is implemented only in Android

it is supported by Android, iOS, macOS, and Windows (the latter only on LTE for now, but they're testing support on Ethernet)

Windows ?

Preview, thanks for sharing ivy

it's been supported on LTE for years since a lot of mobile carriers require it, the new feature is supporting it on Ethernet

ha.. first you need to find mobile carrier with ip6 support

and in my country only one of four seems to be competent enough

v6-only-preferred aka DHCP option 108 seems to be respected by Android phones sine a longer while

we are sending it to wireless clients and Androind phones after receving it don't negotiate DHCP lease further

mzar: because clat makes sure that stuff works, no matter where the ip addresses come from, DNS64 only works if DNS is used and you have to make sure that DNS64 is used

nimaje: CLAT will only work if router, ip6 gatway, implements NAT64, so yes, you can probably CLAT by hand, using either IPFW or PF

let me check

hm, with my test ipfw nat64clat test create clat_prefix 64:ff9b::/96 I get "ipfw: ipfw_ctl3 invalid option 160v0" and "ipfw: nat64clat instance creation failed: Invalid argument"

hello, does rtw88 still not work properly in freebsd 15?

ah, you have to load the ipfw_nat64 kernel module, but still no idea how that whole thing should work from the architecture view point, where would I add routing rules to route ipv4 traffic via that clat instance?

nimaje: you have confused the clat_prefix and the plat_prefix (64::ff9b::/96 is the well-known plat prefix)

they have to differ? can I just use anything as clat_prefix? or do I have to figure out some specific value?

you can theoretical use anything as long as your plat provider is able to route this address to your host

ok, seems like ipfw nat64clat is only meant for 464xlat, not to have a host level clat to have only ipv6 on the host with a nat64 in the network to make stuff like ping 9.9.9.9 still work

hey is anyone available to help with a ZFS question I have?

just ask the question directly and we may find out

long story short, I scrapped together a server at work for a pet project and I just accepted the defaults for ZFS install for a single drive. So the ZROOT pool is a single drive. I just got two SSDs that i want to transfer my existing pool onto. My current plan of action is to simply create a new pool with a mirror vdev and zfs send to this new pool (i plan on retiring the single drive aka the current pool after this is finished)

what do i need to do to properly transfer the boot info/partitions to this new pool?

TLDR i basically want to completely transfer the system's pool to these new drives (single mirror vdev) - is ZFS send the right tool for this?

nimaje: with PF it almost works, (packets are translated, and replies are coming) but the software is dumb

so either this self-hosted CLAT NAT46 doesn't work or we need something more to convience the OS that this returned ip6 has be translated back to ip4

if you're doing "pass out ... af-to inet6", it may be that doing af-to on out rules is less tested than on in rules (i reported one issue with this using af-to inet which i think was fixed)

ant-x: Yes, "cannot undo" is a feature, I agree. Maybe what I dislike is per-line history in my chat client :-D

thermos, zfs send would do the trick, but if you wouldn't mind still using the old drive + one of the new, it would be a lot simpler to add a new drive to the current single drive vdev, so you reuse the same pool

easier and probably faster

also remember that if you boot from there, you have to install the bootcode to the new drive too so it can boot even if the original drive is dead

thermos, also, there is one footgun: use "zpool attach", do *not* use "zpool add"

that mistake used to be non-recoverable, these days it is recoverable, but a headache

actually even if you want to use only the two new, the smoothest pipeline is 1) zpool attach newdrive0 2) zpool replace olddrive0 newdrive1

Does anyone here use Podman?

I'm wondering, for Linux stuff, should I do BSD -> bhyve (for Linux) -> Podman -> *, or BSD -> Podman -> bhyve -> *

The former is kind of what Windows / Podman Machine does, but AFAIK, podman machine isn't supported yet in BSD (unless that changed recently)

never heard of Podman Machine

funtune: thanks for the reply - yes i figured simply adding a drive to the existing pool would be easier since i could then make it a mirror, but the current drive is 500GB while the 2 new ones are 1.92TB

looking at using podman soon, though, to run some Docker Compose garbage

hodapp: docs.podman.io/en/latest/markdown/podman-machine.1.html

Same as Docker Machine, just podman.

TL;DR it's host -> VM -> Podman instead of host -> Podman

Podman (and Docker, via Docker Machine) use it on Windows, for example --- Docker & Podman there use wsl2.

So it's basically Windows -> Hyper-V -> Linux -> Podman|Docker

(Windows just hides most of that)

EXCEPT FOR WHEN IT DOESN'T

True.

reading through your messages, you're suggesting i do make the existing pool a mirror by adding one of the drives and then simply replacing the old drive and let zfs do the heavy lifting?

funtune: can i do this given that the original and new drives are different sizes? for some reason I have it in my head that mirrors have to be of drives of the same size

Is this how i transfer the bootcode gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada2? This is from the Handbook section 22.3.5 - if so, do i simply replace 'ada2' with both of the drives I would be adding?

thermos, as long as the old drive is smaller, the size mismatch is not a problem

you can tell zfs to expand to the full extent of the drives afterwards

for the bootcode, that looks correct to me yeah. Yeah you'll have to run the bootcode command twice - attach newdrive0 - bootcode newdrive0 - replace olddrive0 newdrive1 - bootcode newdrive1

and zpool set autoexpand=on poolname *should* expand the drives to the full extent

wavefunction, you dislike per-line history? You an avoid using that feature, can't you?

thermos, do you use swap? You may want to set up mirroring for the swap partitions, too, but using GEOM raid instead of zfs since it's very discouraged to swap on zfs

okay thank you much funtune, I'll give it a shot. Much appreciated

if so you'll probably want to format the drives before attaching the partitions to zfs, so that you get whatever size swap partition you wanted

gpart show shows 4 partitions on the current disk, 1- efi 2- freebsd-boot 3- freebsd-swap 4- freebsd-zfs

right. So just redo the same scheme on the new drives, and zpool attach the partition corresponding to freebsd-zfs to the pool

if you want to keep having swap, I mean

you can sort out the GEOM raid mirror for the swap partitions later, it can wait

okay so i should create a partitiontable on the new drive before zfs attach, where 1,2,3 are same size as the partitions on the current drive and the 4th partition is the remainder of the drive to attach via zfs

precisely so, thermos

if you want to be really cool and safe you can also give the partitions gpt labels and use attach gpt/label1 instead of attach newdisk0 etc

do i need to dd the partition's contents from the OG drive to the new one? or does something else take care of that like gpart bootcode - or does gpart bootcode only update the 'freebsd-boot' partition?

thermos, is this a bios system or efi?

Dell r640 - pretty sure I have it using efi

okay - I have no first hand experience with that, the server I did this to was bios, and I think it might be different

better check the handbook about that

I mean, just the bootcode part

Okay will do. Do you think I would need to make this partition table on both of the new drives as I attach/replace them?

yeah you should make partition tables on both new drives before you attach/replace

Okay, so really the only question I think left is: what exactly does gpart bootcode do for me and what do i need to manually do - and I should probably see what i can find in the handbook/man pages

thermos, I'm not sure what gpart bootcode does on efi systems :/

funtune: thanks again. I suppose I could force the r640 to use BIOS - it seems like you had something you were going to mention if I was on a BIOS system, anything in particular that you had to deal with on BIOS?

The desired configuration is that the system should be able to boot even if you yank a drive. That works fine with bios if both drives have bootcode. But with EFI, it's kind of weird since the EFI system partition needs to be FAT, and I'm not sure if any given machine supports giving it raid

maybe it works fine? But if only one drive has an EFI system partition, certainly the system can't boot without it...

thermos, it's all good on a bios system, nothing more to say :)

perhaps somebody else knows if EFI implementations are usually able to deal with GEOM raid under the EFI system partition... or similar?

okay thanks funtune, I'm gonna read up on the gpart bootcode - if you're interested I can let you know what I end up finding out

great thermos! If you want to call my attention to it, make sure to spell my name without the extra n :)

I'd love to know how it turns out

ohhh I was wondering what was going wrong in my mentions, LOL I scanned your name multiple times and never realized. Will do

you're not the first, no worries :D

futune: the disks I am adding are newer (relative to the current disk) and they report 4096 block alignments - whereas the OG drive does not. I would like to respect this and set 'ashift=12' for ZFS but the docs say this can only be done at pool creation or when adding a vdev

so if I attach/replace I assume that I won't be able to change this since as far as ZFS is aware, i'm not actually adding a vdev right

thermos, I was right there with futune and thinking that replacing the new drives into the system was the best way but with both UEFI and AF partitions perhaps it is best to install fresh on the new and zfs send|recv from old to new. Mason has some nice documentation on this area, let me point you to it.

thermos, wiki.freebsd.org/MasonLoringBliss/ZFSandGELIbyHAND

If nothing else it is good general documentation on this topic and good to have available.

Okay thanks rwp, I'll take a look now. After reading 'gpart' manpage I found an easy way to transfer the partition tables is via 'gpart backup da2 | gpart restore -F da0 da1'.

If the drives being backed up are 512 byte and the new drives being created are 4K AF then that won't work, unfortunately.

thermos, I'm afraid that's accurate - you can not change ashift on the vdev if you use attach/replace :/

but do check if the vdev was actually provisioned with ashift=9, it might have been done with 12 for future-proofing (precisely because of this scenario)

Good point futune!

thermos, You can somewhat use gpart backup of a 512 byte partition for use with a 4K partition by dividing each of the numbers by 8 and then use the modified backup.

yeah the results after backup/restore had some '- free -' spaces between partitions, I assumed that 'gpart' was just making stuff work behind the scenes

What are the correct keys to use for pkg update on a 15.0pkgbase installation? I've got some using /usr/share/keys/pkgbase-15 and ports /usr/share/keys/pkg

the current zroot pool is encrypted with GELI encryption - if i understand correctly, this is simply a layer on top of the underlying ZFS filesystem?

thermos, almost certainly *under*, by which I mean that the pool is created on the GELI plaintext abstraction, i.e. zpool -> geli -> physical drive

Since "zpool get ashift zroot" just says "default" here I suggest "zdb -C zroot | grep ashift" to get the current ashift value for the pool.

thanks for clarification futune, and rwp I was just trying to figure this out as mine says '0 default' so thanks! for somereason 'zdb' "can't open 'zroot': no such file or dir" so I'm looking into this..

ah found it at '/boot/zfs/zpool.cache' vs the expected '/etc/zfs/zpool.cache'. Turns out I'm in luck! The pool is already using ashift=12. Now I just need to get this partitioning funny-business sorted.

thermos, just to have it in the toolkit: I guess I found the same invocation as you by searching, but the one rwp gave is nicer because it doesn't refer to any cache file!

Agreed, however simply copy-pasting rwp's suggestion I got this error: "zdb: can't open 'zroot': No such file or directory" and I looked at the docs for 'zdb' and found that it looks for a .cache file in /etc/zfs/ yet mine was in /boot/zfs (couldn't tell you why)

so i just had to do a '-U /boot/zfs/zpool.cache' at the end ;)

futune: since these disks are much larger than the original disk, do you think I should zfs-attach the partition of the new disk at the same size as the original one? Then after attach/replacing and fazing the original one out, i 'gpart resize' the zfs partition on both of the new disks?

thermos, the partition should be the final size you want from the start

just skip the gpart resize step

zfs doesn't mind

10-4

I guess you have to stick the geli layer on there before you attach though

thanks for reminding me, was a few keystrokes from attaching haha