ms4sman

OK this is a weirdly specific issue. Basically, under certain conditions (which I will outline in more detail below) I'm having issues with two of my containers crashing on startup. The two containers are Ghost (from cheesemarathon's repo) and Agent-DVR (from Froodle's repo, who does update the templates it seems, but is otherwise not active on the forums) Ghost seems to be a bit more inconsistent about when it has issues but Agent-DVR is pretty consistent. - Both of them start fine if I stop the container and start it again myself. - I use the current AppData Backup plugin, and depending on the order of apps being backed up, Agent-DVR has issues. It has no dependencies that I'm aware of. If it is FIRST on the list in the plugin, it will startup just fine. But from my testing so far, if it is anywhere else in the order, it will startup and then quickly crash. Sometimes if I try to start it again myself it will also crash the first time or two, but then eventually starts and works. - Ghost (seemingly) doesn't have problems with the backup plugin. At least not consistently. - If I disable the Docker system entirely in unRAID, and then re-enable it, all apps including these two seem to startup just fine and it's worth noting, don't take very long to startup all apps. - After a reboot of the entire server, all my dockers take significantly longer to start up, and I don't know why this is, but also, both Agent-DVR and Ghost seem to have issues starting up after a reboot. Again, they start up in the proper order, but then quickly crash. - I'm aware of Ghost's dependency on my MariaDB container, and I know that docker starts up and is running well before Ghost in the order. I don't think Agent-DVR relies on any other containers. I don't understand what's causing this. There are some errors in the logs of each container, but I'm not sure if they are related to the crashing or not. The only way I've been able to retrieve them is AFTER successfully starting the app back up manually, so I don't know if the errors are from before, or from the successful startup, and are unrelated. I'll include them below though. If anyone can help me troubleshoot this, I'd sure appreciate it! I don't understand why the containers work under some conditions and not under others. Here's the errors from Agent-DVR. They aren't very descriptive but seem like MAYBE they are related to the container stopping. text error warn system array login at Interop.Kernel32.SetEvent(SafeWaitHandle ) at System.Threading.EventWaitHandle.Set() at CoreLogic.Setup.<>c__DisplayClass2_0.<SetPermissions>b__2(Object sender, EventArgs e) at System.Diagnostics.Process.OnExited() at System.Diagnostics.Process.RaiseOnExited() at System.Diagnostics.Process.CompletionCallback(Object , Boolean ) at System.Threading._ThreadPoolWaitOrTimerCallback.WaitOrTimerCallback_Context(Object , Boolean ) at System.Threading._ThreadPoolWaitOrTimerCallback.WaitOrTimerCallback_Context_f(Object ) at System.Threading.ExecutionContext.RunInternal(ExecutionContext , ContextCallback , Object ) --- End of stack trace from previous location --- at System.Threading.ExecutionContext.RunInternal(ExecutionContext , ContextCallback , Object ) at System.Threading.ExecutionContext.Run(ExecutionContext , ContextCallback , Object ) at System.Threading._ThreadPoolWaitOrTimerCallback.PerformWaitOrTimerCallback(_ThreadPoolWaitOrTimerCallback , Boolean ) at System.Threading.RegisteredWaitHandle.PerformCallback(Boolean ) at System.Threading.PortableThreadPool.CompleteWait(RegisteredWaitHandle , Boolean ) at System.Threading.CompleteWaitThreadPoolWorkItem.CompleteWait() at System.Threading.CompleteWaitThreadPoolWorkItem.System.Threading.IThreadPoolWorkItem.Execute() at System.Threading.ThreadPoolWorkQueue.Dispatch() at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart() at System.Threading.Thread.StartCallback() TURN: Welcome user TURN: Welcome user TURN: Welcome user TURN: Welcome user TURN: Welcome user TURN: Welcome user TURN: Welcome user TURN: Welcome user TURN: Welcome user TURN: Welcome user TURN: Welcome user TURN: Welcome user TURN: Welcome user TURN: Welcome user TURN: Welcome user TURN: Welcome user TURN: Welcome user TURN: Welcome user TURN: Welcome user TURN: Welcome user TURN: Welcome user TURN: Welcome user Unhandled exception. System.ObjectDisposedException: Safe handle has been closed. Object name: 'SafeHandle'. at System.Runtime.InteropServices.SafeHandle.DangerousAddRef(Boolean& ) at System.StubHelpers.StubHelpers.SafeHandleAddRef(SafeHandle , Boolean& ) at Interop.Kernel32.SetEvent(SafeWaitHandle ) at System.Threading.EventWaitHandle.Set() at CoreLogic.Setup.<>c__DisplayClass2_0.<SetPermissions>b__2(Object sender, EventArgs e) at System.Diagnostics.Process.OnExited() at System.Diagnostics.Process.RaiseOnExited() at System.Diagnostics.Process.CompletionCallback(Object , Boolean ) at System.Threading._ThreadPoolWaitOrTimerCallback.WaitOrTimerCallback_Context(Object , Boolean ) at System.Threading._ThreadPoolWaitOrTimerCallback.WaitOrTimerCallback_Context_f(Object ) at System.Threading.ExecutionContext.RunInternal(ExecutionContext , ContextCallback , Object ) --- End of stack trace from previous location --- at System.Threading.ExecutionContext.RunInternal(ExecutionContext , ContextCallback , Object ) at System.Threading.ExecutionContext.Run(ExecutionContext , ContextCallback , Object ) at System.Threading._ThreadPoolWaitOrTimerCallback.PerformWaitOrTimerCallback(_ThreadPoolWaitOrTimerCallback , Boolean ) at System.Threading.RegisteredWaitHandle.PerformCallback(Boolean ) at System.Threading.PortableThreadPool.CompleteWait(RegisteredWaitHandle , Boolean ) at System.Threading.CompleteWaitThreadPoolWorkItem.CompleteWait() at System.Threading.CompleteWaitThreadPoolWorkItem.System.Threading.IThreadPoolWorkItem.Execute() at System.Threading.ThreadPoolWorkQueue.Dispatch() at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart() at System.Threading.Thread.StartCallback() Unhandled exception. System.ObjectDisposedException: Safe handle has been closed. Object name: 'SafeHandle'. at System.Runtime.InteropServices.SafeHandle.DangerousAddRef(Boolean& ) at System.StubHelpers.StubHelpers.SafeHandleAddRef(SafeHandle , Boolean& ) at Interop.Kernel32.SetEvent(SafeWaitHandle ) at System.Threading.EventWaitHandle.Set() at CoreLogic.Setup.<>c__DisplayClass2_0.<SetPermissions>b__2(Object sender, EventArgs e) at System.Diagnostics.Process.OnExited() at System.Diagnostics.Process.RaiseOnExited() at System.Diagnostics.Process.CompletionCallback(Object , Boolean ) at System.Threading._ThreadPoolWaitOrTimerCallback.WaitOrTimerCallback_Context(Object , Boolean ) at System.Threading._ThreadPoolWaitOrTimerCallback.WaitOrTimerCallback_Context_f(Object ) at System.Threading.ExecutionContext.RunInternal(ExecutionContext , ContextCallback , Object ) --- End of stack trace from previous location --- at System.Threading.ExecutionContext.RunInternal(ExecutionContext , ContextCallback , Object ) at System.Threading.ExecutionContext.Run(ExecutionContext , ContextCallback , Object ) at System.Threading._ThreadPoolWaitOrTimerCallback.PerformWaitOrTimerCallback(_ThreadPoolWaitOrTimerCallback , Boolean ) at System.Threading.RegisteredWaitHandle.PerformCallback(Boolean ) at System.Threading.PortableThreadPool.CompleteWait(RegisteredWaitHandle , Boolean ) at System.Threading.CompleteWaitThreadPoolWorkItem.CompleteWait() at System.Threading.CompleteWaitThreadPoolWorkItem.System.Threading.IThreadPoolWorkItem.Execute() at System.Threading.ThreadPoolWorkQueue.Dispatch() at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart() at System.Threading.Thread.StartCallback() And here's what I can capture from Ghost. It doesn't really seem related. Just seems like my template is likely out of date and using some deprecated stuff. text error warn system array login details: Usage of <code>{{@labs.members}}</code> is no longer supported and should be replaced with <code>{{@site.members_enabled}}</code><br>Find more information about the <code>@site</code> property <a href="https://ghost.org/docs/themes/helpers/site/" target=_blank>here</a>. regex: helper: {{@labs.members}} failures: - ref: default.hbs message: Please remove or replace {{@labs.members}} from this template - ref: partials/site-nav.hbs message: Please remove or replace {{@labs.members}} from this template - ref: post.hbs message: Please remove or replace {{@labs.members}} from this template code: GS001-DEPR-LABS-MEMBERS - fatal: false level: error rule: Replace <code>{{@site.lang}}</code> with <code>{{@site.locale}}</code> details: The usage of <code>{{@site.lang}}</code> is no longer supported and shoud be replaced with <code>{{@site.locale}}</code>.<br>Find more information about the <code>@site.locale</code> property <a href="https://ghost.org/docs/themes/helpers/site/" target=_blank>here</a>. regex: helper: {{@site.lang}} failures: - ref: default.hbs message: Please remove or replace {{@site.lang}} from this template code: GS001-DEPR-SITE-LANG - fatal: false level: error rule: Not all page features are being used details: <b>This error only applies to pages created with the Beta editor.</b> Some page features used by Ghost via the <code>{{@page}}</code> global are not implemented in this theme.&nbsp;Find more information about the <code>{{@page}}</code> global <a href="https://ghost.org/docs/themes/helpers/page/" target=_blank>here</a>. failures: - ref: page.hbs message: @page.show_title_and_feature_image is not used rule: GS110-NO-MISSING-PAGE-BUILDER-USAGE code: GS110-NO-MISSING-PAGE-BUILDER-USAGE warnings: (empty array) ---------------------------------------- ThemeValidationError: The currently active theme "casper-custom" has errors, but will still work. at Object.getThemeValidationError (/var/lib/ghost/versions/5.76.0/core/server/services/themes/validate.js:142:12) at module.exports.loadAndActivate (/var/lib/ghost/versions/5.76.0/core/server/services/themes/activate.js:30:35) at async initServicesForFrontend (/var/lib/ghost/versions/5.76.0/core/boot.js:192:5) at async bootGhost (/var/lib/ghost/versions/5.76.0/core/boot.js:513:31)

I will check on the timeout and try increasing it. Any suggestions regarding when it tries to restart the container and detects it is already started, but then in the morning it is clearly not started? Seems like for some reason it's being told the container is running when it isn't? I couldn't find anything about this in my searching online. Only things I saw about "already running" were in regards to the old version of the plugin and had to do with the auto-update.

Hi there. I used to use the old AppData Backup and Restore way back, and got rid of it a while ago, and then just recently started using this new AppData Backup plugin again. I'm trying to use it in combination with Duplicacy in the way I understand to be correct. Basically AppData Backup runs first, and backs up my AppData to another share called Backups. Then Duplicacy backs up that share later to Backblaze B2 storage. I have AppData Backup configured to stop and backup each container and start it again one at a time. I'm having some issues with the starting and stopping of containers that I never seemed to have with the old plugin. Looking in the logs, I see that many of the containers are having to be force stopped with 'docker stop' due to them not seeming to respond to the regular stop. I'm not sure if this just means they are taking too long to stop the normal way so the plugin gets tired of waiting or what. But I notice that it seems like many of the containers that have trouble stopping, then when its time to start, have trouble starting and end up with a message about already being started. This backup happens while I'm asleep so I dont know for sure if they are or not. All I know is that when I wake up in the morning, I usually have down notifications from UptimeKuma and sure enough, a handful of containers are stopped. But according to the logs, those containers were already started when it went to start them. I don't have AppData Backup configured to update any containers so that shouldn't be it. It's usually same few containers every time. Always Ghost and Agent DVR, and a couple others. This morning Glances was also a problem child though it hasn't been in the past. Oddly, not ALL the containers in the logs that had issues are not started Jellyfin for example had issues stopping AND starting. But it was running just fine this morning. But all the ones that are not started ARE ones that were logged as having issues. I'll include the logs below. If anyone can help out here, I'd sure appreciate it. I don't like having my containers down for hours until I wake up and then having to manually start them first thing in the morning. Debug log ID is 3ec2e7eb-9fab-42bc-8198-712b82790c04 Thanks in advance for any help! ab.log

Well my question may be answered...I switched to SATA to see if there was any performance difference and now I can't switch back to VirtIO. I'm not sure how I had it working before, but I definitely had virtio selected and it was definitely working...but now it doesn't recognize my SSD. I have the virtio driver installed on Windows too, because like I said, it worked before... Oh well, guess SATA is my answer...

I'm passing through an SSD from Unassigned Devices to my VM using the by-id technique using the ID starting with "ata-". Should I use SATA or VirtIO for this? I have the virtio drivers installed in Windows and I've been using VirtIO until now, but I'm not sure if that is correct or not. Does it matter? When I use VirtIO drivers, it shows up as an HDD in task manager, and as a "thin provisioned device" under the optimization window. If I use SATA it shows as an HDD in both places. I find lots of info about this for vdisks but I haven't been able to find a straight answer on this for passthrough disks. Thank you!

Hi all. I recently upgraded my unRAID server from a Ryzen 1700 to an 5900X. I kept my same motherboard for reference, a Gigabyte X370 board, but upgraded the BIOS to the latest to get support for the 5900X. I've had problems ever since upgrading with the CPU temp being crazy high with any load at all (say 10-20%). If all my dockers and VMs are stopped and CPU usage is a couple of percent, CPU temps are OK. 40-50s. About what I'd usually get on my old CPU with all my stuff running. But again, this is with everything stopped. But if everything is running and CPU usage is around 20-30%, my temps go wild and are in the 70's or 80's. Under a heavy load they barely go any higher which is strange too. I finally tracked this to the AMD Performance Boost setting in Tips and Tweaks. I've had this on for a long time, including with my old CPU and had no issues. But turning it off, my temps go back to where I'd expect. 40-50's, even with everything running. Turning it back on, temps shoot back up again. I'm not super familiar with this feature, is this how it's meant to work? I know this isn't really unRAID related, it's a CPU feature but maybe someone knowledgeable here can explain. Should this feature really cause a 30 degree delta whenever there's even a light 10-20% load on the CPU? This seems kind of reckless... Thanks in advance to anyone who can help!

Excellent, glad to hear that the issue is known and being worked on. I'll look forward to the 1.5.1 update and the following update to the container. In the meantime, I'm glad to have found the temporary solution of using no password, thanks to the others here with the same problem.

Hey @SpaceInvaderOne, I know this is a very old thread, but if you're still open to helping, I could use some! I downloaded your disk image for Win 98 and followed the instructions, but every time I try to boot it up, it just tells me that the disk isn't bootable. Any ideas? Does this still work for you on newer unRAID versions? Thanks!

Something seems to have corrupted the database on my Guacamole install. It was fine yesterday, but I think it may have been updated overnight by the Auto Update plugin, and this morning I just get the generic error page. Removing the AppData for it and letting it all be recreated gets me a working Guac install, but if I place the old database files back in place, it stops working again. There doesn't appear to be anything strange in the logs when I view them from right-clicking the container and choosing Logs. Any ideas what to do here? Can I at least back up my connection settings and transfer them to a new installation? I'd really rather not have to re-create ALL my connections. Thanks! EDIT: I was able to resolve this. I'm still not really sure what happened, but ultimately I did a sqldump to a file, deleted all the databases and started the container to remake them, then imported the dump back in and now things seem back to normal...

RESOLVED! Thanks @itimpi, your link helped! So basically, I just needed to be paying attention to the Backup status log while it ran. I didn't realize that if you don't have dockers set to Auto-Start, it seems to just restart the ones that were running in alphabetical order. The Auto-Start order is only honored if it's actually enabled. In my case, I don't normally have anything auto-start with the server, so I didn't realize this. I also figured out how to use the "wait" command, although it's not necessary in this case. Now that I turned on Auto-Start, MariaDB is starting and fully up before Ghost is started anyway, and all seems well Thanks!

Never mind, ignore me, I'm a complete idiot LOL. I didn't have Auto-Start enabled on the Dockers when I was looking for this setting! I'll see if this resolves my issues.

Interesting. Thanks for the link, that is helpful! I don't seem to have the "wait" option though, even when I switch to Advanced View. Would my theme somehow be hiding that field? I'll do some digging on my end.

Doing some further research, I've found several further mentions of the CA Docker Autostart Manager plugin, which from my reading isn't around anymore as of server 6.6 or so. I found mentions of a new "wait" option that could be used to delay further apps from starting till the first one gets a chance to load up. This might be useful, but I have found very little information on how to actually use it, and haven't been able to make it work yet. My other concern is this: is this "wait" honored by the CA Backup plugin when it is restarting the stopped dockers, or does it only actually get used when first enabling the Docker service after a reboot for example? Thanks!

Hi all, This is something I'm guessing is doable, but I didn't have luck trying to find anything about it, but I also wasn't sure how to word my search so there could still definitely be something out there I missed. Basically, I have a Ghost blog container running, and it relies on my MariaDB container as well. In fact, if Ghost starts up and can't contact MariaDB, it shuts back down. This causes some inconveniences with the Community Applications Backup because it stops all containers, and then starts them again when finished. This is great, and I understand the necessity, but unfortunately it means that in this specific case, Ghost comes up before MariaDB and then goes back down when it can't make contact, so most mornings, my Ghost docker is stopped when I get up. I get that this is a super specific use case so I'm not expecting the CA Backup plugin to change, what I'm looking for is this: is there a way I can configure Ghost so that when it starts up, it first starts MariaDB, then itself after? Perhaps using the Extra Parameters field or something... Thanks!

I think I may have figured it out. It seems that if when Ghost starts up, it can't reach it's SQL server, it just goes back down after a couple minutes of trying. So I have daily backups happening that shut down all dockers, then restart them after. I'm betting that MariaDB isn't coming back up quick enough sometimes, and Ghost just gives up trying and goes back down. All the crashes seem to be at 7 AM sharp, in the logs, which with the offset calculated, is 5 hours ahead, so 2 AM which is when my backup is scheduled. I'm going to try a few things to get around this.

It's certainly not impossible that auto-update is related, but I'm pretty sure it's gone down even when I turned Ghost off in the auto-updater. It also has definitely crashed lots of times when there was no update. It happened again today though, and looking at the log, there's loads of red errors about losing connection to the database, or other database related stuff. I'm using MariaDB but that container hasn't been going down, so I'm wondering why it's losing its connection to it off and on. I'll do some more digging...

Hey, so I've got Ghost installed and it is working well for me, but every few days or so, I notice the Docker has stopped (crashed I assume). I don't notice anything odd in the logs at the time of the shutdown last I looked, although I don't have one right now (I'll grab one as soon as it happens again). Initially I thought it was happening because I had a script in User Scripts that killed all Node processes, which was definitely nuking Ghost, but I have removed that so that's not it anymore, but I'm not sure what else would be causing it to seemingly crash randomly. It also seems to sometimes not come back online after an Auto-Update from the autoupdate community apps plugin, but other times it does. Is this anything familiar to anyone, or just me? I'll keep looking for processes that might be killing Node processes or something. Thanks!

