Matthew Kent

Thank you @JorgeB, that seemed to do the trick... it looks like it even helped fix the crashing that was happening on my Truenas server that I have my Unraid syncing to over SyncThing. Any need for concern on that drive? That thing would be expensive to replace.

Hey everyone, I'm not entirely sure what happened, but I noticed today that my nextcloud instance was suddenly unresponsive. When I looked further, I found this on the cli of my system root@nas:~# cd /mnt/ root@nas:/mnt# ls /bin/ls: cannot access 'user': Input/output error /bin/ls: cannot access 'user0': Input/output error /bin/ls: cannot access 'disk1': Input/output error addons/ cache/ disk1/ disk2/ disk3/ disk4/ disks/ remotes/ rootshare/ user/ user0/ root@nas:/mnt# If I restart the array, everything comes back up, but after an hour, the above happens... or if I wander into certain directories. I'm not seeing SMART errors, or errors in general on my Main page, but I'm suspecting a drive is going. Can someone look at my logs and tell me what might be going on? Really appreciate it. -Matt The first diag is while having the errors listed above, the second diag is just after restarting the array matts-nas-diagnostics-20240830-0029.zip matts-nas-diagnostics-20240830-0038.zip

That's fine, I don't think any new info was written besides some of my media libraries emptying out because the drive had gone MIA. Thank you for your assistance

I'm back up. I ended up running the repair in the gui w/ the -L option, and then told the server to run with the new config since I didn't want to do a data rebuild from the unmountable parity image. As far as I can tell there are no lost-and-found files. Not sure if I lost anything, but I'm back up *whew*. Of course the wife had to ask about files she needed just when the server went down.

Uploading now. The results for xfs_repair from the gui is Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being ignored because the -n option was used. Expect spurious inconsistencies which may be resolved by first mounting the filesystem to replay the log. - scan filesystem freespace and inode maps... agf_freeblks 104761526, counted 104761523 in ag 1 agf_longest 104502791, counted 104502788 in ag 1 sb_fdblocks 1282724453, counted 1282724450 - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 bad nblocks 9198282 for inode 2196066468, would reset to 9198253 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 8 - agno = 9 - agno = 10 - agno = 3 - agno = 5 - agno = 7 - agno = 1 - agno = 11 - agno = 13 - agno = 14 - agno = 4 - agno = 6 - agno = 12 bad nblocks 9198282 for inode 2196066468, would reset to 9198253 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... The result without the -n is Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. nas-diagnostics-20240108-1347.zip

I ran it from the command line as I couldn't get it to run in the gui. xfs_repair /dev/sde

also, this is the current output of xfs_repair on the drive now attempting to find secondary superblock... .found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... ......................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................

Hi all, Hoping someone can help. I've been running my server for awhile and my largest drive last Friday went offline. I didn't know it was happening until I got a bunch of discord alerts that my media library files were missing and a cleanup of all the files had started. When I logged in, Disk 1 (A newer 16TB drive), showed unmountable: unsupported or no file system. I've since tried to remove the drive and start the array w/ the drive disconnected to try and get it to start w/ the drive emulated. Unfortunately it still says unmountable: unsupported or no filesystem. Does this mean the parity somehow saved with the drive in this state and is now emulated an unmountable drive? I'm hoping my data is still there in the parity. I'm planning on running xfs_repair on the drive now to see if I can get it back up. Any other suggestions would be greatly appreciated. I'm including my diagnostics file. nas-diagnostics-20240108-1133.zip

I don't have encrypted drives, how do I remove the passphrase requirement? I'd like my array to start on it's own after reboot, but I have to put in a passphrase everytime, even after setting the array to autostart

Hey! I finally figured it out. I don’t know why I was able to get this working on my old server. But essentially everything started working for me when I replaced my CPU with a CPU/GPU chip. It might’ve been the case I had an extra junk GPU inside my old server as it’s a full tower and forgot about it. Either way, I think GPU pass-thru doesn’t work properly unless you have more than one

Anyone?

