JorgeB

Diags posted are not the generated zip.

Syslog is just after rebooting, not seeing any errors, grab and post the complete diagnostics (tools -> diagnostics) after the problem manifests itself.

Those are all normal.

You should always check if the emulated drive is mounting or if it can be fixed before starting a rebuild. Disk16 is already rebuilt, I assume that went well? As for disk 10 there's fatal filesystem corruption, you'll need to use the old disk, assuming it's still available, after doing a new config and running a parity check try upgrading again, but only after trying to fix these, they suggest a power/cable problem: Aug 26 14:12:21 storage kernel: sd 11:0:6:0: Power-on or device reset occurred ... Aug 26 14:12:21 storage kernel: sd 11:0:6:0: Power-on or device reset occurred ... Aug 26 14:12:21 storage kernel: sd 11:0:6:0: Power-on or device reset occurred ... Aug 26 14:12:21 storage kernel: md: disk10 read error, sector=2246592 Aug 26 14:12:21 storage kernel: md: disk10 read error, sector=2246600

There's an "I'm sure" or similar check box next to the start array button, just need to check that after unassigning the device.

Not after rebooting, if it happens again grabbed them before, if it's not possible, even when using the console, try to at least get the syslog.

Any writes will make parity out of sync, UD supports read only mode, this will keep parity in sync, but it's not possible to use if the disk needs a filesystem check first like in this case.

Nginx was doing the log spam: Aug 24 02:30:14 storage nginx: 2021/08/24 02:30:14 [alert] 18120#18120: worker process 2628 exited on signal 6 Aug 24 02:30:16 storage nginx: 2021/08/24 02:30:16 [alert] 18120#18120: worker process 2633 exited on signal 6 Aug 24 02:30:18 storage nginx: 2021/08/24 02:30:18 [alert] 18120#18120: worker process 2669 exited on signal 6 Aug 24 02:30:20 storage nginx: 2021/08/24 02:30:20 [alert] 18120#18120: worker process 2676 exited on signal 6 This is usually GUI related, sometimes caused by having multiple browser windows opened on the GUI, see if it happens again after this reboot.

Syslog is missing a lot of time due to spam, but when this happens it means the disk dropped offline then reconnected with a different identifier, SMART for the disk looks OK, if the emulated disk is mounting and contents look correct you can rebuild on top, good idea to replace/swap cables/slot first to rule that out if it happens again to the same disk.

You should have backups of anything important, many ways to lose data.

Yes, also, and if parity is valid, you can check "parity is already valid" before array start.

Both devices from downloadpool and steampool are in the same pool, something went wrong during device removal. You can do this: Stop the array, if Docker/VM services are using this pool pool disable them, unassign the devices from both pools, start array to make Unraid "forget" those pools config, stop array, reassign both devices to the same pool, the one the this data belongs to, downloadpool or steampoolall (there can't be an "All existing data on this device will be OVERWRITTEN when array is Started" warning for any pool device), re-enable Docker/VMs if needed, start array. Now repeat the pool device removal, make sure you just unassign one the devices, don't assign it to a new pool until it finishes balancing the other pool, you can post new diags after doing this to confirm all is good.

Array needs to be started or there won't be any info about the pools.

Please post the diagnostics: Tools -> Diagnostics

Yes, if not it's run with the no modify flag, and nothing is done.

It was unRAID, now it's Unraid.

You should be able to run a filesystem check from UD, but I don't use encryption, so not sure.

Check filesystem don disk1: https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui Run it without -n or nothing will be done, and if it asks for -L use it.

You won't lose the data, but they won't go to the main pool, it's just for when you start the array without cache Unraid doesn't create new docker/libvirt images, also make sure cache backups are up to date before doing this, not a risky operation but just in case.

Then you're fine.

This is not a bug but a general support issue, next time please use the general support forum. You're having USB issues, and not just with the flash drive: Aug 26 04:17:00 LaptopUnraid kernel: usb 3-2.4.4: USB disconnect, device number 6 Aug 26 04:17:00 LaptopUnraid kernel: usb 3-4: USB disconnect, device number 3 Aug 26 04:17:12 LaptopUnraid kernel: md: disk1 write error, sector=128 Aug 26 04:17:12 LaptopUnraid kernel: md: disk1 write error, sector=136 Aug 26 04:17:12 LaptopUnraid kernel: md: disk1 write error, sector=144 Aug 26 04:17:12 LaptopUnraid kernel: md: disk1 write error, sector=152 Aug 26 04:17:25 LaptopUnraid kernel: xhci_hcd 0000:05:00.4: xHCI host not responding to stop endpoint command. Aug 26 04:17:25 LaptopUnraid kernel: xhci_hcd 0000:05:00.4: USBSTS: HCHalted HSE Aug 26 04:17:25 LaptopUnraid kernel: xhci_hcd 0000:05:00.4: xHCI host controller not responding, assume dead Aug 26 04:17:25 LaptopUnraid kernel: xhci_hcd 0000:05:00.4: HC died; cleaning up Aug 26 04:17:25 LaptopUnraid kernel: usb 5-1: USB disconnect, device number 2 Aug 26 04:17:25 LaptopUnraid kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s Aug 26 04:17:25 LaptopUnraid kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 03 31 b0 00 00 20 00 Aug 26 04:17:25 LaptopUnraid kernel: blk_update_request: I/O error, dev sda, sector 209328 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0 Aug 26 04:17:25 LaptopUnraid kernel: usb 5-2: USB disconnect, device number 3 USB for array/pool devices is not recommended, for the flash drive try another port, ideally a USB 2.0 port.

It might if it's a RAID controller, any true HBA should be fine.

Syslog posted only show errors on disk7, but errors like that on multiple disks are usually a power/connection problem, see if those four disks share anything, like a miniSAS cable or power splitter, 400W for 12 disks is also low, if changing cables doens't help you should try with a more powerful PSU.

Yep, log is clean.

Not that long on an SSD, and you can keep using that server.