civic95man

Google may be your friend here but if you do want to try to recover anything then you need to take your array offline so nothing else will be written to it. writes to that disk will overwrite data that *may* be recovered.

yes, syslog shows disk was formatted. I suspect the emulated disk was showing as unmountable so they formatted it since it was a given option. That format option really needs to be moved somewhere else, like maybe within the individual drive's options, at least that way you have to work to find it!

Also, several of your disks are overheating. Check cooling

That will format the emulated drive and destroy the contents

Did you format the emulated drive? that is NEVER part of the recovery/rebuild process

By chance, do you have a wired keyboard you could try connecting? Maybe the Logitech Unifying Receiver is not behaving nicely with the uefi bios and therefore not initializing.

Thats the uefi bios for the VM (just like a physical computer). When you are re-installing windows, do you have the media ISO selected for the CD in the VM? Are you also passing through USB ports or at least a keyboard so you can interact with it? That countdown sounds like the typical windows installer booting from the CD image and giving you some time initiate the install before it aborts (and assumes you want to boot from other sources). Just make sure you gave the VM a keyboard in one way or another and hit [esc] as soon as it asks for it.

Sounds like maybe the pcie_acs_override option was changed. But you can't really compare apples to oranges here because of the slightly different hardware

In your syslog towards the end, its filled with this Sep 27 16:57:11 PlexHub kernel: md: disk1 write error, sector=13050290504 Sep 27 16:57:11 PlexHub kernel: md: disk1 write error, sector=13050290512 Sep 27 16:57:11 PlexHub kernel: md: disk1 write error, sector=13050290520 Sep 27 16:57:11 PlexHub kernel: md: disk1 write error, sector=13050290528 Sep 27 16:57:11 PlexHub kernel: md: disk1 write error, sector=13050290536 That looks like a failing disk for one reason or another, but further back in the log, you see this Sep 27 16:56:08 PlexHub kernel: mpt2sas_cm0: fault_state(0x7e23)! Sep 27 16:56:08 PlexHub kernel: mpt2sas_cm0: sending diag reset !! Sep 27 16:56:09 PlexHub kernel: mpt2sas_cm0: diag reset: SUCCESS Sep 27 16:56:09 PlexHub kernel: mpt2sas_cm0: CurrentHostPageSize is 0: Setting default host page size to 4k Sep 27 16:56:09 PlexHub kernel: mpt2sas_cm0: LSISAS2008: FWVersion(20.00.04.00), ChipRevision(0x03), BiosVersion(07.39.00.00) Sep 27 16:56:09 PlexHub kernel: mpt2sas_cm0: Protocol=( Sep 27 16:56:09 PlexHub kernel: Initiator Sep 27 16:56:09 PlexHub kernel: ,Target Sep 27 16:56:09 PlexHub kernel: ), Sep 27 16:56:09 PlexHub kernel: Capabilities=( Sep 27 16:56:09 PlexHub kernel: TLR Sep 27 16:56:09 PlexHub kernel: ,EEDP Sep 27 16:56:09 PlexHub kernel: ,Snapshot Buffer Sep 27 16:56:09 PlexHub kernel: ,Diag Trace Buffer Sep 27 16:56:09 PlexHub kernel: ,Task Set Full Sep 27 16:56:09 PlexHub kernel: ,NCQ Sep 27 16:56:09 PlexHub kernel: ) Sep 27 16:56:09 PlexHub kernel: mpt2sas_cm0: sending port enable !! Sep 27 16:56:16 PlexHub kernel: mpt2sas_cm0: port enable: SUCCESS Sep 27 16:56:16 PlexHub kernel: mpt2sas_cm0: search for end-devices: start -where mpt2sas is the driver for the LSI card. This is where the card s--t the bed and where all of the disk problems originated, probably due to the outdated firmware. And I asked because sometimes when a disk becomes disabled, the emulated disk appears unmountable. This can generally be fixed with a file system repair without losing much, if any, data. But in some extreme cases where it cannot be repaired or the recovered data is a mess, the contents of the physical drive may be a better choice. But really it all comes down to a case by case basis.

Yes. But I would personally move it to the array so that it isn't actively consuming space on the cache And for the record, I had this happen to me last year just after I created the VM. Don't know what caused it but it refused to boot. I have since kept a copy of the disk image on my array just in case it happens again.

