Fórum The FreeBSD Forums

What happened in Chernobyl is a long-standing interest of mine; I saw all the original news reports when it happened, and we had warnings where I lived at the time not to drink the milk because the radioactive cloud was over the country and it had been raining. I found this video, about the first internet server to be set up in Chernobyl (actualy, Pripyat) following the disaster. Of course, this was still in the early days of the internet. He mentions from around 8:00 in the video that the first internet node was created at the end of 1996, consisting of a few FreeBSD servers; he says the website stayed online until 2015. This was the first public internet node created for Chernobyl, and the servers were actually sited in the centre of Pripyat, in the middle of the exclusion zone. At the time this was an important scientific infrastructure, as international efforts were made to monitor, understand and control the disaster. Quite interesting, and a reminder of how things used to be. It's good to know that FreeBSD played an important role, clearly they needed something that worked reliably. It's also pretty good to be typing this on another FreeBSD machine, 30 years later! View: https://www.youtube.com/watch?v=iZKw2H6d1SU&list=PLxAcrYn0Q03-EeVhdN3_OuTiXbO8p0MjB

When people advocate the use of "bectl activate -t", they are usually either vague about the benefit or they mention getting back to a BE with working remote access. I'm wondering about how well it protect against an early lockup or spontaneous reboot. Ideally the fallback BE would start first, clear the setting, and then chain the temporary BE. If that doesn't happen then it's a matter of how early the activation is cleared - before loader.conf is read would be a major benefit.

TL;DR: make sure you have the latest version of the ports tree, this commit fixes the issue by switching to the crates.io CDN https://codeberg.org/FreeBSD/freebsd-ports/commit/bc18f00c490cd54dfe38e2d94d8c4feae2815f0f . I'm keeping the full story here as reference to what I had to do to figure it out I had a working port for an earlier version of chhoto-url but now I can't get past make makesum after trying to update the Makefile to the latest release. I'm not using poudriere. Code: > ls Makefile Makefile.crates distinfo files/ pkg-descr pkg-plist > doas make makesum /!\ chhoto-url-7.7.0: Makefile warnings, please consider fixing /!\ Not validating first entry in CATEGORIES due to being outside of PORTSDIR. Please ensure this is proper when committing. ===> License MIT accepted by the user /!\ chhoto-url-7.7.0: Makefile warnings, please consider fixing /!\ Not validating first entry in CATEGORIES due to being outside of PORTSDIR. Please ensure this is proper when committing. ===> License MIT accepted by the user ===> chhoto-url-7.7.0 depends on file: /usr/local/sbin/pkg - found ===> Fetching all distfiles required by chhoto-url-7.7.0 for building > make cargo-crates > Makefile.crates > doas make makesum /!\ chhoto-url-7.7.0: Makefile warnings, please consider fixing /!\ Not validating first entry in CATEGORIES due to being outside of PORTSDIR. Please ensure this is proper when committing. ===> License MIT accepted by the user /!\ chhoto-url-7.7.0: Makefile warnings, please con

