00:00:01 <mquin> mewt: apparently there was a release yesterday, 2.0.13, and This change from a month ago looks suspicious https://github.com/anope/anope/commit/66f37139cba97f2bb2a490376ffc33f153900b6c
00:00:03 <VimDiesel> Title: regchannels: remove dependency on no-delete-null-pointer-checks · anope/anope@66f3713 · GitHub
00:01:05 <mewt> ooh
00:01:06 <RhodiumToad> yeah, that looks like it's addressing exactly this issue
00:01:19 <mewt> yeah, I should have thought to look at the repo... sorry
00:01:42 <mewt> let's see what 14.0-RELEASE has got
00:01:46 <RhodiumToad> the port doesn't seem to have a maintainer though
00:02:26 <RhodiumToad> prior maintainer dropped it a few weeks ago.
00:02:46 <mewt> interesting...
00:02:52 <mewt> well, i have built it for my own use before
00:03:08 <RhodiumToad> so the thing to do would be to submit a patch to update the port to 2.0.13
00:03:16 <mewt> gotcha
00:03:40 <RhodiumToad> you could also take the maintainership if you're up for that
00:04:29 <RhodiumToad> have you done any building from ports?
00:04:40 <mewt> long ago but not at all recently
00:05:08 <mewt> i am happy to try and get up to speed later though
00:05:25 <RhodiumToad> there's almost never any point in checking the pkg repos for other versions, btw. all repos are built from the same two versions of the ports tree (main and the current quarterly branch)
00:06:09 <RhodiumToad> so if the ports tree has 2.0.12, then all "latest" repos will build that version
00:06:21 <mewt> got it
00:07:28 <mewt> i'll be back in a bit and see if i can at least get a patch to bump to the new version after confirming this will solve the problem
00:07:45 <RhodiumToad> the patches for anope don't look too bad, so it's likely that updating would just be a matter of changing the version, running make makesum, and then verifying the patches apply properly
00:07:57 <RhodiumToad> then build and run and see if it works :-)
00:27:15 <tyler82>  Finally. i could fix it. Now i am able to boot into my system again. thanks guys!RhodiumToad mason meena u are legend!! :)
02:01:38 <spork_css> @otis @rtprio - thanks for the oracle suggestion, just reading up on all the caveats and such
02:07:29 <spork_css> also, this looks like a great reference: https://klarasystems.com/articles/deploying-freebsd-on-oracle-cloud/
02:07:31 <VimDiesel> Title: Deploying FreeBSD on Oracle Cloud | Klara Inc
03:15:32 <mason> tyler82: Glad you got it.
04:37:55 <CCFL_Man> i had a kernel page fault this week which rebooted the system? possible memory going bad?
04:38:20 <CCFL_Man> i keep having them quite frequently
04:41:25 <mason> CCFL_Man: Might be good reason to spend a few hours running memtest.
04:47:03 <CCFL_Man> that's a seperate boot? i'm on a headless system
04:47:20 <CCFL_Man> or can it be run in single user mode
04:47:46 <mason> That's generally separate boot media as it tests without anything much loaded .
04:48:04 <mason> https://www.memtest86.com/
04:48:05 <VimDiesel> Title: MemTest86 - Official Site of the x86 and ARM Memory Testing Tool
04:56:38 <CCFL_Man> thanks! i'll have to find a monitor then
04:56:55 <CCFL_Man> but should be a good diagnostic
04:57:45 <CCFL_Man> i have the console redirected to serial on this system
06:30:26 <RhodiumToad> while sometimes it is the hardware, it's usually a mistake to assume it's the hardware first
06:30:52 <RhodiumToad> make sure you get the crash dumps, and look at them to see if they are in any respect similar
06:36:27 <nerozero> just experienced "wow", if type "vi" while in less, the current EDITOR will be run against the file...
06:51:40 <wikan> key bind meta2-1;5D /window left
06:51:50 <wikan> sorry :D
06:52:28 <wikan> it is good it wasn't a password lol
08:34:08 <meena> spork_css: I'm pretty, and sure, somebody has already worked on getting FreeBSD images into Oracle cloud, so it shouldn't be that much written these days
10:21:30 <nerozero> i have an issue with vm-bhyve port ( or maybe bhyve itself ) while rebooting guest machine the guest machine shutdowns but sometimes doesn't start again
10:22:45 <nerozero> my guess the vm is still in lock state while vm-bhyve tries to start it back, and it fails
10:23:01 <nerozero> manual start afterwards works normally
10:23:32 <nerozero> the rebook if guest storage is located on ssd seems to be mostly normal
10:24:00 <nerozero> does anyone experience same things ?
11:19:25 <kenrap> Man, I feel like an idiot. That appjail software is too difficult for me to figure out. There was steep learning curve for me and I still couldn't get Brave to connect to the internet. Sigh...
13:20:42 <Oleg> I started scrubbing a zpool, then I paused it, exported the zpool, and rebooted. After that, I imported the zpool, typed zpool scrub <zpool> and the scrubbing started from the very beginning, not from the paused point. Why?
13:25:13 <laidback_01> presumably the information about scrubbing the pool isn't written to the drives, only kept in working memory.  A rebot wipes working memory.
13:25:47 <Oleg> laidback_01: what? why is it not mentioned in the manual for zfs?
13:27:24 <laidback_01> As to why was it designed that way... it's only a drive scrub.  I'm guessing by the way.  not a developer for zfs.  a drive scrub is not a critical drive function like a write.  there's no journal of it kept since all it's doing is reading...  well, I guess it's fixing it where there's crc errors, but I'll have to read the manpage for more information.
13:28:20 <Oleg> but before I tried to resume the scrubbing, I typed "zpool status -v" <zpool>, and the information that the scrubbing had been paused was displayed
13:29:23 <laidback_01> I don't really know.  Maybe it saw a set of defined circumstances that made it easier to just start from the beginning than resume at the previous point
16:04:52 <rtprio> Oleg: when you exported it closed all the files and probably cleared the scrub process
16:05:49 <rtprio> nerozero: i have that bhyve problem too; is the host that doesn't reboot, is it set to autostart?
16:08:07 <rtprio> spork_css: that's the reference i used
16:09:27 <rtprio> oh wait; i just used dd and reboot; where is that
16:10:42 <rtprio> https://akr.am/blog/posts/installing-freebsd-on-oracle-cloud
16:10:44 <VimDiesel> Title: Installing FreeBSD on Oracle Cloud | seize the dev
16:20:56 <markmcb> how smooth are big version updates, e.g., 13->14? like do you update on day 1? looking at the schedule it seems there's a reasonble amount of pre-release testing. just curious what's the norm.
16:32:58 <yo9fah> Hi all
17:17:34 <debdrup> markmcb: I don't know about percentages, but there are enough people that upgrade to a .0 as soon as they can, and also enough people that wait for .1, that I'd say either is a perfectly acceptable approach.
17:17:43 <debdrup> There are different reasons for doing either, and both make sense.
17:21:18 <markmcb> makes sense. my whole life i always tell myself i'll wait, and then apply upgrades as soon as they're available :)
17:23:12 <Schamschula> If you don't have a test server, you tend to be a bit more cautious upgrading your production server.
17:24:17 <markmcb> totally. it's just my homelab at risk, so not a huge deal if something doesn't go quite right.
17:25:00 <markmcb> does the bectl feature work with major upgrades too? i assume so. i feel like that takes the edge off a bit as well
17:25:08 <rwp> markmcb, For my purposes if it is a production machine for other people then I wait for the .1 release before upgrading to it.  Especially if it has a large storage array because I don't want to break large storage arrays.
17:25:15 <rwp> But my own desktop I upgrade to the .0 as it comes out because I have 1) a good backup 2) Boot Environments and so the risk is minimal.
17:26:16 <markmcb> +1 for backups. everything in triplicate for me.
17:26:37 <rwp> Noting that zfs zpool also has an upgrade cycle.  I usually hold off upgrading the zpool until I am sure I won't be downgrading the system ever.
17:26:51 <natewrench> how many backups do you have
17:26:53 <natewrench> at one point
17:28:23 <markmcb> rwp, so you have to manually upgrade ZFS? it's not done with OS upgrades?
17:29:00 <markmcb> natewrench: i have 3 copies. live data. local backup. and a remote backup.
17:29:46 <rwp> markmcb, ZFS has it's own upgrade cycle as features are added to the pool.  See "zpool upgrade".  The "zpool status" will show if the OS supports features that the pool does not yet and if a zpool upgrade is available.
17:32:17 <markmcb> rwp, thanks for the tip. i'll keep my eye on that.
17:35:10 <rwp> Between 12 and 13 there were new zpool features added for example.  Installing on 12 and then upgrading to 13 made a zpool upgrade available.  It's a one-way trip for zpool upgrades.  So I held off until I was sure I was never returning to 12 again.  All of which worked without any problems btw.
17:35:53 <rwp> I don't know if there are new zpool features added between 13 and 14 yet.  I have not looked.  But again "zpool status" will show this if there are.
17:36:53 <rwp> natewrench, The "backup rule of 321" applies.  At least three copies, on at least two different types of storage, at least one copy off-site.
17:43:18 <natewrench> I use Linux Mint which I set up duplicati then it goes to cloud storage. I think i have the 321 rule down, though cloud storage or off site copies makes me worried
17:45:08 <natewrench> off site is just someone elses machine
17:52:41 <parv> natewrench, Set up at friend|family's house?
17:58:41 <natewrench> ya
18:13:34 <grahamperrin> markmcb: if you use freebsd-update(8) for your major upgrade, then yes. There's automated creation of a boot environment, or two.
18:14:52 <grahamperrin> freebsd-update.conf(5) <https://man.freebsd.org/cgi/man.cgi?query=freebsd-update.conf&sektion=5&manpath=freebsd-release>
18:14:53 <VimDiesel> Title: freebsd-update.conf(5)
18:20:27 <grahamperrin>  > … I don't know if there are new zpool features added between 13 and 14 yet. …
18:20:28 <grahamperrin> rwp: maybe most notable with the superior version of OpenZFS, this property:
18:20:28 <grahamperrin> feature@block_cloning
18:21:19 <grahamperrin> Refrain from enabling the feature.
18:26:30 <grahamperrin> In addition, a systctl that is zero by default:
18:26:47 <grahamperrin> % sysctl -dt vfs.zfs.bclone_enabled... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/7ba01e2b170f8b6124852c00623e21373515cac4>)
18:27:47 <grahamperrin> Contexts include <https://reviews.freebsd.org/D39613> and <https://github.com/openzfs/zfs/pull/14935>.
18:27:49 <VimDiesel> Title: ⚙ D39613 zfs: Add vfs.zfs.bclone_enabled sysctl.
18:28:34 <grahamperrin> From the latter:
18:28:34 <grahamperrin>  > …  I want to keep block cloning disabled by default at least for 14.0 time frame.
18:42:57 <CCFL_Man> (da0:umass-sim0:0:0:0): WRITE(16). CDB: 8a 00 00 00 00 01 00 00 24 80 00 00 00 08 00 00
18:43:00 <CCFL_Man> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
18:43:15 <CCFL_Man> what does that mean for my drive? possibly failing?
18:43:45 <CCFL_Man> it's part of a one device zfs pool on a usb to sata adapter
18:50:19 <grahamperrin> Maybe a failing drive, maybe a transient issue not involving the HDD (assuming it's not solid state).
18:50:57 <rtprio> markmcb: i've upgraded from 4 to 14 (not one system) but never had a system unrecoverable between major versoins
18:51:37 <grahamperrin> CCFL_Man: what do you mean by "part of" a one-device pool? (I visualise a single device with no additional part.)
18:52:35 <CCFL_Man> grahamperrin: it just started happening. i wonder if it's a transient issue. i guess those could happen. it's a pool i created with one device on a usb adapter, it's a WD red hard drive
18:53:07 <rtprio> CCFL_Man: i see similar with my usb pool. scrub showed some errors. the drive could be on its way out
18:54:24 <CCFL_Man> the hope is to copy data from a failing hard drive to the pool containing this one, then move the drive to the sata controller and still maintain the pool
18:54:53 <CCFL_Man> rtprio: ok, i figured. i got it this past november. maybe i can do a warranty claim with WD
18:55:18 <rtprio> i'd make a backup, either rsync or zfs send, and then scrub it
18:55:57 <CCFL_Man> scrub? you mean zero it?
18:58:58 <rtprio> scrub is checking it for errors
18:59:05 <rtprio> man zpool-scrub
18:59:41 <rtprio> but it's a lot of io and if the drive is... having problems it could potentially push it over the edge
19:01:08 <CCFL_Man> ahh, ok
19:02:32 <CCFL_Man> i just got it, so the data is ok.
19:02:43 <CCFL_Man> i will try that
19:02:52 <rtprio> probably. zpool scrub will tell you what file are corrupted, if there are corrupted files
19:03:01 <CCFL_Man> because i may be able to get one from a warranty replacement
19:03:50 <CCFL_Man> i just made a directory on the pool and afterwards i got another write error that was correctable
19:04:25 <CCFL_Man> so i think you are right
19:06:25 <CCFL_Man> the scrub did not return any output to the terminal
19:07:11 <grahamperrin> For those of us who don't know Red: <https://www.westerndigital.com/en-gb/products/internal-drives/wd-red-sata-hdd>
19:07:46 <grahamperrin> CCFL_Man: no output is normal. Run:
19:07:50 <grahamperrin> zpool status -v
19:08:55 <grahamperrin> How old is the drive?
19:10:48 <CCFL_Man> i got it new this past november and just put it into service
19:15:56 <markmcb> rtprio: that's reassuring. thanks :)
21:16:43 <CCFL_Man> grahamperrin: scan: scrub repaired 0 in 0 days 00:35:51 with 0 errors on Sun Jul  2 15:46:58 2023
21:17:00 <CCFL_Man> looks good, so possibly initial failing
21:34:12 <parv> CCFL_Man, Could have been a loose cable conneciton
22:18:06 <meena> markmcb: my suggestion to people wanting to upgrade to a .0: test the betas, or at least the RCs
22:32:58 <meena> rtprio: instead of dual-dhclient-daemon you could warp into the future and install dhcpcd
22:47:22 <rwp> CCFL_Man, Look in /var/log/messages around that time to see what other messages are appearing. Look for "detached" and "starting remove_device" types of messages.  If things are bad then the kernel will detach the device and remove the associated /dev/* entries.
22:47:28 <rwp> But then if it is transient the kernel will see the drive is there and then add those back in and attach the device again.  Possibly repeating.
22:48:03 <rwp> I agree with parv that a transient glitch like that might be a cable problem with either the SATA cable or the power cable.  (I just found a power cable problem causing me similar type problems on my system.)
22:49:50 <rwp> CCFL_Man, Then look at the SMART data for the drive.  If it is say ada2 then "smartctl -l error /dev/da2" and "smartctl -l selftest /dev/da2".  No selftests listed?  Then run a short selftest "smartctl -t /dev/da2" wait the appropriate time indicated and then look at the selftest log again. And then configure smartmontools to run SMART tests periodically.
22:50:14 <rwp> Oh, I said assuming ada2 then wrote da2 in the examples.  But you know what I meant to say there! :-)
22:56:31 <rwp> Oh and the smartctl -t takes an option and should have been "smartctl -t short /dev/ada2" too.