trurl

Go to Tools-diagnostics and attach the complete Diagnostics zip file to your NEXT post.

Probably a connection issue. Examine all ports, plugs on server, router, switches. Try another cable.

You must boot from a device with a GUID. You can try that SD reader but if it doesn't show a valid GUID on the Registration page it won't work. Better, simpler and more reliable to just use a brand name USB2 Flash in a USB2 port, 4GB to 32GB capacity.

Access it by IP so you can get in and change it to a shorter name.

Preclear isn't necessary for your older disks since they have already been "burned in". An extended SMART test and a good SMART report should be good enough. Do any of your disks show SMART warnings on the Dashboard?

The new Flash would get a new key and the license would be transferred to that new key. Is the file in a public share? How was the file created?

Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post.

Doesn't seem like you have actually captured a syslog after a crash since the one you attached was basically the same as that in the diagnostics, and the array wasn't started.

https://wiki.unraid.net/index.php/Replace_A_Cache_Drive

You can copy the data from the emulated disk1 to other disks then remove disk1. I recommend the "Remove and Rebuild Parity Method" from that link. It is simpler and just as fast. At step 4 New Config you can assign the disks however you want. Just make sure you don't assign a data disk to the parity slot.

There is no way to remove a drive from raid0 since it has no redundancy. Each of the drives is assumed to have contents the other doesn't. You would have to backup cache and start a new cache with only one disk.

Sort of lost track of the rest of the thread. Then, putting that together with the FAQ raid0, which you say you successfully converted to, is not redundant.

It might be possible to get Unraid to rebuild that other disk instead, but it is unclear how successful that might be without more details. Probably that is the only choice though if that other disk is truly dead. SMART for the disabled disk looks OK.

The disabled disk is the one Unraid wants to rebuild. In order to do that, it must be able to read ALL of the other disks, including that other one that is clicking. How exactly did you get into this position? Can you give more details about when each disk began to show problems? Do you have backups of anything important and irreplaceable?

My bet is on the BIOS deciding to boot from one of your "new" hard drives.

I don't notice anything in those, except it looks like you are using 11G of 30G docker image with no dockers running. Have you had problems filling docker image? Have you done memtest?

Were you hoping to recover any of the data those disks had? Since you only have single parity you can only rebuild 1 disk at a time. Do you still have the "failed" disks? What evidence do you have that they actually failed instead of some other problem like a bad connection?

It's possible your BIOS decided to "help" you out when you changed disks around, and it is trying to boot from those disks now instead of from the Unraid flash. Does your router see the server? Can you ping it? You will probably have to get the monitor and keyboard to see what is happening during boot.

You really must not allow this to happen. Fix this cooling problem or it will only cause more problems. Most people only do monthly parity checks. Some even do less frequently for servers that aren't always on. Parity checks aren't required to maintain parity, they are just checks. Parity is always updated in realtime. You didn't answer this question: Some people mistakenly think parity is the most important disk. In order to rebuild a missing disk, parity PLUS ALL remaining disks must be reliably read in order for the parity calculation to get the data to rebuild. Parity by itself can't recover anything. Also, parity doesn't actually contain any of your data, unlike the data disks. So arguably parity is the least important disk. Have you ever replaced a disk before? Do you know how? Please ask for more advice if you are unsure.

Array not started in those so can't tell anything about filesystems or shares, though those wouldn't be expected to cause a crash. Does it in fact crash even if you never start the array?

Diagnostics are after reboot so can't see anything about that failed parity check. Was that a correcting parity check? Why are you doing weekly parity checks anyway? You should always try to get diagnostics before rebooting, or setup Syslog Server so you can retain syslog after reboot. https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=781601 Yes, that disk must be replaced. But keep it handy in case there are problems with the rebuild since it's not entirely clear what the state of parity is.

Your exact wording here is a little bit different than that in the FAQ you quoted, so it makes me wonder if you actually did what it said. Stop the array Unassign the one cache pool disk to remove (and do nothing else) Start the array Wait for it to complete as indicated by the Stop button being enabled. Is that what you tried to do?

Also, here is the wiki on upgrading to V6: https://wiki.unraid.net/Upgrading_to_UnRAID_v6

Where are you putting that command? Have you seen the Unraid FAQ pinned near the top of this same subforum?

me too