JorgeB

Most likely will comeback.

I saw this in the log: May 26 19:53:45 Tower kernel: device_list[7046]: segfault at 9267a2 ip 000000000087f7ad sp 00007ffde9c6d860 error 7 in php[600000+338000] May 26 19:53:45 Tower kernel: Code: 48 29 e8 4c 63 e8 89 43 10 48 c7 c0 60 ea 61 01 49 8d 7d 20 48 83 e7 f8 80 b8 8c 00 00 00 00 0f 85 3b 15 00 00 e8 93 75 00 00 <c7> 00 01 00 00 00 49 89 c6 b8 06 00 00 00 4d 89 6e 10 49 8d 4e 18 That's I expected a reboot would fix the device issue, but can't tell you what caused the error in the first place.

Try moving the HBA to another PCIe slot if available, ideally you'd get rid of the error, if it's not possible this should suppress it.

Not sure but it only happens with Dell servers, so likely some BIOS/driver issue.

No, for many years disks with same advertised capacity have the same exact number of available sectors.

Yes. Yes, they are not recommended but for testing it's fine.

Try rebooting.

You don't need a Gigabyte board, those boards had an issue that sometimes created a HPA without you wanting.

No. Though I don't recommended because it doesn't work with all controllers setting a HPA would work for what you want:

Delete the cracked btrfs.key, reboot to clear the log and please post the complete diagnostics when the dockers stop working.

That's good news, but on the other hand might make it more difficult to find what the problem was before, if you can't reproduce it. It's always a good option to have checksums of you files, plugin is a good option, you can also use for example corz to create them over the shares with Windows. I recommend ECC for anyone who cares about data integrity, IMHO RAM issues are definitely the number one reason for data corruption.

Please use the existing plugin support thread:

See here:

Please use the existing plugin support thread:

Try this: Edit config/ident.cfg on the flash drive and change USE_SSL from "yes" to "no", then reboot and access the server by IP.

It does look like the typical Ryzen SATA controller problem, new BIOS or updating to v6.10 might help, if it doesn't best bet is to use an add-on controller.

See here: https://wiki.unraid.net/Manual/Changing_The_Flash_Device#What_to_do_if_you_have_no_backup_and_do_not_know_your_disk_assignments

Changed Status to Closed Changed Priority to Other

This is one of the known controllers that this can happen to, but only because it's using a very old firmware: May 26 09:42:16 ES-unRaid kernel: mpt3sas_cm0: LSISAS3008: FWVersion(05.00.00.00), ChipRevision(0x02), BiosVersion(08.11.00.00) If you updated the firmware while on an older Unraid release you'd see the same thing, and note that you should still update the firmware now, since many issues have been fixed since that one, IIRC current release is 16.00.12.00

This is only for servers using a NIC that uses the tg3 driver, this assuming I'm right and the NIC, or more likely the NIC driver, is the problem when VT-d is enabled, if that's the case there's not much LT can do, they can't fix the driver, what they can do for now is to block loading the tg3 NIC driver if one is found during boot and VT-d/IOMMU is enable, this should at least protect anyone updating without being aware of the possible issues. Even if the NICs are the problem it's not clear all different NIC models supported by this driver are affected, so it should also be possible to force Unraid do still use it when VT-d is enable, for anyone that wants to or believes they are not affected by this issue and doesn't want to lose VT-d.

Your should update to v6.10.1, also your server should be affected by this issue, so please disable VT-d now, if it boots OK then post new diags after array start.

Data Metadata System Id Path single single single Unallocated -- --------- --------- --------- -------- ----------- 1 /dev/sdg1 397.00GiB 2.00GiB 32.00MiB 48.10GiB -- --------- --------- --------- -------- ----------- Total 397.00GiB 2.00GiB 32.00MiB 48.10GiB Used 364.44GiB 314.58MiB 80.00KiB They confirm only cache1 is being used, you can usually fix it doing this: -stop the array -unassign cache2 -start array -stop array -re-assign cache2 -start array You should now see activity for cache2, in case of doubt post new diags.

Diags are incomplete, only the config folder is there, please grab new ones.

If it's a Dell server see here: https://forums.unraid.net/topic/119502-bzimage-checksum-error/?do=findComment&comment=1108354

Those moves should be done server side, without using the LAN, assuming same server and Windows 8 or later.