JorgeB

No, but if there are sparse files on source you need to use the --sparse flag or it will take much more space.

Take a look at the SEL in the BIOS, this is how it appears for one of my SM boards:

Not that one, it's a Marvell, search for ASM1164 or JMB585

Looks at the system event log in the BIOS, or IPMI event viewer, there should be more info there.

If it's not RAM the next suspects are a controller or a disk, since you're using controller with SATA port multipliers and those are not recommended anyway I would start by replacing that.

Correct.

Dec 11 09:47:54 Tower kernel: macvlan_broadcast+0x10e/0x13c [macvlan] Dec 11 09:47:54 Tower kernel: macvlan_process_broadcast+0xf8/0x143 [macvlan] Macvlan call traces are usually the result of having dockers with a custom IP address, upgrading to v6.10 and switching to ipvlan might fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enable, top right)), or see below for more info. https://forums.unraid.net/topic/70529-650-call-traces-when-assigning-ip-address-to-docker-containers/ See also here: https://forums.unraid.net/bug-reports/stable-releases/690691-kernel-panic-due-to-netfilter-nf_nat_setup_info-docker-static-ip-macvlan-r1356/

I have one of those expanders also with an LSI HBA and never had any issues, but there could be with some specific models, also could be firmware related, but IIRC to update it requires a supported HP controller.

It appears after you click on the #1 device of any pool, so yes, pool needs to exist already.

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=480421

Enable the syslog server and post that after a crash, hopefully it catches something.

Cool, would it be possible to also fix this long standing bug? https://forums.unraid.net/bug-reports/stable-releases/clearrebuild-operations-are-reported-as-the-last-parity-check-and-with-the-wrong-avg-speed-if-drive-is-smaller-than-parity-r3/?do=getNewComment&d=2&id=3 First bug report created on this subforum

Check filesystem.

That suggests a hardware issue, start by running memtest.

Log starts over after every reboot, so no way of knowing now if the previous check was correcting or not.

Log only shows one check, maybe the other one was non correcting, run another non correcting check and post new diags if it still finds sync errors.

Yes, this is normal with any disk.

You just need to assign them and start the array to begin the parity sync.

It does, not sure why they don't for me, but can't be the only one.

Intel SAS2 based expanders should work fine, like the RES2SV240, chip is LSI, so less likely to run into compatibility issues.

Forget that, it's the onboard NIC, it uses the same driver.

Yes, strange, according to the syslog link is up: Dec 15 10:38:08 Bifrost kernel: e1000e 0000:00:1f.6 eth0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None And there's nothing else related to eth0 after that.

Yes, drives added later will need to be cleared, but they will be empty so not a problem.

Yes, if you don't change to ipvlan.

No, but there could be issues with the shucked drive, if the size is not the same as it was and/or it's hardware encrypted by the enclosure, some WD USB drives are.