I'm trying to upgrade from 14.4-RELEASE-p8 to 15.1-RELEASE using the Handbook instructions in 27.8.2.1 (Major upgrade with ZFS) but does not seem like I am getting the same results as mentioned in the Handbook. I have switched to pkg-base already.

sorry

bad collision of text in the buffer there

hi

please help

I upgraded from 15.0 to 15.1 and old laptop with core i5 and GEFORCE 610M, I have X support, but should I install nvidia drivers too?

thanks

how can I check if userland programs were upgraded too?

`freebsd-version -kru`

kru, kernel runtime userland

thanks

I followed freebsd.org/releases/15.1R/upgrading/#upgrade-fu

seems to be kru=15.1-RELEASE-p2

ibs: seems ok then

ibs: but I didn't perform any pkg upgrade

wow I'm testing xlibre, seems to be a nice replacement for Xorg, very reactive on this old machine (core i5)

Hi all, I have an interesting phenomenon with zfs. Two servers, running smoothly for years. Both use zroot with zraid2. Last hdd change was 3 years ago. Same procedure for both servers: Shut them down, remove two hdds at the same time, put two new disks in, get the server back up, then resilver to get double redundancy back

This worked flawlessly. Yesterday, I did the same but instead I created a checkpoint first, then removed two hdds while the server was still running. Both servers detect the degraded state just fine. Then remove the checkpoint, add two fresh disks, start resilver. Zero data loss. All works fine.

But both zraids report a single data error each. Both on the <metadata>:<0x39> block.

Feels like a zfs bug to me

( I've manually inspected the 0x39 block with the zfs debug tools and it looks fine on both machines )

After running scrub, no further errors are reported. What do you think?

scrub does trigger self-repair. reading blocks with zdb does not.

You can't self-repair a non-redudancy raid.

Did you even read what I said? Two servers, two raids, same error.

Plus I think it's unlikely that the most redundantly stored block is damaged on all copies

one can never exclude possibility of bug. Proving it to be a bug needs more work than just an hunch. checksum errors are especially nasty ones in that regard.

I'm happy to provide more details if it helps

you got it on 2 systems. is it actually repeatable (with same disks? with other disks)? is it the same block or different block? if its repeatable, then you would need to start to collect pre and post write evidence (is it the same data on disk as it was before write in memory) and so on. It is a lot of digging because there can be many causes for checksum error - starting from power, cabling, cooling etc. If it is software bug, then it

should be repeatable on *different* machine.

The machines are similar configuration, both in the same datacenter, running the same PSU brand, both 128GB / 512GB ECC ram. Both AMD EPYC 7232P 8-Core Processor. Both times same metadata block that is reported damaged: 0x39

They are both in production use so I cannot do tests there. I did try the exact same thing the day before usind 2GB mdconfig'd /dev/md files and there the errors did not occur

that hints against bug.

Oh?

it does not fully exclude possibility because we do not know the exact trigger.

Using 2GB memory files with no real world zfs usage (just copy a few test files) isn't really the same as a real world scenario

The disks in the servers are of different age (3 years vs. 5/1/2 years) and different size (10TB vs 4TB)

(The reason I did the /dev/md test was to find out if the two swapped out disks could serve as an emergency backup. Turns out if you offline them, they don't, but if you hard cut remove them, they do)

So my test served an entirely different purpose, it was not meant to provoke that checksum issue. I discovered that issue later

well, sure, the IO load does contribute for sure, HBA behavior on event of disk removal and so on... all those things which add up to complicate such investigations.

Block 0x39 seems to hold the state of the zpool, active disks, etc. Why would that same block be damaged on two different systems with an otherwise fully functional (albeit non-reduntant) zraid2?

Why would adb report a fully intact block even before running scrub?

s/adb/zdb/

should check zdb code to be sure if it does verify checksum or just reads the block from disk.

zdb -c Verify the checksum of all metadata blocks while printing block statistics (see -b).

.oO oops?

Okay I ran it with -c, same output as before

Should the command abort if it encounters a checksum error?

with -c and -b?

yes

they usually report all the data there without abort

Besides, I did a full scrub since (after the initial zdb) That scrub reported zero additional errors

You want me to paste the output somewhere?

also multiple -c will switch on all checksum checks

it may help, sure

How can there be a checksum fault if scrub already reported zero errors?

well, then there should be no checksum errors obviously:)

Yes, there are none

That block should have been rewritten the very moment the two replacement disks were added

or, may it be the corruption did appear while resilvering the replacements?

Same block, one time 2 3yr old hdds, one time 2 5yr old hdds?

They had been scrubbed with 0 errors once a month before that

because disk replace surely does trigger metadata updates

I'd think so :)

How do you think the corruption happens that very moment?

I do not know, I can only guess there:)

Ok, thanks

Do you think this is worth reporting to the zfs mailing list?

definitely, maybe someone else has seen similar issue

kk, thx

it *may* be just stupid coincidence. It also may be issue about specific hardware/firmware.

like my sata disks do get checksum errors from time to time (scan: scrub repaired 44K in 0 days 10:32:26 with 0 errors on Sun Aug 9 16:32:27 2026) but then again, that MB is old, disks are old, cables are mess there and so on...

finally made the switch from debian to freebsd on my home server

woo hoo

I've learned a lot, so glad I decided to get rid of docker and podman

chatting here right now through a jail hosting the lounge irc client

jails are awesome

pertho: they really are, vnet jails especially are so powerful

I still fail to understand the point of jails. From my experice with docker/podman, containers are very inconvenient to work with, because they are to thouroughly isolated from the outer world and too ephemeral. Are jails similar to docker?

