cat2devnull

So it looks like QEMU is having issue with accessing your card (assuming it is on address 04:00.0 and 04:00.1 When trying to debug an issue with passing a video card to the VM there are many things to consider/try. 1) Ensure the card is in its own IOMMU group and not sharing a group with any other hardware. Also ensure that it is stubbed so that the host OS doesn't take control of the card. 2) Ensure your config is correct. Here is an example from my config. My card is on bus 0x12 and I pass it to bus 0x04. <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x12' slot='0x00' function='0x0'/> </source> <rom file='/mnt/user/isos/vbios/Yeston-RX550-4G-LP-D5.rom'/> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0' multifunction='on'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x12' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x1'/> </hostdev> 3) Try passing the VBIOS The goto place for VBIOS files is TechPowerUp but most people recommend that you rip your own BIOS. Spaceinvader has written some software and made a video that is easy to follow. 4) If it is the primary GPU in the system you will need to prevent the Linux OS from using the virtual frame buffer to display the boot process. So under Main -> Flash you can add video=efifb:off to the Unraid boot option. More details can be found in this blog. If you need more help than this, you will need to provide us more information. - The motherboard, CPU and video card(s) details. - Also the relevant logs from the Unraid OS and VM. Also be aware that weird things can happen when you upgrade Unraid (aka upgrade the host OS kernel). I ran for years without needing to do anything but then after one upgrade I suddenly needed to stub the card. Then another upgrade and I had to pass a VBIOS. Then last upgrade to 6.10.0-rc2 I needed to enable efifb:off. Good Luck!

There are very few single slot cards out there. I've had success with the Yeston RX550. Single slot, <40watt, full hardware encode/decode, modern Baffin core and inexpensive (by today's standards ~$100USD). I did a big post about it here; https://forums.unraid.net/topic/84601-support-spaceinvaderone-macinabox/?do=findComment&comment=1052456 http://www.yeston.net/product/details/234/272 As with ghost82, no issue with DRM once I added unfairgva=1 to the boot options in my config.plist Should be perfect unless you want to do AAA gaming.

You can check for yourself here; https://dortania.github.io/GPU-Buyers-Guide/#a-quick-refresher-with-nvidia-and-web-drivers From what I can see that's a negative because Maxwell support was dropped post High Sierra; https://dortania.github.io/GPU-Buyers-Guide/modern-gpus/nvidia-gpu.html#maxwell-series-gtx-9xx-745-750-ti

If you pass the NVMe device through in its IOMMU group then the hardware is available to the OS. I can see my drive temps via smartctl so any software should be able to do the same.

Some dockers will exit on boot if they can't write to their appdata folder. In my case I'm playing with prometheus and it was behaving this way. So what's the best way to allow the docker access to its appdata files if its using uid=65534(nobody) gid=65534(nobody)? Should I add these to the Unraid server?

I think this is a reoccurring issue that people start hitting as they get deeper into the world of Unraid and Dockers. I have started running into issues with users and groups. I see that Unraid normally runs dockers nobody:users (user 99 and group 100). I've been using a lot of linuxserver.io dockers that allow you to set the user/group in the docker GUI. When set to 99 & 100 then permissions on the filesystem all work. Within the docker id is as follows; root@361b22374b0e:/# id uid=0(root) gid=0(root) groups=0(root) I've been playing with some other dockers that don't seem to have any way to set the user/group. In order to get them to boot I have to set permissions on their appdata folder to 777. Then from within the docker the id looks like; /mydocker $ id uid=65534(nobody) gid=65534(nobody) Obviously setting a dockers files to 777 is a security nightmare. Is there anyway to force the user/group of a docker? How does the mapping between the user/group of the docker and the underlying OS (Unraid) work? Is there any good documentation I can read? Thanks,

Don't forget that any devices not on bus 0x00 will be considered 'external'. The video card should be external (as though it is plugged into a PCIe slot) but the NVME drive should be internal otherwise the machine thinks you're booting off an external drive. You can override this in the OC config but it is easier just to fix the VM xml. Take a look at; As always, be very careful using OC configurator. It is very version dependent and can break your system as easily as fix it. You would be much better off just using an XML aware editor or ProperTree. You should be able to get your VM to work under Unraid 6.10 The change in linux kernel sometimes causes weird things to break. When I went from 6.8 to 6.9 I needed to load a ROM for my video card. When I went from 6.9 to 6.10 I needed to stub my video card. Both times I was able to identify the issue because when I tried to start the VM it spat mountains of PCIe bus errors. Once you have everything working nice and stable, give it another go.

