alexciurea

Hi @AinzOolGown In my case I faced a problem with my gitlab-ce docker installation during updates because: 1) no autoapdates, and 2) I did not follow the update path recommended by gitlab. When I manually updated, it jumped from a very old version to latest. The container was not starting because db was failing; I think the db upgrade scrips failed. So I manually updated step by step, using specifically the respective tags in the docker, based on this info below: https://docs.gitlab.com/ee/update/#upgrade-paths This resolved the issue. Maybe this is already common knowledge for many, but I hope it helps someone failing like me... -a

facing a similar issue. my linux vm's with passthrough GPU fail to start, getting stuck at tianocore screen. but windows VM's seemed ok, no issue encountered. rolled-back and problem solved.

one way to solve this annoyance is to use the Queue Manager; use F2 - Queue, when performing long duration actions.

thanks for sharing this, it solved my problem when moving vm's from one unraid box to another.

see this one:

hello seems that fix common problems plugin report the gitlab-ce ports as non-standard. Getting in FCP errors like: Docker Application GitLab-CE, Container Port 22 not found or changed on installed application Docker Application GitLab-CE, Container Port 80 not found or changed on installed application Docker Application GitLab-CE, Container Port 443 not found or changed on installed application somebody else reporting this in the GL-CE docker support thread. i guess we can ignore, but probably the plugin reporting such error should be corrected?

same issue here. I don't remember if i changed these to other values. tried to change to 22, 80 and 443, but container does not start anymore. tried to remove the container and reinstalled, but same values are used by default (9022, 9080, 9443). will post also in the fix common problems plugin

+ 1 for the compose / kubernetes in unraid out-of-box (and also using multiple unraid nodes)

looks like solved, i did few things - hope it helps somebody: 1) i manually checked for updates in the Plugins page, then installed the updates. Some hickups along the way: a) the check for updates was very slow b) the process stuck 2-3 times, had to navigate away, then back to Plugins page, then restarting the process of check for updates. c) one pluggin failed to update on first try, then had to restart the update and all was ok... 2) Also, i disabled the autostart of the VM, then started the VM from CLI. Then re-enabled the autostart for that VM and since then, it starts properly and quickly, couple of seconds after unraid startup.

i always thought that it's not possible to passthrough integrated wireles cards...

hi, i need your help for an issue that is getting bigger and bigger... my setup: x99-m ws, 5820k, 32gb ram 1 disk in array, 1 parity 1 cache ssd (crucial mx300) 1 passthrough ssd 850 EVO (daily driver with windows 10 with 1060 passthrough with rom dump) 1 unassigned ssd (750 EVO) I noticed towards the end of the year that upon a fresh start of the unraid box, the windows 10 VM (autostart) would take more time to initialize. The unraid loads, reaching the tower login prompt, but waiting more and more (sometimes up to 2-3 minutes) to get the win 10 vm to autostart... now, after the new year, the VM does not start anymore under normal conditions. it gets stuck at tower login prompt... keyboard seems unresponsive, i cannot even type a username/password (i remember i could do that in the past if i was quick enough)... Current workaround is to select the gui mode from boot menu of unraid, and then at certain point some 3-5 minutes i believe, after loading the gui, it will autostart the windows 10 vm (with the usual artifacts on screen) One interesting thing to notice, is that while waiting for autostart VM, i cannot access the admin console (emhttp) - the firefox browser remains in "waiting for IP..." I am not sure if this is because of the flash usb drive, or some other issue with my hardware, or something else...? I do get some message just before the tower login prompt, related to unassigned devices, as if a certain file does not exist. I attach diagnostics for when i am successfully able to autostart the VM (unraid gui boot) - but i cannot extract the diagnostics for the situation when VM does not autostart (unraid default boot) kindly please suggest what should i try... thanks, alex towerx99-diagnostics-20180110-0035.zip

really not sure about that difference - slot vs bus. are you also using the ubuntu vm template?

i'm using the latest stable 6.3.5 Not sure about your question - it's a setting in uefi bios or some configuration in unraid? If bios, i think i'm using Legacy OS (non uefi) - really i am a bit confused on this and not sure if/how it matters. Here's the xml. Just note it's passing through a secondary 1060 gpu (so no rom file). also i'm passing through an on-board ASMedia usb controller (bus 0x07). <domain type='kvm'> <name>MintCin</name> <uuid>xx</uuid> <description></description> <metadata> <vmtemplate xmlns="unraid" name="Ubuntu" icon="ubuntu.png" os="ubuntu"/> </metadata> <memory unit='KiB'>4194304</memory> <currentMemory unit='KiB'>4194304</currentMemory> <memoryBacking> <nosharepages/> </memoryBacking> <vcpu placement='static'>4</vcpu> <cputune> <vcpupin vcpu='0' cpuset='4'/> <vcpupin vcpu='1' cpuset='5'/> <vcpupin vcpu='2' cpuset='10'/> <vcpupin vcpu='3' cpuset='11'/> <emulatorpin cpuset='0,6'/> </cputune> <os> <type arch='x86_64' machine='pc-q35-2.7'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/xx_VARS-pure-efi.fd</nvram> </os> <features> <acpi/> <apic/> </features> <cpu mode='host-passthrough'> <topology sockets='1' cores='2' threads='2'/> </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/disks/Samsung_SSD_750_EVO_500GB_xx/MintCin/vdisk1.img'/> <target dev='hdc' bus='virtio'/> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x04' function='0x0'/> </disk> <controller type='usb' index='0' model='nec-xhci'> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </controller> <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='dmi-to-pci-bridge'> <model name='i82801b11-bridge'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x1e' function='0x0'/> </controller> <controller type='pci' index='2' model='pci-bridge'> <model name='pci-bridge'/> <target chassisNr='2'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </controller> <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x02' slot='0x03' function='0x0'/> </controller> <filesystem type='mount' accessmode='passthrough'> <source dir='/mnt/user/lindrive'/> <target dir='lindrive'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/> </filesystem> <interface type='bridge'> <mac address='xx'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x0'/> </interface> <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <channel type='unix'> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x02' slot='0x05' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x02' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x02' slot='0x06' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x07' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x02' slot='0x07' function='0x0'/> </hostdev> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x02' slot='0x08' function='0x0'/> </memballoon> </devices> </domain>

totally understand the situation. d15s is asymetrical and might allow for better compatibility (but might go into the top fan of the case, etc...) but d15 ... then no option to take away the external fan? it will only increase temps by 2-3 C. i checked now - i also don't see the ovmf tianocore splash logo and neither the grub menu when booting the linux mint 18.2 - i just get the dots... then, the mint logo with the loading dots, then blank screen for 1-2 seconds, and finally the login screen - with an 1060. but this does not bother me currently give it a try also to give the rom explicitly to the gpu, even if it's not required - maybe a downloaded one will help you better than "who knows what" customized bios asus might have put in there... good luck...

i did not encounter stability issues with the plugged devices. also i am switching the unifying receiver from one controller to another (the controllers are passed through to different VM's) and no issue. USB sticks, HDD, speedlink wireless controllers - all went ok... The only issue i faced sometimes, as mentioned earlier, was with a rii mini keyboard usb dongle, when plugged in to an asmedia 3.1 internal controller - from time to time, it makes the controller to freeze or something, and i need to reset the whole unraid box...