mystic: netgraph in itself is to do with networking, not security

mystic: it's a way to connect up different networking concepts in a modular fashion

RhodiumToad: :-) thanks so much. Now I understand.

why pkg autoremove -n shows all my kde5 and xorg to remove?? i am using those...🤨🙄

it wants to remove 3GB. but i dont want those remove

RhodiumToad: I meant specifically the order of loading modules within loader.conf and rc.conf:kld_list.

Wasn't sure if that was deterministic or not.

Was asking because when I moved a couple of kernel modules from loader.conf to rc.conf, it worked fine. When I had them in loader.conf, I had to unload and reload a specific module (nvidia-drm.ko) to be able to boot wayland. Made me wonder if there was some dependency it needed to come after, and thus what the order was.

is this a 3rd party nvidia driver?

Not sure what that means, but it's the dev version of x11/nvidia-driver.

535.54.03 with drm.

ah ok

drm part does not come from nvidia though?

is why i asked

badland.io/announcing_nvidia_drm.md is what i aslo referring to

Title: Announcing nvidia-drm port and Call for Testing

i'm so pleased with my new freebsd server =]

Demosthenex: congrats

mason, Waaay back around June 24th we were talking about my disk array problem? Life here outside the keyboard has kept me busy and continues to do so.

mason, I wanted to let you know that I figured out the root cause of the problem. And that I completely rescued 100% of my array. No errors. ZFS is good!

The root cause of the problem was a bad 4-pin Molex power connector being used to power several of the disk drives.

My systems sometimes get reused and reconfigured and so that power supply had been used and re-used with many insertions into the connector. The PSU end was well used and did not grip the pins of the drive side cable very well.

Vibrations from the fans, and from the disk drive heads seeking, would cause the connector to drop power when things were "thumping". That was the root cause of the problem.

As I said at the time I was making a complete copy of the 6 drives and then working with the copies. During that time this problem *killed* one of the replacement drives! Lost power during a drive write I imagine. It will no longer survive a read of the entire disk. Glad it was on a copy!

After I figured the problem out and corrected things ensuring that the power connectors were good I was able to import the array, resilver, and scrub (took a few iterations) and was able to 100% recover the array. And it has been solid since. Whew!

ooh, nasty

The bad power connector once found totally explained the strange behavior and why "perfectly good" drives were resetting at what seemed like random times.

rwp: Oh, I'm really glad you figured that out. It sounded astoundingly frustrating.,

And that it wasn't one particular drive but this drive this time and that drive the next time and so forth.

It drove me bonkers! And those connectors are usually very reliable. But then once I suspected it I was able to jiggle things and cause it on demand. And then could fix it. I removed pins and "adjusted" them to be very tight and that solved the problem.

I've never thought of those connectors as being problematic.

And then subsequently I bought a Supermicro rack case bare but it has 8 bays on a backplane and of course that is the perfect answer for a NAS drive array. This is in my house though so had to replace all of the fans with something a little less noisy.

But clearly they can be.

Once I was able to jiggle the power cables and cause the problem (logged to the console I could watch) then I could zero in on the problem. And it was the PSU 4-pin Molex that was the problematic one.

Those 4 pin connectors were never great, they were ditched with good reason for SATA. If they weren't giving poor connections they were getting jammed in place

Rather interesting but during the scrub where zpool status reports resilvering there are 6 drives and 4 of them were being reported as resilvering. Which is quite unusual! Since raidz2 has only two disks of redundancy. Fortunately it seemed that the blocks with checksum failures were scattered and across the entire collection the redundancy block by block was sufficient!

In the end ZFS pulled me through though and it was 100% recovered with no errors. Whew! And Yay!

\o/

O_O

Anyway... Since my problem was rather unusual with the random drive resets I wanted to pass along what was causing those random drive resets that did not make sense at the time.

Thank you.

And here is that _unusual_ zpool status report from it with 4 disks resilvering: bsd.to/j9gm/raw

Title: j9gm

The other unusual thing about the entire event is that I *killed* one of my replacement drives. It was resilvering and then failed out.

I imagine power loss during a track write scrambled the middle part of the disk. I can read and write both ends but a read pass through the entire disk now causes it to I/O and the drive becomes unresponsive for long enough that there are kernel errors thinking it was detached.

"It's dead Jim."

Fortunately it was a replacement drive and I still had the original data available. I cloned that disk of data again onto a different replacement drive. That really made me feel good about working with copies and not the original data.

For replacement drives I bought used SAS drives pulled out of datacenters from random different vendors. Out of 8 drives I won the lottery in that 2 were brand new! And the others scattered in age as expected. And all bought for appropriate costs for used datacenter pulled drives.