General advice of things to try; - With/without the VBIOS - With/without stubbing the card - Ensure you're passing the video & audio component of the card together <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x12' slot='0x00' function='0x0'/> </source> <rom file='/mnt/user/isos/vbios/Yeston-RX550-4G-LP-D5.rom'/> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0' multifunction='on'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x12' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x1'/> </hostdev> - Check the Unraid server logs - Check the VM logs It's unusual to need ACS override on any modern motherboard. I would try updating the BIOS first.

Yes to both; <graphics type='vnc' port='-1' autoport='yes' websocket='-1' listen='0.0.0.0' keymap='en-us'> <listen type='address' address='0.0.0.0'/> </graphics> If I use Max or 2560x1440 (which is the max) then I get a black screen with only the small writing in the bottom right corner. 1920x1080 with any color depth gives 1 icon as above. 1280x720 with any color depth gives more icons but the same issue when using the arrow keys. So this is a common misconception... The AMD RX550 does work in OS X OTB with one BIG caveat. You have to buy the right one! The original RX550 released in 2017 used the unsupported Lexa core but in 2018 it was rereleased with an updated and now supported Baffin core. Why AMD decided to update the chip but keep the same model number is anyone's guess. Most board partners make cards with both chips. The trick to spot the difference is the compute unit count, stream processor count, GPU and memory speed. 2017 Lexa Core - Polaris 12 (incompatible) CUs 8, 512SP, RAM 1750MHz (7000Mz effective), GPU 1183MHz 2018 Baffin Core - Polaris 11/21 (compatible) CUs 10, 640SP, RAM 1500MHz (6000Mz effective) GPU 1071MHz I did a nice post about it here with more details;

So just out of interest I re-enabled the GUI picker and it is still doing the same thing. I'm still using VNC at this stage but will move to my RX550 in the next few days. The first image is what it looks like on boot and the second shot is after hitting the arrow keys to try and choose a different boot option. My settings are; Misc -> Boot -> PickerMode: External Misc -> Boot -> PickerAttributes: 17 Misc -> Boot -> PickerVariant: Acidanthera\GoldenGate UEFI -> Output -> 1920x1080@32 Any ideas appreciated.

Awesome... I new I had broken something in a dumb way and just couldn't see the forest for the trees. So I built the config.plist from the template but ran it through a pre 0.7.5 version of Propertree that built the drivers section in the old format. That explains why it couldn't see the HFS+ volume which is what I thought but didn't understand why. I thought I had already run it through ocvalidate but I must be getting confused (I've been playing around with several VMs for the last few weeks). Yep, this is just from me messing around. I have never managed to get the external picker to work. I get strange graphical distortions (each icon is huge) that make it impossible to use. It hasn't annoyed me enough to look at again since OC 0.5.x but I have always left it there for the day I have some spare time. Now I am going to rearrange my PCIe bus config which I have been meaning to do for 2 years. Then I can add my GPU, USB and NVME drives. I just have to go and refresh my memory as per your post... Thanks again @ghost82

Ok, so I'm running out of ideas so hoping the community can help. I've been running a Mac VM for years on my AMD system. Originally on Clover native, then switched to OpenCore in Unraid. It's been relatively smooth sailing excluding the odd AMD GPU bug etc. OpenCore and OS X upgrades have been straight forward. A few days ago I wanted to go to OC 0.7.5 and trial Monterey, (currently on 0.7.1 with BigSur). I decided to build a fresh VM to test with before migrating my production desktop. I downloaded the Monterey installer, made a 16GB GPD HFS+ .dmg, used createinstallmedia to make the install media. Followed the OC install guide to make my EFI folder and put that into the .dmg. Renamed it to a .img and fired it up. OC boots but no option for install media, just reset NVRAM and OpenShell.efi I've tried setting ScanPolicy to 0, changing SecureBootModel from Default to Disabled and a myriad of other bits and pieces but nothing makes a difference. I can only assume I am missing something silly... I am only running the basic latest drivers (OpenCanopy.efi, OpenHfsPlus.efi, OpenRuntime.efi) and kexts (AppleALC, IntelMausi, Lilu, VirtualSMC, WhateverGreen). A pretty simple setup. I've attached the OC logs, which seem to show it finding 2 valid filesystems. This boot I pulled the EFI partition into a separate .img file so I could mount/unmount easily. I think it should have found 3 filesystems. 1) EFI-075.img - EFI partition 2) Monterey.img - EFI partition 3) Monterey.img - HFS+ install media partition I wonder if it is ignoring HFS+ partitions??? If anyone has any thoughts it would be greatly appreciated. config.txt VM.xml opencore-2021-11-19-090547.txt