I have just tried it out in a Fedora VM I had set up, and it works fine there. So it seems to just be Manjaro. I'm going to try it again in another Manjaro VM without any other PCI devices passed through and a few other combos just to see if it makes any difference. EDIT: Could it be to do with SeaBIOS or anything? I ended up having to use SeaBIOS for Manjaro, it didn't want to work with me on OVMF.

Sorry for the late reply, I haven't had a chance to try another VM, I will do that now and get back to you. Thanks!

This may or may not be the correct place to ask about this, but I figured it was worth a shot to see if anyone could help me out. I've got a Windows 10 VM with a GTX 1080 passed through to it. I've got a Manjaro VM with a GTX 650TI passed through to it. I'm trying to use Steam In-Home Streaming to play games on Windows 10, via Manjaro. however, the streaming diagnostics constantly tell me I have slow networking and the ping and latency in the game stream is unplayable. However, I can stream the same game (Portal 2 for testing) from my work laptop, via VPN which isn't even on the same network as me, from the same Manjaro VM as client, and get excellent performance with it, no warnings from Steam and everything is peachy. So it's my Windows 10 VM I assume, and you probably do too, but I have a steam link, and I can stream Portal 2 to it, from Windows 10 with excellent performance as well, no issues whatsoever. So all I can think of is something weird going on in the networking between the two VMs that I'm not thinking of, and hopefully someone here can. But even then, the ping from Manjaro to the Windows 10 VM in the terminal is <1ms. But when streaming a game, it skyrockets. Anyone have any clue what I am missing here? Thanks in advance! Windows 10 XML <?xml version='1.0' encoding='UTF-8'?> <domain type='kvm' id='16'> <name>Windows 10</name> <uuid>afb22e68-6160-c234-7de8-a72f6d0501f6</uuid> <metadata> <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/> </metadata> <memory unit='KiB'>16777216</memory> <currentMemory unit='KiB'>16777216</currentMemory> <memoryBacking> <nosharepages/> </memoryBacking> <vcpu placement='static'>8</vcpu> <cputune> <vcpupin vcpu='0' cpuset='8'/> <vcpupin vcpu='1' cpuset='9'/> <vcpupin vcpu='2' cpuset='10'/> <vcpupin vcpu='3' cpuset='11'/> <vcpupin vcpu='4' cpuset='12'/> <vcpupin vcpu='5' cpuset='13'/> <vcpupin vcpu='6' cpuset='14'/> <vcpupin vcpu='7' cpuset='15'/> </cputune> <resource> <partition>/machine</partition> </resource> <os> <type arch='x86_64' machine='pc-i440fx-2.9'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/afb22e68-6160-c234-7de8-a72f6d0501f6_VARS-pure-efi.fd</nvram> </os> <features> <acpi/> <apic/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> <vendor_id state='on' value='none'/> </hyperv> </features> <cpu mode='host-passthrough' check='none'> <topology sockets='1' cores='8' threads='1'/> </cpu> <clock offset='localtime'> <timer name='hypervclock' present='yes'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source dev='/dev/disk/by-id/ata-MKNSSDRE512GB_MK170421100356BF5'/> <backingStore/> <target dev='hdc' bus='virtio'/> <boot order='1'/> <alias name='virtio-disk2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> <controller type='usb' index='0' model='nec-xhci' ports='15'> <alias name='usb'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </controller> <controller type='virtio-serial' index='0'> <alias name='virtio-serial0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </controller> <controller type='pci' index='0' model='pci-root'> <alias name='pci.0'/> </controller> <interface type='bridge'> <mac address='52:54:00:76:00:5c'/> <source bridge='br0'/> <target dev='vnet0'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <serial type='pty'> <source path='/dev/pts/1'/> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> <alias name='serial0'/> </serial> <console type='pty' tty='/dev/pts/1'> <source path='/dev/pts/1'/> <target type='serial' port='0'/> <alias name='serial0'/> </console> <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-16-Windows 10/org.qemu.guest_agent.0'/> <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/> <alias name='channel0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='tablet' bus='usb'> <alias name='input0'/> <address type='usb' bus='0' port='4'/> </input> <input type='mouse' bus='ps2'> <alias name='input1'/> </input> <input type='keyboard' bus='ps2'> <alias name='input2'/> </input> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x0d' slot='0x00' function='0x0'/> </source> <alias name='hostdev0'/> <rom file='/mnt/user/isos/BIOS Dumps/1080.rom'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x0d' slot='0x00' function='0x1'/> </source> <alias name='hostdev1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </hostdev> <memballoon model='none'/> </devices> <seclabel type='dynamic' model='dac' relabel='yes'> <label>+0:+100</label> <imagelabel>+0:+100</imagelabel> </seclabel> </domain> Manjaro XML <?xml version='1.0' encoding='UTF-8'?> <domain type='kvm' id='27'> <name>Manjaro</name> <uuid>f26c0162-e80e-e8e0-ae18-7fe845110950</uuid> <metadata> <vmtemplate xmlns="unraid" name="Arch" icon="manjaro.png" os="arch"/> </metadata> <memory unit='KiB'>16777216</memory> <currentMemory unit='KiB'>16777216</currentMemory> <memoryBacking> <nosharepages/> </memoryBacking> <vcpu placement='static'>4</vcpu> <cputune> <vcpupin vcpu='0' cpuset='4'/> <vcpupin vcpu='1' cpuset='5'/> <vcpupin vcpu='2' cpuset='6'/> <vcpupin vcpu='3' cpuset='7'/> </cputune> <resource> <partition>/machine</partition> </resource> <os> <type arch='x86_64' machine='pc-q35-3.1'>hvm</type> </os> <features> <acpi/> <apic/> </features> <cpu mode='host-passthrough' check='none'> <topology sockets='1' cores='4' threads='1'/> </cpu> <clock offset='utc'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/domains/Manjaro/vdisk1.img'/> <backingStore/> <target dev='hdc' bus='sata'/> <boot order='1'/> <alias name='sata0-0-2'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> <controller type='usb' index='0' model='ich9-ehci1'> <alias name='usb'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <alias name='usb'/> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0' multifunction='on'/> </controller> <controller type='usb' index='0' model='ich9-uhci2'> <alias name='usb'/> <master startport='2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x1' multifunction='on'/> </controller> <controller type='usb' index='0' model='ich9-uhci3'> <alias name='usb'/> <master startport='4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2'/> </controller> <controller type='pci' index='3' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='3' port='0xa'/> <alias name='pci.3'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> <controller type='pci' index='4' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='4' port='0x13'/> <alias name='pci.4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/> </controller> <controller type='pci' index='5' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='5' port='0x14'/> <alias name='pci.5'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/> </controller> <controller type='virtio-serial' index='0'> <alias name='virtio-serial0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </controller> <controller type='sata' index='0'> <alias name='ide'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> <controller type='pci' index='0' model='pcie-root'> <alias name='pcie.0'/> </controller> <controller type='pci' index='1' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='1' port='0x8'/> <alias name='pci.1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0' multifunction='on'/> </controller> <controller type='pci' index='2' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='2' port='0x9'/> <alias name='pci.2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <interface type='bridge'> <mac address='52:54:00:8b:74:7d'/> <source bridge='br0'/> <target dev='vnet1'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> <serial type='pty'> <source path='/dev/pts/2'/> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> <alias name='serial0'/> </serial> <console type='pty' tty='/dev/pts/2'> <source path='/dev/pts/2'/> <target type='serial' port='0'/> <alias name='serial0'/> </console> <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-27-Manjaro/org.qemu.guest_agent.0'/> <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/> <alias name='channel0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='tablet' bus='usb'> <alias name='input0'/> <address type='usb' bus='0' port='1'/> </input> <input type='mouse' bus='ps2'> <alias name='input1'/> </input> <input type='keyboard' bus='ps2'> <alias name='input2'/> </input> <hostdev mode='subsystem' type='pci' managed='yes' xvga='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x0e' slot='0x00' function='0x0'/> </source> <alias name='hostdev0'/> <rom file='/mnt/user/isos/BIOS Dumps/650TI.rom'/> <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x0e' slot='0x00' function='0x1'/> </source> <alias name='hostdev1'/> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x07' slot='0x00' function='0x0'/> </source> <alias name='hostdev2'/> <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x046d'/> <product id='0xc531'/> <address bus='7' device='7'/> </source> <alias name='hostdev3'/> <address type='usb' bus='0' port='2'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x08ff'/> <product id='0x0009'/> <address bus='7' device='6'/> </source> <alias name='hostdev4'/> <address type='usb' bus='0' port='3'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x0c45'/> <product id='0x7605'/> <address bus='7' device='4'/> </source> <alias name='hostdev5'/> <address type='usb' bus='0' port='4'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x0c76'/> <product id='0x161f'/> <address bus='3' device='4'/> </source> <alias name='hostdev6'/> <address type='usb' bus='0' port='5'/> </hostdev> <memballoon model='none'/> </devices> <seclabel type='dynamic' model='dac' relabel='yes'> <label>+0:+100</label> <imagelabel>+0:+100</imagelabel> </seclabel> </domain> If any other information is needed, please let me know and I'll be happy to provide it!

