ghost82
Members
-
Joined
-
Last visited
Everything posted by ghost82
-
Yes You don't need to be an advanced user to read the changelog. Having said that, you have all the info you need, have a nice day.
-
What has an issue is this VERSION, I would say instead that it's your build that has issue, what's the difference? You didn't attach diagnostics, you attached 2 screenshots that say nothing more than your network doesn't work. Read the first post, it has description and fixes for tg3 drivers. Not true
-
Your behaviour will not help...and I described how to roll back.
-
Download the zip package from unraid site and overwrite bz... files on your usb.
-
not good?did you read the first post/changelog before update? It seems you have an issue with your caps lock.
-
May 30 01:24:10 Gizbo emhttpd: Unregistered - flash device blacklisted (EBLACKLISTED) Either the guid is empty (check if the guid is ok, if it's not ok and it's plugged in usb 3 move it to usb 2 and check again). Or the guid of your usb key is not unique. Or you already registered that usb key and then you transferred the license from there to somewhere else: in this case the blacklist is hardcoded in the system.
-
duckdns (if you don't have static public ip address) + wireguard: https://www.youtube.com/watch?v=HIJiYuPDzKs https://unraid.net/blog/wireguard-on-unraid
-
vms on hdds are not the best but I think you already noticed. I'm running a linux vm on a vdisk on a hdd on a non unraid build and recently I got some issues with performance, well...in real it was unusable...firefox wasn't launching, gedit stuck, updates took forever.. I had some luck, i.e. the vm is now usable, by changing vm.dirty_background_ratio and vm.dirty_ratio The symptom is that you have in your log something like: task xxxx:xxxx blocked for more than 120 seconds --> this is i/o issue Values depend on the build, so you need to experiment yourself. Unraid should have a plugin for this (tips and tweaks by user dlandon).
-
Where? Are you sure about this?if bios is uefi as far as I know there's no way for a legacy gpu to output anything, but this isn't your case. You igpu should work both with uefi and legacy bios. Error 43 is a generic error meaning that the gpu cannot be initialized, this depends on several reasons. If you get a black screen with ovmf usually it means the gpu is used by something else: make sure to isolate it, check that the igpu is not used by efifb, if it's used disable it in syslinux config (or boot unraid in legacy bios mode), setup the gpu as multifunction (so pass also the audio part), use your own bios dump. On some builds with 'bugged' bioses this may not be possible at all.
-
Hi, look at this, it doesn't seem related to vm settings. https://unix.stackexchange.com/questions/547812/how-to-enable-2560x1440-option-for-display-in-linux-mint Look at the xrandr output and see what are available resolutions and max. Check your monitor EDID, decode it, and see if 2560x1440 is available in the EDID. Check also the refresh rate (frequency) when you set the new resolution, this depends on the monitor, gpu, cable and resolution.
-
It's ok, what you don't want is to have other devices you don't want to passthrough in the same iommu group as your gpu video or gpu audio. So these cases are ok: 1. gpu audio and video are in the same iommu group, without any other device that you don't want to passthrough to the vm 2. gpu audio and video are in different iommu groups, without any other device that you don't want to passthrough to the vm 3. gpu audio and video are in the same iommu group, together with other devices that you want to passthrough to the vm 4. gpu audio and video are in different iommu groups, together with other devices that you want to passthrough to the vm In your case (case: 2) simply bound to vfio iommu groups 17 and 18. Do not use syslinux config. use only unraid panel.
-
sorry, no ideas...I hate when things don't work randomly or when it seems there's no sense (in this case the fail on first boot...but Why??...)
-
If the ssd is passed through as a 'by-id' block you will connect this block to a virtual disk controller; if the disk is a vdisk file the virtual disk is attached in the same way to a virtual disk controller; so, yes it's nearly the same. If you passthrough a sata/nvme controller you wont have the overhead of the virtual disk controller, this is noticeable or not depending on the hardware. It depends on how many physical cores you have: best practice is to reserve cpu 0 to unraid (and its hyperthreaded core), then you can assign the others. If you are using only the vm when it runs with no other particular background processes, just reserve cpu 0 (and its hyperthreaded core) and assign the others to the vm. Nothing particular and everything is quite straight forward to have a basic windows vm running: - choose q35 + ovmf (ovmf+tpm for windows 11) - choose a vdisk or disk to install windows on - choose an iso for installation media - choose the virtio iso for virtio drivers (only needed if you use any virtio device) - run the vm; if it falls back to the uefi shell when you are in vnc viewer just type 'exit' and you will access ovmf bios, choose 'continue' and then press a key on your keyboard to run from the installation iso If you want to go very smooth do not choose any virtio device, especially for the virtual disk controller, otherwise you need to load virtio drivers, because windows doesn't include them and it wont be able to see the disk. Tutorial?for example this: https://www.youtube.com/watch?v=miYUGWq6l24
-
Reference post: https://forums.unraid.net/topic/124021-win-10-vm-bootbcd-io-error-after-unraid-6101-update/ This user was receiving a bcd error for his passed through nvme controller with a windows 10 installation. He stated that windows booted correctly when not run in a vm. The issue was solved by pointing in the xml to a newer compiled seabios version (latest 1.16).
-
Hi, I tested unraid 6.10.1 and 6.10.2 but I think the issue comes from 6.10.0RC7 when libvirt 8.2.0 was introduced. It seems there are several issues: 1. Unraid gui (xml view): Reference post: https://forums.unraid.net/topic/123933-unraid-610-win10-vm-not-able-to-start-intel-btwifi-3168-device-error-code-10/ The user was trying to use: <qemu:capabilities> <qemu:del capability='usb-host.hostdevice'/> </qemu:capabilities> to avoid error 10 on its bluetooth device. Issue: he first added only that block of code before the closing </domain> tag in the unraid gui (xml view); after pressing the update button there was no output error, but viewing again the vm settings in xml view mode there was no trace of that block. If the vm is modified with 'virsh edit VmName' then it outputs an error (no validated schemas found for that block). That's because additionally to that block he needed to modify from: <domain type='kvm'> to: <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> Changes through the unraid gui (xml view) or through virsh edit command work. The issue is that unraid gui (xml view) is exiting without outputting any error, and the user thinks everything was correctly modified, but it wasn't. 2. Second issue: Reference post: https://forums.unraid.net/topic/120232-atheros-ar9280-wireless-card-bar-error The user is trying to add property x-msix-relocation for his wifi device. Libvirt 8.2.0 introduced <qemu:override> to be able to override properties for passed through devices. The sintax is: <qemu:override> <qemu:device alias='YOURALIASHERE'> <qemu:frontend> <qemu:property name='x-msix-relocation' type='string' value='bar2'/> </qemu:frontend> </qemu:device> </qemu:override> together with: <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> Both these changes aren't saved, both through the unraid gui (xml view) and with the 'virsh edit VmName': both do not output any error, but changes aren't applied. This is more tricky, because in my manjaro build (as host) changes are applied correctly with the 'virsh edit VmName'. In this build I have: libvirt-1:8.3.0-1-x86_64 qemu-XXXX-7.0.0-10-x86_64 I don't think the issue is with qemu 6.2 included in unraid, maybe an update to libvirt (from 8.2.0 to 8.3.0) worth a try. PS: I'm seeing during boot that there is a checksum on bzroot file, I don't know if it prevents boot or not if the checksum fails (for 'security' reasons), so I can't repack/replace the binaries inside it, without maybe cracking any additional binary...thing that I don't want to do to troubleshoot this more.
-
I confirm there's a problem that needs to be investigated. Will update.
-
Try with virsh command, look at this thread: https://forums.unraid.net/topic/123933-unraid-610-win10-vm-not-able-to-start-intel-btwifi-3168-device-error-code-10/?do=findComment&comment=1130894 export nano as editor then run virsh edit, save with ctrl+o
-
did you edit also the wrong domain line? <domain type='kvm'> without the schemas the xml will not validate and it will not save the block. But if you modify that line as written in my last post the block will save, I tried it.
-
unfortunately it really sounds a bios bug to me..6000 series cards do not suffer the reset bug, but you're not alone, other users with aorus motherboards are experiencing this issue with 6000 series gpus. It seems that you can use a reset script to properly reset the gpu, you can read more here: https://forum.level1techs.com/t/6700xt-reset-bug/181814/36 You could also contact asus and report your issue, maybe one day they will release a new bios for your motherboard.
-
Sorry but there's nothing to fix!You just need to follow best practice for vms. Go to Settings -> VM Manager and set PCIe ACS override to both. Reboot the server. Go to Tools -> System Devices and put a check next to: VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] [1002:731f] (rev ff) and Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 HDMI Audio [1002:ab38] (rev ff) Move to the vm tab, left click on the icon of the vm, edit, click on xml view (top right), find this: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </source> <rom file='/mnt/user/ISOs/vbios/5700 xt.rom'/> <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='0x03' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> </hostdev> Replace with this: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </source> <rom file='/mnt/user/ISOs/vbios/5700 xt.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='0x03' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x1'/> </hostdev> Reboot server. Try. Attach new diagnostics after the changes if it doesn't work
-
if it's not outputting any error you probably changed something?If this is the case new diagnostics is needed.
-
Trust me it should be better now Now you have this: May 27 05:50:50 server kernel: vfio-pci 0000:0b:00.0: BAR 0: can't reserve [mem 0xd0000000-0xdfffffff 64bit pref] ...and yes because: May 27 05:28:41 server kernel: pci 0000:0b:00.0: BAR 0: assigned to efifb Go to Main --> flash --> syslinux configuration and edit the "green label": add to the 'append' line: video=efifb:off such that it's like: append blablabl blablalba video=efifb:off [without blablabl blablalba ] Reboot the server and try
-
as far as I know no...maybe try to change the physical slot, but I'm not confident it will work...
-
As you can see all the 4 devices (03:00.0, .1, .2 and .3) are in the same iommu group. You can't assign one device (i.e. .0) to a vm and another one (i.e. .1) to another vm at the same time when devices are in the same iommu group. Unfortunately I'm seeing that you are still using the acs override patch and it didn't split this group
-
how the ethernet card splits in iommu groups?diagnostics