Here is the current XML to the VM I created for the passthrough <?xml version='1.0' encoding='UTF-8'?> <domain type='kvm'> <name>GamerVM</name> <uuid>ed2f15bb-c32e-85d7-0de3-869fca92f0dc</uuid> <metadata> <vmtemplate xmlns="unraid" name="Windows 10" icon="Windows_11.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='4'/> <vcpupin vcpu='1' cpuset='12'/> <vcpupin vcpu='2' cpuset='5'/> <vcpupin vcpu='3' cpuset='13'/> <vcpupin vcpu='4' cpuset='6'/> <vcpupin vcpu='5' cpuset='14'/> <vcpupin vcpu='6' cpuset='7'/> <vcpupin vcpu='7' cpuset='15'/> </cputune> <os> <type arch='x86_64' machine='pc-q35-5.1'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/ed2f15bb-c32e-85d7-0de3-869fca92f0dc_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' migratable='on'> <topology sockets='1' dies='1' cores='4' threads='2'/> <cache mode='passthrough'/> <feature policy='require' name='topoext'/> </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-MKNSSDCR60GB_MKN1203A0000041856'/> <target dev='hdc' bus='sata'/> <boot order='1'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='writeback'/> <source file='/mnt/user/VMs/GamingVM/Storage.qcow2'/> <target dev='hdd' bus='sata'/> <address type='drive' controller='0' bus='0' target='0' unit='3'/> </disk> <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='1' port='0x10'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/> </controller> <controller type='pci' index='2' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='2' port='0x11'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/> </controller> <controller type='pci' index='3' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='3' port='0x12'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/> </controller> <controller type='pci' index='4' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='4' port='0x13'/> <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='0x8'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0' multifunction='on'/> </controller> <controller type='pci' index='6' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='6' port='0x9'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <controller type='pci' index='7' model='pcie-to-pci-bridge'> <model name='pcie-pci-bridge'/> <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='0x00' function='0x0'/> </controller> <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> <controller type='usb' index='0' model='qemu-xhci' ports='15'> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:db:fc:4a'/> <source bridge='br0.4'/> <model type='virtio-net'/> <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </interface> <serial type='pty'> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> </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='tablet' bus='usb'> <address type='usb' bus='0' port='3'/> </input> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <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> <audio id='1' type='none'/> <video> <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> <address type='pci' domain='0x0000' bus='0x07' slot='0x01' function='0x0'/> </video> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x09' slot='0x00' function='0x0'/> </source> <rom file='/mnt/user/appdata/vbios/Gigabyte.RX5700XT.8192.191105.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='0x09' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x1'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x045e'/> <product id='0x0291'/> </source> <address type='usb' bus='0' port='1'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x0b05'/> <product id='0x1939'/> </source> <address type='usb' bus='0' port='2'/> </hostdev> <memballoon model='none'/> </devices> </domain> I've tried it with and without checkmarking the IOMMU vfio boxes.

Hi All, One of the things I used to love about my unraid server was gaming. At one point I eventually upgraded to the 5700xt, followed the typical steps with enabling IOMMU in BIOS, editing the XML for multifuction capabilities, and had no problem gaming. Then a little less than a year ago, I decided to move my server to my office, and built a smaller unraid server for VM lab work with the eventual goal of gaming again. I finally decided to do some gaming, but for the life of me can't get passthrough working. Initially I only did the XML edits like I'd done before, then decided to add the bios file when the XML edits didn't work. I should also add, when I start the VM, within a minute, the entire server freezes up, and I have to do a hard reboot to get it back up. Eventually I decided to add IOMMU passthrough for the GPU in system devices. This helped a little, so the server no longer freezes up. But on my screen, I only get the POST screen. If I add VNC as screen 1, the VM loads, but the GPU still does not work. It shows up in device manager, but with an error. Does anyone have any ideas? I really want to get passthrough working again, I have other things I wanted to get up and running that needs GPU power.

Any updates on this? I also have a gigabyte 5700xt, and once upon a time with a previous config was doing GPU passthrough without any issues. Then recently I built a new server, put my 5700xt into it, followed the same steps as before and for the life of me can't get the damn thing to work. Hoping someone's seen the light w/ this card + unraid combo