XanderLort

Members
  • Posts

    11
  • Joined

  • Last visited

Everything posted by XanderLort

  1. Regarding the Factorio Unraid docker: I set it to latest, I do have a cache drive, and I tried the factorio folder both default (appdata) and on the array, though on a mount that uses the cache as a scratch area.
  2. Issue with the Factorio server docker: I use Community Applications in UnRaid to install the Factorio docker. The container seems to download and start fine, but the log keeps spamming "standard_init_linux.go:190: exec user process caused 'no such file or directory'". Additionally, when I try to connect to the docker console I get the message "Error response from daemon: Container ... is restarting, wait until the container is running". It seems like it's getting stuck in an infinite restart loop. Any suggestions on what I should do to get it running?
  3. Agreed - this whole thing is a hypothetical situation where someone did not know there were emulated writes to the disk before doing a "trust my array" operation, but then wanted to recover those writes. Not sure if there is a mechanism for knowing whether there were emulated writes to the disk or not.
  4. Correct, which is why the emulated writes to the parity only will persist until they are specifically overwritten by writes to those sectors (or a parity update operation across the whole array).
  5. I am not trying to accomplish anything with the "Trust My Array" step - only trying to gain a conceptual understanding of how it, the parity calculation process, and the drive rebuild process interact with each other. My point is that after you do a Trust My Array, the parity still contains the emulated write data until it is overwritten by either a parity update operation, or additional writes (to the same sectors). Rebuilding a drive with that data in the parity will include the emulated writes. I think... it might be possible to test using an externally removable drive and removing it in the middle of a write.
  6. Agreed. But, as long as you don't do a parity update and don't do any more writes to the drive, you should be able to replace the problematic drive and re-build it with the contents of the parity, which include the emulated writes, at which point everything is correct and all data is available. So the sequence of events would be: Drive encounters a write error and gets disabled with emulation (non-parity drive). Writes occur to the disabled drive, actually get written to parity-only. At this point, the parity is invalid as compared to the array in the written sectors. Do a "Trust My Array", do not re-calculate the parity. Do not write anything else to drive. Replace the drive and re-build that drive. After re-build is complete, drive is restored with emulated writes and parity is in sync. Or am I missing something? (This is all for conceptual understanding only - I'm a software engineer, so I'm not being intentionally frustrating )
  7. A "Trust My Array" operation does not re-calculate the parity though, as when it comes back up you check the "Parity is already valid" box. By that logic, as long as you don't re-sync the parity you should be able to re-build the lost drive with the emulated writes. Addendum: I understand it is bad practice and a generally terrible idea, I am just trying to make sure there isn't an intermediate product being stored that would remove the emulated write data from the parity drive.
  8. So, if I did a "Trust My Array" operation, but did not do a parity-sync, the writes should be preserved for when I replace and rebuild that drive?
  9. Recently had a drive fail and was reading on the troubleshooting procedures, which talk about potential writes to the emulated drive? Where do those writes go? Are they lost upon a reboot? Are they preserved in the parity disk? If they are preserved in the parity disk, would the writes survive someone doing a "trust my array" operation? Referenced troubleshooting steps taken from here: https://wiki.unraid.net/Troubleshooting#Re-enable_the_drive
  10. Here's the goal: One Ryzen 7 1700X machine running the unRaid base, with two virtual machines: Ubuntu Desktop, and Windows 10, each with their own passthrough GPU, mouse, and keyboard. I want all 16 cores available to both VMs - they will be for software development, and some VR gaming on the Windows VM. The GPUs are a 1060 for the Windows VM and a 1050ti for the Ubuntu VM, and there is a GT 710 for unRaid to hold onto because it fits into a PCIEX1 slot... yes, three NVIDIA cards. I know, I know. MOBO is an MSI Gaming Carbon Pro X370. After wrestling with PCIE slots, IOMMU groups and the ACS patch, I have successfully been able to pass through the 1050ti to a new Ubuntu VM and install it. However, I was met with weird functional issues once inside Ubuntu, such as being unable to open the "Displays" GUI to change the resolution. I installed the latest NVIDIA drivers in the VM and was met with a colorful, pixelated screen of GPU agony, which unfortunately persisted after multiple VM reboots. That and further attempts at different VM configurations revealed the following: CPU must be Host Passthrough. If using QEMU64, Ubuntu won't install. Bios must be SeaBIOS. I was using Q35-2.9 because that's the default in the Ubuntu template and frankly, I have no idea what it means. So here's the actual question: Are there things I've misconfigured, or steps I've omitted? Or, is Ryzen support not quite there yet? Or is this just not possible? I'm a software engineer and reasonably seasoned Linux user, but totally new to KVMs and all this virtualization magic. The relationship between virtual machines and drivers when doing passthrough is a relationship I don't understand either. Any advice or ideas on things to try is much appreciated! And I will of course post my results back if (when) it does work.