recently I have installed one ARM64 vServer and I am seeing ping times to localhost in the rage of >20ms ... whereas on a virtualized AMD64 it's more like 0.020ms

does anyone else see that problem? could it be specific to ARM64?

gustik: i've never seen that on native arm64, but i've never used virtualised arm64

yes, that's the clue

which virtualization technology?

maybe this virtualization is not that ready... I did not try this on Linux before I reinstalled

it seems to be KVM

NetCup is the provider

they say it's KVM

and I see VirtIO (RedHat) all devices, so my guess it's that

looks like this:

ping localhost

PING(56=40+8+8 bytes) ::1 --> ::1

16 bytes from ::1, icmp_seq=0 hlim=64 time=0.137 ms

16 bytes from ::1, icmp_seq=1 hlim=64 time=26.078 ms

16 bytes from ::1, icmp_seq=2 hlim=64 time=10.273 ms

16 bytes from ::1, icmp_seq=3 hlim=64 time=14.480 ms

same on IPv4 localhost

I have tried to disable PF and run it as bare as possible now and it's still there, so it was there from the start I suppose

since it is not that stable, always jumping up and down, it may not be a bug but may be correlated to the load there is on the host

second what came up to my mind is, since this has 18 cores, it may be that it tries to distrubute the ping/pongs among the cores and that the communication between them takes variable time

I don't think that should be a problem

me neither

that's why it is very strange

OK I SOLVED THE ISSUE

I rebooted with control panel setting of ONE CORE ... effectively disabeling SMP and it came up with one core (1CPU) and now the ping times to localhost are stable at 0.05 ms

huh, can you create a bug?

no

I think it has something to do with the speed it is transferring among the sockets

I will then set it back to 18 cores, but ALL on one socket

14ms is a long time

ping 1.1.1.1

PING 1.1.1.1 (1.1.1.1): 56 data bytes

64 bytes from 1.1.1.1: icmp_seq=0 ttl=56 time=543.336 ms

64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=815.054 ms

64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=19.799 ms

64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=91.905 ms

I was about to say its almost as long as my rtt to the internet, but theres something up with my ethernet here

because it seems that this hold-offs which the server is suffering (unexpected stop and goes) are due to the context switching among the packages

now with one core enabled I have localhost worst care of 0.2

case

OK, maybe it is a bug, but not a freebsd specific one

this seems to be a KVM or even hardware issue

with one core it works fine

ideally we would have a tool users could run

so you could point the finger at netcup

I am going to eat now

I will remember to check on it later

bon essen

yes

i really wish make update-packages could be faster

my last build, 52 seconds buildworld, 25 seconds buildkernel, 455 seconds update-packages

that's on 2x SATA SSD in zpool mirror

is gcc for linux amd64 gone?

i remember using it in the past for cross compile

sopparus, amd64-*-* is an alias for x86_64-*-*

yes, but amd64-gcc14-14.1.0 Cross GNU Compiler 14 for FreeBSD/amd64 is the only thing i found

that is not for making linux binaries

right

?

in the fast there was this gnugcc-linux-thingy

past

not sure, haven't cross compiled decades.

container with linux is easier

or virtual machine

I have spotted interesting glitch, the clock was set to 2225 year and in this situation autodealay in during boot doesn't work, the counter will not decrease

tsoome_: ^^^^ - it's probably not any bug, and I am not goint to submit any PR

aww.

bios or uefi boot btw?

UEFI

the counter is really about time we do get from firmware.

I wondered why one of 16 machines behaves this way until it had to update packages, https and certs will let you know when the clock is set 200 years in the future - so the mystery of not decreasing conuter got demystified

Would it make sense for bectl to set a property indicating the current zfs/zpool version, and for zpool/zfs upgrade commands to check and warn if you have boot environments from older versions? Since a zpool upgrade will make older BEs useless..

you can still use them, especially data from them

Data yes, but you can't boot

Howdy Friends

sometimes, you can rewind and boot, sometimes not

the XFCE is neat DE but it wont let me change the Wallpaper

XFCE is one of favourite DEs of FreeBSD users

if you run zpool upgrade, you also need to update your boot blocks, as simple as that

Well zpool upgrade could be smart enough to see if the different features have been enabled/used, thereby rendering boot impossible.

i want to rebuild all noauto packages installed but from ports to suit my needs. I *know* poudriere is de-facto a standard tool for this but i do not want to use it. I just want to go through all the steps. What be be a way - also maybe building them in dedicated jail?

No you don't, necessarily. And new bootblocks do not prevent booting older kernels. Upgrading zpool+enabling/using new features can.

Ltning: that's sysadmin who could be smart or nto

we do not support booting with only few features (draid for example). so, in general, you want to make sure your boot blocks are updated.

Ltning: you can always send this data to thee other pool and boot it or rewind to checkoint what should allow you to boot

tsoome_: The boot blocks are not the issue here. Those are backwards compatible.

But I guess consensus is that having that additional safety net is not worth it - whoever ends up making their pool incompatible with existing BEs only has themselves to blame and has to deal with it.

yep

I find that a bit harsh - we tend to have the safety on by default for most foot-cannons in the system, and this would seem like a sensible thing to check for given how actively BEs are touted as a rollback capability above and beyond mere snapshots.

the thing is, there is no way to know if you have somewhere the kernel with old zfs or not. Also, in general, there is little point to keep very old BE's around. So if you have *decided* you are going to upgrade your pool, you want to be sure you do not want to *boot* those old BE's any more.

I just proposed a way to know - set a property when a BE is created, indicating the current version/feature flags.

well, there is compatibility property on pool. if you want to keep yourself from shooting into the leg, you set it.

see zpool-upgrade(8)