Good to hear. It may have just been a minor fault in the drive that was only showing up when you had the drive running at full gen4 speeds.

I was in the same boat, just needed a low power, low cost card with modern support for HDMI 2.0, DP 1.4, 4K@60Hz, H264/H265 Hardware encode/decode, HDR, PCIe 3.0, etc all in 30 watts... I ended up going for an AMD RX550. The trick is that there are two versions sold as the RX550 so you need to get the right one. The way to work out the difference is down to memory speeds and stream processors (SPs); Old Lexa Core - Polaris 12 (incompatible) Stream Processors 512 (CUs 8 - 512SP) Memory Speed 1750MHz (7000Mz effective) Reference Clock 1183MHz Newer Baffin Core - Polaris 11 & 21 (compatible) Stream Processors 640 (CUs 10 - 640SP) Memory Speed 1500MHz (6000Mz effective) Reference Clock 1071MHz If the card has the device ID of 0x67ff then it will work OTB. https://devicehunt.com/view/type/pci/vendor/1002/device/67FF Device ID 0x699f = RX 550 512SP ✗ Device ID 0x67ff Rev FF = RX 550 640SP ✓ Device ID 0x67ff Rev CF = RX 560 ✓ Here are some models which are Baffin and WOB; Yeston RX550-4G LP D5 Gigabyte RX 550 D5 2G (rev. 2.0) Sapphire PULSE RX 550 4G G5 640SP Sapphire PULSE RX 550 2G G5 640SP Asus AREZ-PH-RX550-2G Asus PH-RX550-4G-M7 There may be others but this is what I am aware of. I ended up with the Yeston for about $99 AUS but I got it before the market went stupid. It was all I could find in Australia as Sapphire and Asus were not bringing their low end cards into the country.

Unless you bought a no name SSD off AliExpress or Wish.com it should work fine with respects to PCIe compatibility. Is the drive from Samsong? or SeeGate? 😆 The Gen3 drive might work fine just because it is clocked at half the speed so not triggering the issue. Gen4 electrical tolerances are really tight. If you put the Gen4 drive back and it starts erroring again it would be worth using the motherboard bios to lock that M.2 slot to Gen3 and see if the issues go away. Also try moving the Gen4 drive to one of the other Gen3 ports and see how it goes.

I need to rearrange a couple of Unraid servers to suit a change of requirements and I'm not sure on the best way to do it. Current setup: Server 1: Fileserver & VMs Cache Drives A & B Array Drives C, D & E Dedicated VM Drive F Server 2: Dockers Array Drives G & H Proposed setup: Server 1: VMs Array Drives A & B Dedicated VM Drive F Server 2: Fileserver & Dockers Cache Drives G & H Array Drives C, D & E Effectively what I want to do is move the array from server 1 -> 2. In doing so on server 1, I need to move the existing cache drives to become the array and on server 2, I need to move the array drives to become the cache drives. I should be able to juggle the data around from cache to array easily enough using the inbuilt options for the shares and the mover script. My concern is more around moving the main fileserver array between machines and moving the cache to array and array to cache. Anyone have any ideas on how to do this? Should I back the data up to an different drive and format/reassign the drives or is there a smarter way?

So these are hardware errors being reported by the PCIe bus. It's indicating that the data from the drive is corrupted but able to be corrected (probably by CRC or similar hardware error correction). So it's time to do some basic trouble shooting. Start by making sure the NVME pins and slot are clean. Remove and reseat the drive carefully. Consider a gentle clean with a cotton bud and isopropyl alcohol. See if the errors remain. Try moving the drive to a different M.2 slot and see if the errors follow the drive. Try a different NVME drive in the same slot. Process of elimination should allow you to work out if the M.2 slot or the NVME drive are at fault.

Again unfortunately there isn't enough here for us to go on. It's complaining about the OS.dmg.root_hash which makes me think that there is an issue with the image that was downloaded... Given that you are working with a VM, most of the normal hardware compatibility issues should not exist because it's all virtualized. Hence there is most likely something about your VM config that is incorrect and causing an issue. Start again from scratch with a fresh docker and OS download. Don't try to pass any hardware through at first, just get the system booting and then worry about USB/GPU/etc. Apple have a tendency to keep changing the product IDs of their OS images and of course new versions come out all the time. It is a lot of work to keep the Macinabox code up to date and probably more than Spacinvaderone was counting on. @ghost82 has been hard at work to fix a lot of these issues; https://github.com/SpaceinvaderOne/Macinabox/commit/2aba67bc2738d3ecc7a156a1a9b897665d6982ff https://forums.unraid.net/topic/84601-support-spaceinvaderone-macinabox/page/84/?tab=comments#comment-1010581 This was for OpenCore 0.7.0 and Mac OS 11.4 I'm not sure on the state of this work now with OpenCore 0.7.2 and Mac OS 11.5 being out. Take a look at the dortania debug guide. You may need to install the debug version of OpenCore to get more information. https://dortania.github.io/OpenCore-Install-Guide/troubleshooting/extended/kernel-issues.html#stuck-on-eb-log-exitbs-start You can also just try building your own setup from scratch. It isn't that bad if you don't mind investing some time to tinker. https://dortania.github.io/OpenCore-Install-Guide/ It's pretty rewarding.

