March 17, 20206 yr This is an issue I have struggling with for the last couple of days. I primarily use Mac VMs at my house. The other day I went into the unraid web console and updated unraid to 6.8.3. I was on 6.8.1 at the time. I also updated some plugins that were outdated. I restarted my server and booted into my Primary Mac VM. It worked. I shut it down and later rebooted it again, this time the VM would not boot. After much debugging I create a brand new Mac VM from the awesome Macinabox docker container (which is what I used to create the original one too) and go it installed and booting perfectly. But after about 3 boots total it will not boot anymore ether. I just get VNC saying it can't connect. Things I have tried: I have reverted back to 6.8.1 and tested the VM. No difference. I have moved to 6.9-beta (which is what I am currently running off of), no difference. I have removed all of my community apps in case they were causing any issues. No difference. I have turned off & put ACS override to Downstream. I am not even attempting any pass though at the moment, just trying to get it to boot with VNC with default XML. No difference. I have done a party check on the drives. All good. I have ran the mover. Nothing to move. I have rebooted 5+ times. I have ran the btrfs scrub process. No errors. I have looked at all the VM log... no out of the ordinary error messages that I can google.. just the typical "is tainted: custom-argv" & "warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]" which people don't seem to be too concerned about online. I have checked the concatenated Libvirt log under VM Manager. Nothing else in there. I have checked the system log for relevant errors or messages. Nothing interesting. I have downloaded the diagnostic files and looked through that, nothing is jumping out to me. I'll post them here in case I am missing something. I have NOT changed any firmware, BIOS or hardware in the time these issues have stated happening. I am so out of ideas its sad. I just want to find an error message for me to Google to fix it. I have been using unraid for 5 months now. I have setup some pretty cool stuff and have always got myself stuck and googled my way out. I can't make heads or tails with this one. My gut feeling is that my .img files are getting corrupted some how, but I have not found any way to prove that. My mind is blown and I would love some direction. studio-diagnostics-20200317-1537.zip Edited March 20, 20206 yr by Ronsper typo
March 20, 20206 yr Author Hi Everyone. I figured I should share my solution to this obscure problem. The reason there was no error message to be found turned out to be simple. There was no errors after all. I am using a AMD graphics card for my Mac VM. When the VM boots with the pass though graphics, video output does not happen till the graphics driver loads / runs in the macOS boot press, about 60% of the way though the apple logo loading process. This is when my monitors get signal. This means that I never get visual of the Clover / Mobo boot processes. If I switch the xml to VNC then I will get video of the whole process. This is a well documented issue in the forums related to the exact mobo / graphics and not a deal breaker once you understand it. However, I have 2-3 macOS installs on unraid. Most of these installs use copies of xml configs that I paste across VM configs. My Mac configs have custom os loader & nvram file paths. <loader readonly='yes' type='pflash'>/mnt/user/domains/MacinaboxCatalina/ovmf/OVMF_CODE.fd</loader> <nvram>/mnt/user/domains/MacinaboxCatalina/ovmf/OVMF_VARS.fd</nvram> When I pasted the configs across the different Mac VMs I didn't change this path to be unique. This created a scenario where all my of Mac VMs were running on the same loader & nvram. This is not an issue by itself, but combined with the issue with the blank output above.. it sent me on a wild goose chase. What was happening in the above post is this: When I booted up into a VM, clover would store the last booted volume in this shared state (nvram / loader). This is great so that Clover just boots into what it booted last time. On subsequent boots it would try to prefer this volume, but if it was a different VM, Clover would not be able to find the last volume and the net result would be Clover just waiting on the bootloader screen indefinitely because it didn't know what to do. If this happened with my Graphics card passed though it would hang forever on a black screen. Once I separated the nvram & loader per VM (by adjusting the file paths in the XML) & booted the VM into VNC, picked the correct boot volume, rebooted with my graphics passed though for each VM, everything works again. I can boot into each VM no issues. This is the root problem I experienced. I hope this helps someone in the future. Edited March 20, 20206 yr by Ronsper
Archived
This topic is now archived and is closed to further replies.