JorgeB

Jan 26 13:20:07 MediaCenter emhttpd: device /dev/sdm problem getting id Jan 26 13:20:07 MediaCenter emhttpd: device /dev/sdj problem getting id Jan 26 13:20:07 MediaCenter emhttpd: device /dev/sdab problem getting id Jan 26 13:20:07 MediaCenter emhttpd: device /dev/sdk problem getting id Jan 26 13:20:07 MediaCenter emhttpd: device /dev/sdy problem getting id Jan 26 13:20:07 MediaCenter emhttpd: device /dev/sdh problem getting id Jan 26 13:20:07 MediaCenter emhttpd: device /dev/sdac problem getting id Jan 26 13:20:07 MediaCenter emhttpd: device /dev/sdz problem getting id  
These suggest Unraid is seeing multiple disks twice, Unraid does not support SAS multipath, make sure only one cable goes from the server to the enclosure, then post new diags after the disk replacement starts, if you cannot get them at that time post at least the syslog:
 
cp /var/log/syslog /boot/syslog.txt  

Looks like the server rebooted on its own, no parity check was started in those logs and parity is still invalid, and a server rebooting by itself is usually a hardware issue, or bad power.

As long as Destructive mode is enabled in the UD settings, you will see something like this after reconnecting the other device:
 

 
Click the red X to wipe the partition.

Macvlan call traces will usually end up crashing the server, switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enabled, top right)), then reboot.

Disk was already disabled at boot, so we can't see what happened, SMART looks OK but has very few attributes, is this a white label disk? You can replace/swap cables and rebuild the disk or if you prefer do a new config without and resync parity.

Select the Unraid flash drive in Boot Override, I assume it's the SwissbitUSB?
 
If UEFI boot is enabled in the flash drive (an EFI folder must exist, not EFI-), and it boots UEFI on a different PC and still doesn't on that one I'm sorry but I don't have more ideas.

The problem was the log tree, so that was the correct fix, if that was the only issue the pool should be fine now, if the same issue reoccurs in the near future, and that is not that uncommon, then I would recommend reformatting the pool.

Did you reboot after changing to ipvlan? Also there are a lot of OOM errors.

Pool is corrupt, before doing anything else I would recommend running at least a couple of memtest passes, if nothing is found see if the pool mounts read-only:
 
zpool import -o readonly=on tier1-cache  
If it does, start the array, it will still show unmountable on the GUID, but the data will be under /mnt/tier1-cache, then backup what you can somewhere else, note that the corrupt file will fail to copy.

You likely have a hardware issue, also make sure this has been taken care of:
 
https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173
 

I assume they are connected to the onboard SATA controller? If yes there's no link, do you hear the disks spinning up?
 
Feb  6 14:48:18 unraid kernel: ata1: SATA link down (SStatus 0 SControl 300) Feb  6 14:48:18 unraid kernel: ata7: SATA link down (SStatus 0 SControl 300) Feb  6 14:48:18 unraid kernel: ata2: SATA link down (SStatus 0 SControl 300) Feb  6 14:48:18 unraid kernel: ata3: SATA link down (SStatus 0 SControl 330) Feb  6 14:48:18 unraid kernel: ata4: SATA link down (SStatus 0 SControl 330) Feb  6 14:48:18 unraid kernel: ata8: SATA link down (SStatus 0 SControl 300) Feb  6 14:48:18 unraid kernel: ata9: SATA link down (SStatus 0 SControl 300) Feb  6 14:48:18 unraid kernel: ata10: SATA link down (SStatus 0 SControl 300)  
P.S. you are also having flash drive issues:
 
Feb  6 19:40:32 unraid kernel: usb 8-1: USB disconnect, device number 2 Feb  6 19:40:33 unraid emhttpd: Unregistered - flash device error (ENOFLASH3) Feb  6 19:40:33 unraid kernel: md: unRAID driver removed Feb  6 19:40:33 unraid emhttpd: scandir: /boot/config/pools No such file or directory Feb  6 19:40:33 unraid emhttpd: shcmd (17340): /sbin/modprobe md-mod super=/boot/config/super.dat Feb  6 19:40:33 unraid kernel: FAT-fs (sda1): Directory bread(block 29634) failed Feb  6 19:40:33 unraid kernel: FAT-fs (sda1): Directory bread(block 29635) failed  
Try a different USB port, ideally USB 2.0

This could be the issue, some USB bridges are not transparent, if that is the case the data will only be accessible using the same one, try that.
 
 
No worries.
 

Pool has logs and cache vdevs, to use them you need to reimport the pool with all devices assigned, see the end of this post for how to reimport the pool:
 
https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=1256329
 
 

@takekoI missed earlier that the issue you are having is because the flash drive is not being detected:
 
Feb  7 03:07:37 Tower emhttpd: Unregistered - flash device error (ENOFLASH4)  
That's what causes the other errors, try resetting the board BIOS to defaults, if the same you may try playing with any USB related settings.

You can try that, I remember seeing other users with the same issue and trying a different Linux OS with a similar kernel didn't help, confirming it's not an Unraid issue.

You can copy super.dat and the pools folder from the old flash for the assignments.

That should work, assuming the raid volumes are presented to linux.
 
 

See if anything on this thread helps:
 
 

The MCE appears to be CPU related, for the disk errors please post the complete diagnostics after some errors.

It's not logged as a disk problem, and SMART looks fine, so most likely a power/connection issue.

Make sure this has been taker care of:
 
https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173
 
If it doesn't help enable the syslog server and post that after a crash.

I'm sorry, I didn't read the 1st post correctly, you can only expand a zfs raidz pool by adding a new vdev of the same width, this is a zfs limitation, not Unraid, in this case you need to add 3 new disks.

It will change if you add a new VM, or change the configuration for any existing one.

Not that I can see, you can try disabling docker and VM services, then enable just the services, test to see if everything is stable, if yes, start enabling the containers and VMs one by one and retest.