Hi @ritty, Not sure exactly what is going on here because you haven't given us enough to work with... I can't say for sure if this is a show stopping error or just a warning. So I don't know if the error is with the VM or the OS. What is your system AMD/Intel and what video cards do you have installed? What type of GT640 do you have? - Fermi GF108/GF116 with support up to High Sierra or Kepler GK107/GK208 support up to Big Sur. Have you tried dumping the GPU ROM and loading it in your VM XML? https://forums.unraid.net/topic/84601-support-spaceinvaderone-macinabox/page/83/?tab=comments#comment-1007917 Have you tried getting the card working on Win10 VM? Are you passing both the video and audio component of the card using multifunction? Point #3 on this post; https://forums.unraid.net/topic/84601-support-spaceinvaderone-macinabox/page/82/?tab=comments#comment-1000526 Have you tried stubbing the card under system devices? Passing through Nvidia cards that are your primary GPU can be a bit tricky. Not sure if you have seen this post, along with the SpaceInvaderOne video. https://forums.unraid.net/topic/71371-resolved-primary-gpu-passthrough/ Just some ideas to get you started...

It was discussed a few pages back. See here; https://forums.unraid.net/topic/84601-support-spaceinvaderone-macinabox/page/84/?tab=comments#comment-1011949

So you need to look at the permissions to understand why you can't edit the file. Also check that the filesystem is mounted as read/write.

Actually there are 20 items in that plist file as you can see in the "value" column. You just need to click on the "> Add" to get it to expand. But I am not sure why you are editing the pcidevices.plist file. You need to add the built-in settings to your config.plist in your EFI disk/partition. If you look at my earlier post, you can see I am editing /Volumes/EFI/EFI/OC/config.plist Also I noticed that you are still using the VMX ethernet driver. This should have been updated to be the intel e1000 driver when you ran the Macinabox helper script. I believe that you need to be using the intel virtual NIC to avoid issues with iServices. You can check your virtual machines XML configuration in Unraid and make sure the NIC model is set to e1000-82545em as per my example below. You may also just be able to run the the helper script again to fix it. Just make sure you updated the FIRSTINSTALL variable to "no". Spacinvader One talks about this here; https://www.youtube.com/watch?v=7OunFLG84Qs&t=840s <interface type='bridge'> <mac address='60:03:08:aa:bb:cc'/> <source bridge='br0'/> <target dev='vnet0'/> <model type='e1000-82545em'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface>

Actually I’m using ProperTree.

Actually it does talk about how to fix the en0 not having a check mark, but I agree that it's not well written. https://dortania.github.io/OpenCore-Post-Install/universal/iservices.html#fixing-en0 "Here under Network Interfaces (network card icon), look for en0 under BSD and check whether the device has a check mark under Builtin. If there is a check mark, skip to Fixing ROM section otherwise continue reading." After running the two commands to delete the .plist files it actually gives instructions about what to do if you don't have an en0 interface so you can ignore the section about NullEthernet.kext and ssdt-rmne.aml since that isn't your issue. Jump to "Now head under the PCI tab of Hackintool and export your PCI DeviceProperties, this will create a pcidevices.plist on your desktop..." You just need to add the en0 interface PCI root to your config.plist to tell the OS that it is built-in. In my case I had to define the built-in option for the WiFI, Bluetooth and the NVMe SSD.

Everything you need to fix it is here; https://dortania.github.io/OpenCore-Post-Install/universal/iservices.html#using-gensmbios 1) Set SystemProductName to iMacPro1,1 unless you really know what you are doing. 2) Generate a unique serial number, UUID and Board number using GenSMBIOS. 3) Check the serial number with the Apple Tool. It is fine to use an invalid serial number if your Apple ID is in good standing. I've been doing this for years on multiple VMs and never had an issue. 4) Set the MAC address of your VMs virtual network card to an Apple Inc address. 5) Set the ROM address to be the same. 6) Make sure your ethernet interface is "en0" and marked as internal. Then you should be good to go.