04:03:55 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. 04:15:44 https://paste.debian.net/hidden/cdf846ca 07:38:22 * mewt np: /31 07:38:26 sorry 07:38:35 bad collision of text in the buffer there 10:36:54 <_Posterdati_> hi 10:36:58 <_Posterdati_> please help 10:37:50 <_Posterdati_> 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? 10:37:55 <_Posterdati_> thanks 10:39:15 <_Posterdati_> how can I check if userland programs were upgraded too? 10:53:02 `freebsd-version -kru` 10:53:18 kru, kernel runtime userland 10:56:16 <_Posterdati_> thanks 10:56:31 <_Posterdati_> I followed https://www.freebsd.org/releases/15.1R/upgrading/#upgrade-fu 11:06:54 <_Posterdati_> seems to be kru=15.1-RELEASE-p2 11:07:05 <_Posterdati_> ibs: seems ok then 11:07:20 <_Posterdati_> ibs: but I didn't perform any pkg upgrade 11:39:18 <_Posterdati_> wow I'm testing xlibre, seems to be a nice replacement for Xorg, very reactive on this old machine (core i5) 11:48:08 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 11:48:51 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. 11:49:10 But both zraids report a single data error each. Both on the :<0x39> block. 11:49:16 Feels like a zfs bug to me 11:49:57 ( I've manually inspected the 0x39 block with the zfs debug tools and it looks fine on both machines ) 11:50:05 After running scrub, no further errors are reported. What do you think? 11:51:01 scrub does trigger self-repair. reading blocks with zdb does not. 11:51:21 You can't self-repair a non-redudancy raid. 11:53:46 Did you even read what I said? Two servers, two raids, same error. 11:54:01 Plus I think it's unlikely that the most redundantly stored block is damaged on all copies 11:58:08 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. 11:58:25 I'm happy to provide more details if it helps 12:04:27 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 12:04:27 should be repeatable on *different* machine. 12:07:40 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 12:08:19 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 12:08:45 that hints against bug. 12:08:52 Oh? 12:09:17 it does not fully exclude possibility because we do not know the exact trigger. 12:09:20 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 12:09:43 The disks in the servers are of different age (3 years vs. 5/1/2 years) and different size (10TB vs 4TB) 12:10:37 (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) 12:11:12 So my test served an entirely different purpose, it was not meant to provoke that checksum issue. I discovered that issue later 12:14:51 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. 12:15:43 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? 12:16:05 Why would adb report a fully intact block even before running scrub? 12:16:09 s/adb/zdb/ 12:18:17 should check zdb code to be sure if it does verify checksum or just reads the block from disk. 12:20:41 zdb -c Verify the checksum of all metadata blocks while printing block statistics (see -b). 12:20:55 .oO oops? 12:22:33 Okay I ran it with -c, same output as before 12:22:54 Should the command abort if it encounters a checksum error? 12:22:56 with -c and -b? 12:23:17 yes 12:23:40 they usually report all the data there without abort 12:23:47 Besides, I did a full scrub since (after the initial zdb) That scrub reported zero additional errors 12:23:58 You want me to paste the output somewhere? 12:24:08 also multiple -c will switch on all checksum checks 12:24:31 it may help, sure 12:25:57 How can there be a checksum fault if scrub already reported zero errors? 12:26:33 well, then there should be no checksum errors obviously:) 12:26:39 Yes, there are none 12:26:57 That block should have been rewritten the very moment the two replacement disks were added 12:27:39 or, may it be the corruption did appear while resilvering the replacements? 12:28:07 Same block, one time 2 3yr old hdds, one time 2 5yr old hdds? 12:28:25 They had been scrubbed with 0 errors once a month before that 12:28:27 because disk replace surely does trigger metadata updates 12:28:46 I'd think so :) 12:28:57 How do you think the corruption happens that very moment? 12:29:17 I do not know, I can only guess there:) 12:29:32 Ok, thanks 12:29:39 Do you think this is worth reporting to the zfs mailing list? 12:30:08 definitely, maybe someone else has seen similar issue 12:30:18 kk, thx 12:32:14 it *may* be just stupid coincidence. It also may be issue about specific hardware/firmware. 12:34:07 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... 13:01:33 finally made the switch from debian to freebsd on my home server 13:02:14 woo hoo 13:05:14 I've learned a lot, so glad I decided to get rid of docker and podman 13:05:52 chatting here right now through a jail hosting the lounge irc client 13:30:48 jails are awesome 13:37:53 pertho: they really are, vnet jails especially are so powerful 14:13:31 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? 14:17:10 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 14:17:11 jails are similar to lxc, if we have to make parallels with linux 14:17:11 for me 14:30:18 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 14:30:33 (in practice I'm using bastille so it'd be `bastille send` but the principle applies generally) 14:31:54 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 14:33:02 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 14:34:19 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 14:35:44 (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) 14:36:13 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. 14:36:31 you are missing out on a lot of the benefits of freebsd by neglecting those 14:36:56 Agreed. 14:37:12 those three things are the reason I don't even consider other OSes for application hosting 14:39:41 if openbsd had jails and zfs I'd probably be using that instead 14:40:11 Containers are often mounted read only and only a data partition gets mounted rw, allowing for atomic upgrades/downgrades and reducing attack surface 14:40:32 And clear separation between application and data 14:40:49 afaict freebsd supports pandoc these days 14:41:13 Jails can also have their own secure levels, independent of the host system. 14:41:44 Mitigates the impact of a jail getting rooted. 14:41:45 jails can also let you run disparate versions of the userland when needed 14:42:06 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 14:42:28 so long as you account for the other security implications of doing that, running it in a jail with an older userland just works 14:43:02 Real Hackers™ just abuse libmap.conf 14:44:28 Zerock: That doesn't always work, mind you. I had jails running Java things break when I upgraded the host a few years back. 14:44:41 hmm 14:45:02 Sounds like a java problem. Write once, debug everywhere. 14:45:14 boru: Yeah, but it was Java inside of a jail.. 14:45:48 I'm just poking fun. It's late in the day. 14:45:58 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. 14:46:04 No worries. :) 14:46:10 I appreciate the sentiment. 15:38:43 Zerock: i started using zfs only recently and i agree with everything you're saying, especially pf, it's amazing 15:39:08 it's wonderful 15:43:43 hi. does anyone using Haiku and it is possible to instll in byhive, please? 18:54:14 can someone link me a guide or help me setup VAAPI for transcoding on a jellyfin instance inside a jail (bastille)? 18:55:48 i can't seem to find anything online and it's getting really confusing 19:52:00 i've only successfully done it on a jellyfin lxc on proxmox :/ 20:01:56 i assume you already tried setting up the devfs ruleset to pass through? 20:02:54 Maybe I'm oldskool, but I'm not sure "the juice is worth the squeeze" when it comes to putting everything in a jail. 20:03:24 honestly, in this case i'd probably put it in a bhyve linux vm 20:03:35 vs a jail 20:04:06 That's probably more work. 20:04:22 yea, right igpu passthrough...bah 20:07:01 alem, this for a jellyfin server or client? 20:07:55 I found: https://daemonless.io/images/jellyfin/ 20:07:56 if transcode is needed, I would think the server 20:08:19 its available in ports, if wanting to try to run outside of a jail 20:09:12 yeah I just made a bhyve VM for jellyfin and did pci passthru to give it the gpu for transcoding 20:25:38 i guess i didn't realize the oci/podman stuff had come so far on FreeBSD 20:25:44 shame it still requires root, but still 20:41:57 What exactly requires root? 20:43:13 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 21:20:44 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 ( https://docs.hetzner.com/cloud/servers/primary-ips/primary-ip-configuration ). unfortunately, while accepting the input, not showing a 21:20:44 warning, the installer just returns to the network configuration when you configure it. 21:20:56 is there another way to set this up? 21:29:35 alt+F2, alt+F3 to get to a root console? 21:30:11 I think the hetzner cloud has a webui keyboard that allows you to use the alt+Fx combinations? 21:32:45 no webui keyboard for the cloud, just for dedicated servers, i think 21:37:07 Sounds like a deeply flawed cloud service. 21:37:42 https://amzetta.com/wp-content/uploads/2024/09/hetznerconsole.png is all you get 21:38:20 (copy+paste works, to a degree) 21:38:49 yes, this is pretty bad, but i guess that's why they're cheap. 21:41:20 FWIW, I can't ping or connect to ssh on your 2a01:4ff:f0:40bb::2 IP. 21:41:53 that's not mine, i just shared a screenshot io found on the web 21:42:19 "I", no "io" 21:42:26 "I", not "io" 21:42:27 sorry 21:42:47 ahh 21:44:00 apparently i could ask them to provide disc1.iso so i could install offline, then boot and login and edit the config 21:44:33 do i want disc1 or dvd1 for this? 21:46:45 disc1 is prolly fine. 21:46:54 thanks 21:47:06 dvd1 would have a bunch of packages & src available. 21:47:15 All our of date. 21:47:26 s/our/out 21:51:35 i see 21:55:19 alem: devfs shouldn't be dark maguc as long as you know what device files you need in your /dev within the jail 22:09:08 * CrtxReavr remembers installing FreeBSD via a single floppy disk, using PPP dial-up. 22:12:28 pepperidge farm remembers 23:57:36 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