Ltning: can you clarify 'Since a zpool upgrade will make older BEs useless'?

it's not yet coffee o'clock so I'm not properly caffeinated, but that doesn't sound like something that's necessarily true

Yea it was a bit of an absolutist statement. What I meant was that once you zpool upgrade, it becomes very easy to render old BEs useless for booting. I'm not sure if zpool upgrade in recent times (since feature flags) has immediately rendered BEs with older kernels unbootable.

And while it is true that a sysadmin "should" know not to do this, it is also very easy to do inadvertently. And for a new or inexperienced sysadmin - or for someone playing with FreeBSD for the first time - it can be unexpected and unpleasant.

It would also allow for some extra safety in situations where upgrades are automated. We were just worried about whether opnsense upgrades automatically ran zpool upgrade; turns out they don't seem to be doing that but it triggered the discussion.

Also when is it not coffee o'clock? If it's irc o'clock it's coffee o'clock. Unless it's beer o'clock, of course.

well it starts when I finally get around to making some :-)

kevans: making some beer?

i also thought that "zpool upgrade will stop older BEs booting" seemed wrong because you'd have to update the loader, but it's true that older kernels might not be able to mount it then

which is different from the problem we usually run into where people update the kernel without updating the loader

I, er, well, er

my specific problem with the statement was that it didn't occur to me what might be special about those older BEs that would make them specifically unbootable, but I get it now

the problem with encoding it as a prop is that that relies on a specific model of BE management that we don't really enforce

one where the kernel/zfs version is effectively immutable in that BE, but some folks also choose the other way of spinning off a new BE and upgrading the contents of *that*, then bootonce'ing it

Yea that's the kind of use case-type feedback I was hoping for

Ltning: don't get me wrong, though, I'm not opposed to some more seatbelts there- I'm just not sure of the best shape

i'd hate to add unnecessary roadblocks to one or the other management style when things are working as intended

i have installed python but there is no way to run it

anyone work on python in BSD, let me know

what do you mean "no way to run it"?

*with

have you installed python ?

yes, but how does that matter?

type python3 --version and give me the output, if that's cool with you

I don't see how that matters to your problem but Python 3.11.11

can you solve my problem, you cant even issue the command I asked you to do

lol you're a real asshole

don't try to be hero okay

Python 3.11.10

how about you read my message again?

okay

cool

I get this

root@yuki:~ # python3 --version

-su: python3: not found

root@yuki:~ #

I'm gonna say you haven't installed python3

okay

it might have been pulled in as a dependency, but you need to install it to use it

root@willow:/usr/local/etc # netstat -rn|wc -l

1199268

the routes, we has them. all of them

okay let me run in spyder

spyder give me wrong result

2^3 should be 8 and it gives me 1

python3 is a package that basically installs the python3 symlink to the current default version of python3 (which is 3.11 currently in the ports tree) and if you stated your problem from the start I would have suggested trying python3.11 --version

okay nimaje thanks

its working now I think

thanks its working

bot in spyder and command promot

sorry I got big agitated

it just too much in my plate

no hard feelings my dudes

I need to get the postgreSQL and MariaDB configured correct, but may be some other time

Anyone else seen OpenVPN creating a new tun device each time it runs?

I'm trying to copy a bhyve vm (done with vm-bhyve) to a different host. I've tried creating (but not installing) the guest on the new host, then rysncing over vm/<guestname> but it's not working. From what I've seen web searching, that seems to be the usual way to do it. I tried the vm-bhyve migrate command but got an error that it was unable to get config from server2.

by not working, I mean I start it on the new host and (it's a Rocky 9x VM) I get a bunch of error messages about services failing to start and then it hangs on Account service failing to start

smr54: so same rocky.conf on both hosts?

smr54 is the vm disk on zfs or a file?

hmm, tarfs could be the tech we need to have our own App Image/App Bundle style distribution of executable for FreeBSD

How much of a performance hit is it?

why would we want that

Why wouldn't we? :)

got my answer, I'm running OpenVPN as non-root.

dvl: can the ending process not delete the old tun device?

rtprio: that is precisely the problem.dpaste.org/bbaAi - however, I've been running with this configuration for years, apart from changing from topology=Point-to-point to subnet.

rtprio yes

getz both are on zfs

Are you perhaps running on an amd zen3 processor?

getz yes. that is what started this. I had vms on an Intel and got an SER5 beelink. Wanted to move some vms to it. Found they wouldn't install on the AMD, so thought I could install on Intel then move guest to the AMD

there was a glibc bug recently when running bhyve would cause an issue

are you able to upgrade the vm on the other host?

let me get you the bugzilla link

Yes, all works fine on the intel. I know about that bug. I don't n eed the link I have it

Ok! Then you know how to fix it

I know the bug, but not how to fix it. Unless this is a different bug

I thought kib's patch fixed it, let me have a look

otherwise you just need a newer glibc in the vm

I think so. And it might be that I have to wait for various Linux distributions to update it.

For example, I can install rocky 9.4, and successfully update it to 9.5, but if I try to install 9.5, it won't install

Florian merged the fix on the glibc patch a while ago and backported it, I thought it was fixed by now

Yeah I know, been there done that :)

It's not a disaster, I have plenty of room on the old machine just wanted to take advantage of the greater memory on new machine. But thank you for the input

hm, I cant find it in upstream. Might just need a ping

Here's the patch inbox.sourceware.org/libc-alpha/87s…qmrz3b.fsf⊙osrc

smr54: I realized that we were talking about different bugs, I was referencing 279901

my apologies. I was going on something I got from the vm-bhyve iste.

Yes, Ihad that bug bookmarked too (the one that you just gave me).

thanks again

time to eat so I'll bid you a goodnight