thresh: ive implemented a fix for the branch you're tracking (re pkg) and it should show up within an hour or so for you

thresh: there were a couple of others that were impacted that are already fixed/live

"known issue" being the gigantic data file size?

(Not trying to snark, just validating my understanding)

wavefunction: yes

zi: would you mind to show a link to the relevant commits?

gbon121: his resolution would have been outside repos in cluster/builder config, iirc

does anyone else have problems fetching packages from the FreeBSD package mirrors right now?

i get "Error 503 Response object too large" trying to upgrade thunderbird

for this URL: pkgmir.geo.freebsd.org/FreeBSD:15:a…/thunderbird-153.0_1~2$zmpyrrq1.pkg

Hi, I have a frew question about HAST.

1). I'm not sure if I should se the `memsync` and `async` algo. The secondary machine will be in a different geographical location, so ping time of <50ms would be some good times.

Does `memsync` validate first local write when first block is set to arrive to the secondary or when all blocks actually have arrived over the wire and are set to be written to the secondary?

2). Did I understand correctly that HAST auto-configures a secondary machine to be primary in case of sustained timeout of the primary machine? If so, is there a way to turn this behavior off?

*if I should use the `memsync` _or_ `async` algo.

memsync means the remote machine acks the write the moment it has received it

async means the local machine doesn't even wait for the remote machine to see the write

with 50ms latency waiting a roundtrip means disk sync write performance has to suck

because what takes <0.1ms on a local nvme drive now take at least 500 times longer

with memsync the remote system still has to see the write and send back a success message

unless you're in a really nice datacenter network that will take longer than a write to a local ssd

iirc hast has no builtin automatic failover. you need something else e.g. consul, etcd, etc. to trigger the failover

remember two nodes can't form a consensus

you need at least 3 systems so that the remaining two can form a quorum

(or for five for better redundancy)

Ah ok. Yeah so I could live with the fact if memsync just acks a write at the moment the 1st block gets sent over the network, but otherwise in my case it would most likely be best to choose async and some mechanism to alert me of prolonged dirty extents on the primary.

There will just be 2 machines, and it's going to be pretty obvious if either of them is down, so I'll just prefer to set primary / secondary role myself.

async runs the realistic chance of corrupting the hast "disk" if something goes wrong

if you write on your current master device and fail over

and the disk was being written to

you will see writes being lost

file systems don't like that

and applications don't like it either if you "undo" writes

e.g. upload a file, failover, fsck the filesystem/force import the zfs pool

and the file you wrote is lost forever

is that an acceptable behaviour for your usecase?

also why do you want async aka best effort replication at the block level instead of at the file level?

Morning, trying to run /usr/share/examples/bhyve/vmrun.sh -v -c 1 -m 1G -E -d /dev/zvol/build/vms/9front -i -I 9front-11554.amd64.iso 9front I get Assertion failed: (error == 0), function modify_bar_registration, file /usr/src/usr.sbin/bhyve/pci_emul.c, line 708.

I've read that error did appear when some folks try to do some passthrough, but it's not my case, any pointer would help me, I tried to follow wiki.freebsd.org/bhyve/9front and have the same issue

does ist work if you follow the steps exactly without vmrun.sh?

and which freebsd version are you running on your host?

crest_: Yeah async has some definite downsides, although it's still probably a better than "send daily zfs snapshots" which I had in mind before learning about HAST.

i would recommend just doing more frequent zfs snapshot + send

there is nothing wrong with a snapshot every 5 minutes that gets destroyed as soon as it's received

just don't keep too many because deleting them is annoying and they clutter the cli output

funnily the cheapest thing about a zfs snapshot is creating them

> just don't keep too many because deleting them is annoying and they clutter the cli output

That was one of my concerns as well, but this sounds like something that some scripting might solve. I'll definitely reconsider ZFS snapshots.

crest_ nope, doesn't run with the exact steps in my case, I'm running 15.1

pkg: pkgmir.geo.freebsd.org/FreeBSD:15:a…d/qbittorrent-5.2.3~2$ci5shz6g.pkg: Service Unavailable

something weird going on here lol

pkg: pkgmir.geo.freebsd.org/FreeBSD:15:a…ashed/go125-1.25.12~2$w83fwpg1.pkg: Service Unavailable

ditto go

whats with the $ strings in them

oh because they are hashed...

Error 503 Response object too large