Hi all, A while back I bought a Renesas uPD720201 USB 3.0 PCI card for my Windows 10 VM so I could pass it through for some hotpluggable USB ports. It worked great, but more recently I'm starting to try to switch entirely over to Manjaro for everything but gaming, and I'd like to give those hotpluggable ports to the Manjaro VM instead. I added the card to the XML according to this post, just like I did to add it to Windows, and it seems to attach to the machine on startup, because all devices plugged into it become unavailable for use elsewhere, but Manjaro doesn't seem to know what to do with it. It doesn't show up in lspci and devices plugged into it don't show up in lsusb either. It is in it's own IOMMU group. I think I'm probably missing something obvious but I can't think what. I'd appreciate any help! Full server specs here Manjaro XML <?xml version='1.0' encoding='UTF-8'?> <domain type='kvm' id='27'> <name>Manjaro</name> <uuid>f26c0162-e80e-e8e0-ae18-7fe845110950</uuid> <metadata> <vmtemplate xmlns="unraid" name="Arch" icon="manjaro.png" os="arch"/> </metadata> <memory unit='KiB'>16777216</memory> <currentMemory unit='KiB'>16777216</currentMemory> <memoryBacking> <nosharepages/> </memoryBacking> <vcpu placement='static'>4</vcpu> <cputune> <vcpupin vcpu='0' cpuset='4'/> <vcpupin vcpu='1' cpuset='5'/> <vcpupin vcpu='2' cpuset='6'/> <vcpupin vcpu='3' cpuset='7'/> </cputune> <resource> <partition>/machine</partition> </resource> <os> <type arch='x86_64' machine='pc-q35-3.1'>hvm</type> </os> <features> <acpi/> <apic/> </features> <cpu mode='host-passthrough' check='none'> <topology sockets='1' cores='4' threads='1'/> </cpu> <clock offset='utc'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/domains/Manjaro/vdisk1.img'/> <backingStore/> <target dev='hdc' bus='sata'/> <boot order='1'/> <alias name='sata0-0-2'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> <controller type='usb' index='0' model='ich9-ehci1'> <alias name='usb'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <alias name='usb'/> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0' multifunction='on'/> </controller> <controller type='usb' index='0' model='ich9-uhci2'> <alias name='usb'/> <master startport='2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x1' multifunction='on'/> </controller> <controller type='usb' index='0' model='ich9-uhci3'> <alias name='usb'/> <master startport='4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2'/> </controller> <controller type='pci' index='3' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='3' port='0xa'/> <alias name='pci.3'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> <controller type='pci' index='4' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='4' port='0x13'/> <alias name='pci.4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/> </controller> <controller type='pci' index='5' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='5' port='0x14'/> <alias name='pci.5'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/> </controller> <controller type='virtio-serial' index='0'> <alias name='virtio-serial0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </controller> <controller type='sata' index='0'> <alias name='ide'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> <controller type='pci' index='0' model='pcie-root'> <alias name='pcie.0'/> </controller> <controller type='pci' index='1' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='1' port='0x8'/> <alias name='pci.1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0' multifunction='on'/> </controller> <controller type='pci' index='2' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='2' port='0x9'/> <alias name='pci.2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <interface type='bridge'> <mac address='52:54:00:8b:74:7d'/> <source bridge='br0'/> <target dev='vnet1'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> <serial type='pty'> <source path='/dev/pts/2'/> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> <alias name='serial0'/> </serial> <console type='pty' tty='/dev/pts/2'> <source path='/dev/pts/2'/> <target type='serial' port='0'/> <alias name='serial0'/> </console> <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-27-Manjaro/org.qemu.guest_agent.0'/> <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/> <alias name='channel0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='tablet' bus='usb'> <alias name='input0'/> <address type='usb' bus='0' port='1'/> </input> <input type='mouse' bus='ps2'> <alias name='input1'/> </input> <input type='keyboard' bus='ps2'> <alias name='input2'/> </input> <hostdev mode='subsystem' type='pci' managed='yes' xvga='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x0e' slot='0x00' function='0x0'/> </source> <alias name='hostdev0'/> <rom file='/mnt/user/isos/BIOS Dumps/650TI.rom'/> <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x0e' slot='0x00' function='0x1'/> </source> <alias name='hostdev1'/> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x07' slot='0x00' function='0x0'/> </source> <alias name='hostdev2'/> <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x046d'/> <product id='0xc531'/> <address bus='7' device='7'/> </source> <alias name='hostdev3'/> <address type='usb' bus='0' port='2'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x08ff'/> <product id='0x0009'/> <address bus='7' device='6'/> </source> <alias name='hostdev4'/> <address type='usb' bus='0' port='3'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x0c45'/> <product id='0x7605'/> <address bus='7' device='4'/> </source> <alias name='hostdev5'/> <address type='usb' bus='0' port='4'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x0c76'/> <product id='0x161f'/> <address bus='3' device='4'/> </source> <alias name='hostdev6'/> <address type='usb' bus='0' port='5'/> </hostdev> <memballoon model='none'/> </devices> <seclabel type='dynamic' model='dac' relabel='yes'> <label>+0:+100</label> <imagelabel>+0:+100</imagelabel> </seclabel> </domain> Let me know if any more information is needed, I am happy to provide it!

That fixed it! Thanks for the quick reply and fix! This is pretty nice, I think I might stick with it!

@Squid this plugin is great, I'm trying it out to see if I can eliminate my Organizr docker in favor of this and so far it's working very well. My only issue is that the positioning doesn't seem to be working. Using the information you provided in the OP, I assigned tab numbers for each that should have put them in my custom order, all after the default unRAID tabs. But they still seem to just all be alphabetical and nothing I do seems to change that. Any idea what might be causing this? Thanks!

OK, so I think I'm ready to call this. I've had the flash drive plugged into the back port for a while now and it hasn't crashed once, or whatever you'd call what was happening. The reason it took so long to establish was I was trying front ports too, which also use the onboard USB2 headers to see if they were better and they weren't, plus I kept rebooting the server manually for other reasons. But I think I'm ready to call it stable in a back port and I guess I'll just have to stick with it. Any reason why using any port connected to the onboard USB 2.0 headers seems to cause this issue for me?

I haven't forgotten this thread, I'm just doing tests in various ports to see how stable it is.