ant-x: yes and no, I understand your point of view, technically containers are not necessary if the software you run is trusted. But imo jails make experimenting with new packages really easy. If you mess something up, you can rollback and try again. If a jail fails you are certain the issue is definitely inside the jail and debugging is way easier

jails are similar to lxc, if we have to make parallels with linux

for me

ant-x: I like jails not only for security reasons but also for compartmentalization. Each of my jails is in its own zfs dataset. If I want to migrate a service between hosts (or recover from backup), it's just a `zfs send` away

(in practice I'm using bastille so it'd be `bastille send` but the principle applies generally)

and with vnet jails they are not so isolated from the outer world. vnet jails appear like a first class host to the rest of the network

on my VPS I use non-vnet jails to get a facsimile of a LAN, where my jails can communicate freely with one another but they are behind a pf NAT and therefore isolated from the internet unless I explicitly forward a port

it's also not difficult to break the isolation when desired. for instance I have a temp file hosting service in its own jail separate from the http server jail, but I want them to share a file system so that files uploaded to the hosting service can be served statically by the http server. for that I just made a separate zfs dataset and mounted it on both jails via nullfs

(and on the http server side I can mount that dataset as read only so it can't interfere with the hosting service even by that route)

Thanks for the explanaiont, I understand it in a general way, but not in the specifics, which is natural as I don't use jails, zfs, or pf.

you are missing out on a lot of the benefits of freebsd by neglecting those

Agreed.

those three things are the reason I don't even consider other OSes for application hosting

if openbsd had jails and zfs I'd probably be using that instead

Containers are often mounted read only and only a data partition gets mounted rw, allowing for atomic upgrades/downgrades and reducing attack surface

And clear separation between application and data

afaict freebsd supports pandoc these days

Jails can also have their own secure levels, independent of the host system.

Mitigates the impact of a jail getting rooted.

jails can also let you run disparate versions of the userland when needed

for instance if you need to run some outdated software on a legacy version of freebsd but don't want to give it a dedicated host

so long as you account for the other security implications of doing that, running it in a jail with an older userland just works

Real Hackers™ just abuse libmap.conf

Zerock: That doesn't always work, mind you. I had jails running Java things break when I upgraded the host a few years back.

hmm

Sounds like a java problem. Write once, debug everywhere.

boru: Yeah, but it was Java inside of a jail..

I'm just poking fun. It's late in the day.

That said, I've got one jail that's ancient and can't update for various reasons that keeps on chugging. Just not running Java.

No worries. :)

I appreciate the sentiment.

Zerock: i started using zfs only recently and i agree with everything you're saying, especially pf, it's amazing

it's wonderful

hi. does anyone using Haiku and it is possible to instll in byhive, please?

can someone link me a guide or help me setup VAAPI for transcoding on a jellyfin instance inside a jail (bastille)?

i can't seem to find anything online and it's getting really confusing

i've only successfully done it on a jellyfin lxc on proxmox :/

i assume you already tried setting up the devfs ruleset to pass through?

Maybe I'm oldskool, but I'm not sure "the juice is worth the squeeze" when it comes to putting everything in a jail.

honestly, in this case i'd probably put it in a bhyve linux vm

vs a jail

That's probably more work.

yea, right igpu passthrough...bah

alem, this for a jellyfin server or client?

I found: daemonless.io/images/jellyfin

if transcode is needed, I would think the server

its available in ports, if wanting to try to run outside of a jail

yeah I just made a bhyve VM for jellyfin and did pci passthru to give it the gpu for transcoding

i guess i didn't realize the oci/podman stuff had come so far on FreeBSD

shame it still requires root, but still

What exactly requires root?

CrtxReavr: server, i got some help from claude to setup devfs as it all seemed like dark magic to me and got it working. I might just destroy the jail and run it on the base system for simplicity tho

i'm assisting a friend setting up 15.1 on hetzner cloud, amd64 (qemu-kvm), ipv6 only. they provide FreeBSD-15.1-RELEASE-amd64-bootonly.iso which you can boot from, and control tty1 through a web UI (where the only available key combo is ctrl-alt-del). they require you to manually configure a default route via fe80::1 ( docs.hetzner.com/cloud/servers/primary-ips/primary-ip-configuration ). unfortunately, while accepting the input, not showing a

warning, the installer just returns to the network configuration when you configure it.

is there another way to set this up?

alt+F2, alt+F3 to get to a root console?

I think the hetzner cloud has a webui keyboard that allows you to use the alt+Fx combinations?

no webui keyboard for the cloud, just for dedicated servers, i think

Sounds like a deeply flawed cloud service.

amzetta.com/wp-content/uploads/2024/09/hetznerconsole.png is all you get

(copy+paste works, to a degree)

yes, this is pretty bad, but i guess that's why they're cheap.

FWIW, I can't ping or connect to ssh on your 2a01:4ff:f0:40bb::2 IP.

that's not mine, i just shared a screenshot io found on the web

"I", no "io"

"I", not "io"

sorry

ahh

apparently i could ask them to provide disc1.iso so i could install offline, then boot and login and edit the config

do i want disc1 or dvd1 for this?

disc1 is prolly fine.

thanks

dvd1 would have a bunch of packages & src available.

All our of date.

s/our/out

i see

alem: devfs shouldn't be dark maguc as long as you know what device files you need in your /dev within the jail

pepperidge farm remembers

karolyi: well i didnt know which device files to share with the jail and couldn't find any info about it online (or really didnt know what to search for lol). Surprisingly Claude helped me, it usually fails miserably