OK, Ursul0, you surprised me, THANK YOU, apology heartly accepted.
Kudos also, most people are too pig headed to do it these days.

Hey so to be clear, I don't disagree with your views on cloning, simply that as a posted cloning solution to the problem tabled.
Assuming that will work in all and every case, is a generalisation, very much dependant on specific hardware, means and ability of the person doing it.
Those guys are running a single rig, and on a learning curve, and as you well know, that is a really tough combination.
Even if you have a tiny "other" rig, at least you have the vastness of differentiation available when you're trying to troubleshoot.

Anyway, all water under the bridge, they had already done an OS install.

As you asked, to clarify, why I don't clone for clients on mining rigs, (and I DO CLONE, also with Acronis, just as you do), but not for clients.
Why? Protection, mine and theirs.
Mining involves money, my clients money.

If I make a mistake, somewhere, and have cloned 50 rigs off that, and later I find out I messed up, that is a 50x mistake multiplier I'm not prepared to risk. You can mess up just as easily by something you don't do.
With single install, I'm isolating risk, constraining it to THAT rig.`
So to be clear here, this is my CHOICE in this context, but equally none of us want to clone/deploy our mistakes either.

While it might not be THE solution, it's the one I've adopted to date. I've not had to consider building more than one or two rigs, single builds, or tiny batches if you like, so clone rollout is not a big time saver for me, and certainly does nothing to build customer confidence.

Of course I have a bunch of reg files, and envrio tweaks, so the additional deploy time is minimal, and I usually multi task while doing those build stages, so I'm not idle in that time.

One thing I often see in tech support is what seems simple to you, me, is often too complex or outside the comfort zone of the people asking for help.
Usually I probe with a few questions to get a feel for their ability and experience level, and get some dialogue going, before settling on what advice to give, and walk them through it, (not so easy on a part time forum basis).
But assuming they have, blah, blah means and ability, etc etc, actually assuming anything about them at all, is my error, and usually going to cause them more issues.

Take your logical method of driver install, (extract and do it in devman), absolutely, I could not agree more, however, while that is known to you, it's not the AMD advertised method, they steer the user to setup.exe, which does usually work, time consuming as it is, but is that the "best" method?
Well, probably for the majority, yes it is according to AMD, which is why AMD release that way.
Is it the best method you have? No.

OK, so question to you, there are a lot of postings "blaming" issues on stable rigs, after updating to this recent (April) 1803 update.
For sure, some of those cases are possibly blaming 1803 unfairly, but that isn't the question.
Have you tried that update?
What issues, if any, did you encounter?

I have a feeling this is going to be a mini-plague for the coming months, and while "don't update" is one obvious answer, I'm curious to know, specifically why that breaks, (assuming it does), and how to solve that, (other than fallback etc).
If the answer is fallback, is that the only answer, or have you recovered a rig in that situation?
Cheers