I'm on an ASUS Zenbook 14 OLED UX3405MA, Core Ultra 7 155H, Meteor Lake-H with the Arc iGPU. I sent the project two full hardware probes already, back in August and December 2025 — dmesg, kldload logs, the panic traces, all of it. Not attaching them again, they should be in the archive under my earlier posts if anyone wants to check. What I actually do on this machine is photo editing — GIMP, darktable, RawTherapee. No video encode, no OpenCL. So all I need is i915kms loading stable and Mesa/iris doing its job for the desktop, that's it. I saw drm-kmod 6.12.85_2 back in June claims a Meteor Lake fix (#418), but people posting after that release are still hitting black screens and force-probe panics on this exact chipset. So where does that actually leave things right now — is it holding stable for anyone on Meteor Lake with 6.12.85_2 on 15.1 or 16-CURRENT, or is it still a coin flip? And is there an actual version being aimed at for this — 6.13, 6.14, whatever — that I could watch on GitHub, or is it just "whenever it happens"? I'm not asking for a date, just something concrete to follow instead of guessing. Last thing — for someone who never touches VA-API or OpenCL, is there anything else still broken on Meteor Lake beyond the display driver itself? I'd genuinely rather hear "nobody knows yet" than get pointed at another thread that doesn't answer this. Already been down that road a few times.

I am trying to set up queuing on my interface. It seems I can't use only PF for it because of ALTQ (altq not being implemented for USB ethernet adapters?). So it seems like I need to set up a dummynet+ipfw for queuing first with fq_codel, and then PF will process normally. Can I order the processing with pfilctl so it goes ethernet ipfw pf? Has anyone chained up and re-ordered packet processing that way before? [what a confusion that pfilctl is NOT related to PF firewall] Seems also that that order of hooks needs to be set manually because otherwise it just puts it in the order that kernel modules are loaded. So what's the way to order them up on boot via rc.conf?

I'm running 15.1 on a 6-core AMD system I built years ago. It has 32 GB of memory and a 256 GB NVME SSD, GPT and ZFS. Also in the case is a 2 TB Seagate mechanical SATA disk, that I use of local backups and archives, also GPT and ZFS. This system has been running for 2 or 3 months flawlessly since I installed FreeBSD, replacing the Arch Linux system that was installed before. Flawlessly until today. While I'm working, I periodically run a backup script that rsyncs my home directory with a backup directory on the Seagate. Today, when I tried to do this, the script just hung. The chatter on the console said that there was a catastrophic hardware failure on the backup disk. I tried to reboot the system but was unable to do so. Finally, I pushed the reset button and that seemed to start the reboot process but that hung with a blank screen. I tried that twice, no luck. So I power-cycled the system. It came up normally. The ZFS pool on the Seagate got mounted properly and everything is there. I was able to run my backup script and have been using the system for a few hours since the hiccup without any issues. Because of the inability to reboot with the reset button and that power-cycling the machine was necessary to restore order, I suspect that this was a hardware issue or perhaps a driver issue getting the hardware into a wedged state. Anyone seen anything like this? This machine has been dead reliable for years (yes, I do understand that past performance is not a blah, blah, bla

I'm trying to build an app stack on FreeBSD using hierarchical vnet jails. It looks like this: Code: HOST + JAILS + lb_jail + backup_jail + dev_jail + stage_jail + prod_jail Within each [dev|stage|prod]_jail, I will have: Code: [dev|stage|prod]_jail + webserver + database I am still building the the first part of this and haven't gotten to the hierarchical jails yet: Code: HOST + JAILS + lb_jail + backup_jail My jails are in 10.0.0.0/24. I have tried including this net range in my 'martians' list of unroutable addresses to protect my external interface. But this leads to the jails losing external internet access (pf.conf below). Is there a way do differentiate traffic on my internal 10.0.0.0/24 network ($jailnet) from outside unroutable world traffic on 10.0.0.0/8? I'd like to still block baddies on the outside, but allow my internal networks full connectivity. Additional questions to show how little I understand about networking: Q: I've read that lo0 is short for local 0 , and is a virtual interface. I've also read that creating a bridge is 'cloning' the lo0 interface. Does that mean that all virtual interfaces can see each other? What about if they are on different subnets, e.g 10. and 192.? If I create bridge0 on 10.0.0.0/24 and bridge1 on 192.168.1.0/24, can these two subnets talk to each other? Should they be able to? Or say it was 10.0.0.0/24 and 10.0.1.0/24, what would we expect there? My expectation is that the examples above are different network segments and should

Original article here. Consider this when replying. FreeBSD, The FreeBSD Foundation, and The FreeBSD Forums are not associated with the content of this article.

Working amazing with no hanging

The specifications of the PC can be found here ; it's an amd64 motherboard. I did install FreeBSD on it successfully many years ago, version 12 or 13, I don't remember exactly. I decided to revive it by installing the latest version, 15.1. The installation goes well but after rebooting when the installation has completed I see message Loaded only 545k in a loop on the screen. I tried installing version 14.5 but the result is the same. Please let me know if you want me to provide more detailed information on the hardware, for example the output of program dmidecode that I can run from a Linux installation flash drive. Thanks in advance.

I would like to run Agisoft Metashape on FreeBSD to build 3d point maps for photogrammetry. I have a licensed copy that used to run on void linux without systemd. I have read the handbook chapter about Linux Binary Compatibility and get the impression that I can only install linux programs from ports tree. It this this true?

An idea. A suggestion, perhaps. It depends on XenForo, I guess, but one can dream. Edit: It's happened twice very recently.