yeah all large ports are unable to download, someones fucked the webserver config

polarian: mastodon.social/@_bapt_/116962204010624175

the problem is known the the right people and in the process of begin fixed

the scripts are running and there is nothing you can do speed it up

crest_: nice!

thx for the info

crest_: out of curiosity can you explain what is repo?

I assume its a tool

repo = short repository

a repo is a collection of packages and meta about those packages

the format of the metadata was extended to allow asking the repo which package would install a specific file

you can already run `pkg which $file` to find out which package (if any) has installed it on your system

but a new `pkg rwhich` (short for remote which) command would be able to answer which of the packages inside the repo would install the file

without having to install all packages first

the problem is that this feature caused the metadata size to explode

explode to such a degree that the content delivery network that hosts the packages refuses to deliver the bloated files

yeah that makes sense :)

crest_: what does bapt's comment on repo -l mean?

(sorry to ping again)

polarian: github.com/freebsd/pkg/releases/tag/2.8.0 (search for -l)

oh wait nevermind

I was trying to find "repo" but I didnt realise it had a "pkg-" prefix to it

also this isn't the first time that pkg has broken in the last few years due to an update

I remember a while back some SQL error

thanks again for the great explanation!!!

will move my follow up question to #pkg :)

wiki.freebsd.org/clusteradm can someone explain to me why the example layout is designed like this :3

im interested

All I can say is that I'm stealing that Moss gif.

hi friends

anyone have some ideas what to check: sometimes the laptop wakes from s3 okay, but if it sleeps too long, it goes into a cold boot

is that a bios setting?

o_O

In my day S3 was a video chipset. . . kind of a pain in the ass video chipset.

i remember s3

It foolishly parked its fat ass on 0x2f8 I/O address space, same as com2 defaulted to.

Spent *A LOT* of time when I wokred at MS supporting Win95 working around that on people's systems.

The only worse piece of hardware was this sound card that wanted !!*THREE*!! IRQs.

thanks zi, it seems to work fine now

thresh: welcome, sorry about that

no worries, mistakes happen

its kinda cool that you guys run the infra on the latest and greatest

Oh, those weird DDOSes on hosting companies and other stuff happened for me were made by KimWolf DDoS botnet

owner arrested on end of may justice.gov/usao-ak/pr/canadian-man…charged-administrating-kimwolf-ddos

that's a bit sad. the time should match the crime and i dont think thats gonna happen. probably looking at decades if not life.

bsdrobert: Says he's only facing one count and up to 10 years?

Probably a slap on the wrist in the end.

Better fodder for #freebsd-social

meanwhile: bbc.com/news/articles/c62qw1qk95eo

ForeverNoob[m]: haha, yeah the Moss gif is amaqzing

ok, I guess I'll ask here even though it's probably me not knowing a thing...

I'm trying to get an IPv6 IP via SLAAC on a box. restarting rtsold shows router solicitation and advertisement on a link-local addr. There is one thing on the link-local broadcast that isn't me. Prefix len is 64, default gateway should be ::1

After neighbor discovery with the same IP that sent the router advertisement, it stops and nothing more happens

starting dhcp6c gives me three rounds of neighbor solicitation for my hostname/subdomain/... on the link local broadcast, I think?

(this is looking with tcpdump)

What have I done wrong here?

for the nic, nd6 options=8023<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL,DEFAULTIF>. I have a link-local addr but only that

starting rtsold with flags -imF [network interface here]. ipv6_activate_all_interfaces="YES", rtsold_enable="YES"

ifconfig_myinteface_ipv6="inet6 accept rtadv"

What else do I need to do?

I've also tried ifconfig_myinteface_ipv6="inet6 accept rtadv prefixlen 64", seems that 64 is the default

It is for for v6.

And should be used for any segment/VLAN/prefix with endpoint devices.

The commit in question severed our

ports tree mirroring to github.com due to their filesize hard limit of 100MB,

and introduced a blob of questionable licensing into the repository history.

Why did that paste in 3 lines? I wonder what they mean by a blob of questionable licensing.

Macer: just a binary that we don't really know we can legally redistribute like this

Thanks kevans, makes sense

we don't know and we already need it purged anyways because of the size, but we wanted to make it clear that size isn't the only concern

"It is for for v6." What does this mean?

I know this is for IPv6, IPv6 is the point of the exercise here

Oh, you mean the prefix length

> default gateway should be ::1

Indeed