JonathanM

So change it to do what you want. That's the point of my post, here are the building blocks, assemble as needed.

You will have to rewrite this to do what you want, but I think the basic concept is there for you. This script pings an IP, waits until it responds, then runs a command. If you research the ping command you should be able to use the logic the way you want. #!/bin/bash printf "%s" "waiting for IP to respond ..." while ! ping -c 1 -n -w 1 192.168.1.1 &> /dev/null do printf "%c" "." done printf "\n%s\n" "IP is responding" docker start "Container"

I'm guessing then that you never told windows to disconnect it, which should result in "It's now safe to remove" message? https://www.howtogeek.com/685934/how-to-safely-remove-a-drive-on-windows-10/

Sometimes the USB enclosure alters the addressing, causing the partition not to start at the proper spot. Any way you can hook them up direct to SATA? Wouldn't hurt to collect diagnostics with them attached and attach the zip to your next post. In this case, either drive should be mountable, because as long as you used the parity1 slot, the two drives should essentially be a RAID1 mirror. It's possible only one drive will SHOW as mountable, because the XFS signature would be identical keeping the second drive from mounting. Since you only had 2 drives, you actually might be ok.

IF you have ALL the drives EXACTLY as they were when one drive went missing, Unraid will emulate as many drives as there were parity drives assigned at that point. Sounds like you may have hosed yourself by actively using some of the drives. You CAN start the array with a missing drive, but all the rest have to be there. Parity doesn't contain any data, just the answer to the equation formed by the rest of the data drives. When you know A+B+C+D=P, you can find the value of any single missing variable by using the rest. As soon as you remove 2 values, the answer isn't solvable for sure. Hopefully your repair works out for you.

Extended SMART test.

Do what they did to make it work.

Perfectly reasonable. The example I quote is I think from Tom (Limetech) himself, where he had a server in an unheated garage, spun up the drives and a large number of them failed. I forget the details, but it demonstrates that spinning up a dead cold drive is not healthy for it. 30c is warmish, 35 is just a little more warmish, NOTHING compared to spinning up a drive at 5c. You didn't state the environment in which you keep the server, so I gave my best answer given limited info.

Switch back to ipvlan.

Some drives report temps regardless of spin state, others don't. Your technique would work fine.

Try nomachine.

Spin up / down is less of an issue than temperature shock. If the temperature difference between spun up and spun down is small, spin them down as soon as you can, assuming they won't get spun back up minutes later. If, on the other hand, you see a huge temperature swing every time the drives spin up, I'd be less likely to spin them down. Better to keep the drives warmer than ideal but at a steady temperature than to cool them way down only to heat them way up comparatively.

If you do that, be aware macvlan causes crashes on some systems. This is the reason the default was changed to ipvlan.

There is an entire sticky thread on the topic of file system conversions that answers most if not all of your questions.

Doesn't matter much, whichever works best for you.

If you don't have any hardware passed through to VMs, and both the old and new disk controllers are straight HBA IT mode, no RAID or IR, then changing everything over will just work. No changes needed. Unraid "installs" itself fresh and redetects the hardware on every boot anyway, so it's typically seamless to move all your drives and USB boot stick to new equipment.

I don't believe that card is supported yet.

Keep in mind that the memory speed limitation may very well NOT be the memory DIMMs, it can be the memory controller on the CPU or the motherboard itself. Putting 200MPH rated tires on a toyota corolla is not going to allow the car to go that fast. All parts in the memory access path must be able to sustain the targeted speed. Run the system at stock speed (no XMP) and see how it behaves. Memtest can only prove the memory is bad, passing memtest doesn't mean the memory is working 100% under all conditions.

Contact support with the email you used to purchase the license. Or, if you keep old emails, look back through them, the info should be there.

Try a different USB stick. May also try reformatting the stick using RUFUS

Attach diagnostics from the current session to your NEXT post in this thread.

Block that IP range on your firewall. It's an automated hack attempt.

Try disabling cache dirs.