You could try that. At this point it can't hurt anything. Be sure to make a backup of your flash drive so you can revert back if needed/don't remember what you did. You could also make a copy of your VM disk image to the array so that if you every want to revisit this in its current state, you would have a copy - or just a backup if you do need to start over. If you do need to start over, you can add that disk image as another disk assignment in the VM (after you have a functional windows instance) and hopefully still be able to pull data off of it if there is anything critical.

either via the start menu->shutdown or via unraid by clicking on the VM icon and select shutdown (would be equivalent to pressing the power button on a computer to signal to shutdown, provided its configured to shutdown on power button). Just don't do the force shutdown option since that's like pulling the power plug. It was worth a try click on the cache drive and select the scrub option. It will look for corruption of your cache drive, but I seriously doubt there is any as it would show up in your syslog. At this point it sounds like a win10 issue and would take the standard windows troubleshooting to fix. Could it have been a botched update?

This current beta seems to be pretty solid for people and for some its the only way to support their new hardware. Just be sure to read up on the release notes because there were some significant changes

Never tried it so I'm not up to speed on that but this line is in your syslog many times. Seems like there may be issues with your bonding: Sep 30 18:55:50 Tower kernel: br0: received packet on bond0 with own address as source address (addr:70:8b:cd:bc:02:0b, vlan:0) All of your symptoms sound like a corrupt disk image. Did the server see an unsafe restart? When the VM does boot up to that repair menu, have you tried selecting the repair option? I don't see any mention of cache corruption in the syslog but you could always run a scrub to check.

Thats another issue but you would have to determine what usb controller is in it's own iommu group and NOT used for the unraid flash drive and isolate it then you are given the option to pass that through to the VM. Not a problem, just wanted to point it out. If you are happy with your performance then keep it. BUT there are a few cases where a VM (maybe its a win10 thing) fails to boot with too many cores selected, but this doesn't seem to be your issue. It shouldn't be an issue

absolutely! I would personally disconnect unraid from the internet immediately! Then try to create a flash drive backup and then reboot your server. Chances are that whatever they placed on your server is residing in ram via the rootfs so a reboot will clear that out. Hopefully they didn't mess with the boot directory.

I would have thought that you could have just made another win10 instance, but I guess not. You could try to create it again but just change the UUID in the raw xml before saving. And yes, you would manually tell it to point the disk image to the vdisk location. You have a gpu with a bios file so be sure to set that up the same. It might be easier to take some screenshots of your configuration so that you can refer to it as you make the new one. Finally, you have 20 of your 24 cores assigned to the VM. Is that really necessary? Sometimes less is more. Remember that unraid needs cpu cycles to emulate the base hardware for the VM and to take care of other tasks. If you are worried about performance then you could try passing fewer cores but isolate them so only the VM has access to them and thus won't have to swap processes on that core. EDIT: and I personally use whatever the default USB emulation method it provides

If it's not explicitly called out as the chipset then you would have to search google for an answer. The JMB585 based sata controller seems to be a reliable alternative. Otherwise you could look at the LSI series flashed to IT mode.

Is all of your hardware working? For example, one image shows one gpu while the other shows a different

I'm assuming one image is the before and the other is the after? It looks like you added/removed some hardware which will reshuffle devices and I guess could change iommu groups. Did you disable anything in the bios or reset it?

yes to both

Looks like your LSI card is resetting - may need to check cooling/ reseat it in the slot. Also, not sure if it's related, but your're running an older version of the firmware (20.00.04.00). You should look into updating that. does the emulated drive appear mountable?

The 'tainted' keyword is because of the out-of-tree nvidia driver which was loaded. Its nothing bad or to be worried about - just lets people know that you are using an "unsupported" configuration due to that oot driver so kernel-level tech support would be limited. The call trace appears to be a kernel bug relating to kswapd and several other people are seeing this issue - according to google. It *may* not be a critical issue and can be ignored, but I don't know for sure. You could always try the beta version to see if the newer kernel fixes things.

Have you tried the beta to see if the newer kernel fixes things?

diagnostics are after reboot so the logs don't show anything; however you appear to be running a Marvell controller which is known to cause issues and therefore is not recommended. This is most likely the cause of the parity errors. Best to replace that with a supported controller and then re-sync parity