jordanmw

I had to boot it for first install without VNC graphics. No matter what I did, if I added VNC graphics, I got code 43. So instead, I stubbed the card, dumped the bios, and then set only that card for video- then did a full windows install and added geforce drivers- that has worked for me every time. Not sure why- but others have had success with that method.

I did dump my own bios for the first card that unraid grabs- removed the header and set it to do rom passthrough. Since it wasn't the only card, none of my others required that to work properly.

I had this issue until I setup a new machine without vnc graphics- with only the graphics card attached and hyper-v disabled, then did a physical install of windows without vnc. Not sure why it worked, but worth a shot.

Are you using the Epyc hack for processor identification? It seems that helps some of us with TR CPUs.

Check this out:

Also curious what you are doing for this- have you tried using RRTR?

That change should have absolutely no effect if the card is stubbed properly. I changed 2 of my 960s to 2070s a few months ago and the biggest changes that I had to do were to get all of the IDs for that card to pass through- including the USB and sound devices on the card. Note: the old card only had 2 pcie devices but the new one has a 3rd for the USB 3 device that the card contains. I didn't even have to change drivers before it would boot(just as fast as always).

Looks like mine works now too- and I have to say JDK- the 18 experimental version of ALPHA 18 is fully worth it! They have really changed and improved so many things... and this is from a guy who has 1982 hours into that game. I particularly like the re-balancing and removal of level cap for perks. I was so pissed in A17 being level 80 and not being able to craft a 4x4. And the Turrets syndrome perk looks like a awesome addition.

An experimental of an ALPHA game.... right. Can't help but be a little jaded after being a die hard and seeing so many builds with glitches that get the whole community pissy. Eh, hey.. maybe I'll give it a shot, just this once. How do you add -beta latest_experimental to the steamcmd update command?

Knowing the fun pimps... they'll wait until the week before x-mas before dropping it! They never release on time- even when it's their own timeline!

Thanks Squid- yeah, I'm at max length. Maybe you are right and I just need to tweak refresh settings. I'll have some time to test things more thoroughly this weekend. Don't know why I haven't tried just swapping cables.... duh!

Well I did try a new PSU- with the same results. Here is the crazy part- at this point I think it's hdmi cables that are causing the issues. I ran a few experiments and if I use a shorter hdmi for VM#1 it never goes black, but VM#2 does if it is still using the longer cables. VM#3 even does it for a few minutes. Screen goes black, flashes on and off for maybe 5-10 minutes, then everything works properly again on all VMs and we continue playing for another 90 min or so before it happens the exact same way again?!? My only guess at this point is that the longer cables are causing errors that stack up for 90 minutes before crashing some kind of buffer and restarting that buffer. Anyone know anything about hdmi length causing these kinds of issues? What kind of error in hdmi signals can cause this kind of behavior?

Well, after understanding the configs were still in my most recent diagnostics upload- I used that to get back all my config- sans plugins. Everything ran for a while again and then froze and erased my config again! Guess I will have to use the internal USB ports since the ones on the back are all USB 3.0. I rebuilt again and will try the internal port as soon as I get a chance tonight. Seems insane that just using a usb 3.0 port would cause this repeated issue......

What is the order of operations once I have rebuilt the flash drive? If I don't get everything exactly perfect with the setup- what things should I avoid doing to preserve my data?

Thanks johnnie- any ideas on how this could have happened- or what I can do to prevent a re-occurrence?

Really not feeling supported in any way at this point- guess I am on my own! AWESOME!

30 views and nothing yet? Has anyone seen any thread like my issues? Maybe one with some recovery methods that might leverage my diagnostics to recover my config?

I had an issue last night that wiped out my config on my usb and the web gui was completely not loading. I had 4 vms up and running and one docker- then everything froze. I powered it down and on reboot- it picked up a dhcp address but wouldn't load the gui on the web or physically. I ran diagnostics but they show no shares at all and no configs.... really concerning since I didn't backup my USB after upgrading to 6.7. SO I am going to attach 2 diagnostic files- one from a few days ago- and one after it happened. PLEASE- someone help me out in figuring out what happened- and recovering my system. The usb drive is completely readable but shows a large number of fsk files. I can open all the files I have attempted from that drive still. Really need someone to point me in the right direction to restore properly. I should mention that I upgraded CPUs- changed core assignments- and swapped a couple of graphics card locations since I upgraded to 6.7. tower-diagnostics-20190619-0744.zip tower-diagnostics-20190617-0305.zip

Nope- no streaming. All machines are physically accessed. The only streaming I do is from a shield with steamlink. 4 gamers in one room is what we do for our sessions.

Yeah- 1920x1080 framerates are 40-60 on my 960s- and 60-100+ on my 2070s. I have a USB card with 4 separate controllers- each passed to their own VM. No issues with input lag or stuttering.

Going to agree with him there- anything over stock 2667 has a much larger chance of causing stability issues and possibly data corruption. Even XMP profiles rarely work as expected.

You may have to dump the GPU rom and edit the header before passing it through to that VM. Check this process at 2:20 ish:

Mine are all setup with i440x and ovmf, but others have had good results with the opposite. I honestly, didn't compare them and just went with the defaults- since it worked, I haven't tested the others.

This isn't windows land- unfortunately unraid is pretty sensitive to overclocking and ECC ram is even recommended to prevent data corruption. I can overclock the crap out of my rig with a bare metal windows install but unraid will freak out on those same settings after I start a few VMs and dockers. I highly recommend just getting rid of all overclocking- even if just to test. Once you have things stable on stock clocks- depending on how much pain and suffering you can endure- you can start tweaking but really need a great way to stress test the entire machine- not just single VMs on the host.

I believe the trick here is to edit the header of the bios file with a hex editor as in his video here: Skip to 2:20 where he explains editing the header out of the file before use.