dominicmck

Re-sync worked as expected. All working now. @JorgeB Thanks so much for your help!

Results look promising. Drive can be mounded by starting the array, and I can browse the file system. However, parity drive is still disabled, even after a reboot. Any suggestions? Thanks. root@Tower:~# xfs_repair -vL /dev/md1p1 Phase 1 - find and verify superblock... - block cache size set to 539608 entries Phase 2 - using internal log - zero log... zero_log: head block 2425326 tail block 2425301 ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... clearing needsrepair flag and regenerating metadata sb_fdblocks 114794426, counted 115775119 - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 5 - agno = 4 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (11:2428865) is ahead of log (1:2). Format log to cycle 14. XFS_REPAIR Summary Mon Oct 9 12:28:03 2023 Phase Start End Duration Phase 1: 10/09 12:25:59 10/09 12:25:59 Phase 2: 10/09 12:25:59 10/09 12:26:09 10 seconds Phase 3: 10/09 12:26:09 10/09 12:26:34 25 seconds Phase 4: 10/09 12:26:34 10/09 12:26:35 1 second Phase 5: 10/09 12:26:35 10/09 12:26:36 1 second Phase 6: 10/09 12:26:36 10/09 12:26:49 13 seconds Phase 7: 10/09 12:26:49 10/09 12:26:49 Total run time: 50 seconds done tower-diagnostics-20231009-1244.zip

Apologies. Started in maintenance mode this time. root@Tower:~# xfs_repair -v /dev/md1p1 Phase 1 - find and verify superblock... - block cache size set to 539608 entries Phase 2 - using internal log - zero log... zero_log: head block 2425326 tail block 2425301 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. root@Tower:~# Reading the error, I tried starting the array (to "Mount the filesystem"), but nothing changed. If I destroy the log, how much data might be lost and is there a way to identify it so I can recover it from backup? Thanks. tower-diagnostics-20231009-1149.zip

Thanks @JorgeB Run again with your correction: root@Tower:~# xfs_repair -v /dev/md1p1 /dev/md1p1: No such file or directory /dev/md1p1: No such file or directory fatal error -- couldn't initialize XFS library Fresh diags attached. tower-diagnostics-20231009-1104.zip

Hi all, I was trying to make some changes to my server and I noticed that no changes were being saved. When I click Apply my browser just says waiting for 192.168… after a while the values change back to what they were. This happened in Shares, Users, and Disk Settings. So I restarted my server only to be met with Disk1 “Unmountable: Unsupported or no file system”. I have run short and full SMART tests and both are fine. I’ve had no errors on the disk before (3-year-old 4 TB Ironwolf in a HP gen8 microserver). Looking in the logs I see: Oct 8 14:20:31 Tower kernel: XFS (md1p1): Mounting V5 Filesystem Oct 8 14:20:31 Tower root: mount: /mnt/disk1: wrong fs type, bad option, bad superblock on /dev/md1p1, missing codepage or helper program, or other error. Oct 8 14:20:31 Tower root: dmesg(1) may have more information after failed mount system call. Oct 8 14:20:31 Tower kernel: XFS (md1p1): Corruption warning: Metadata has LSN (11:2428865) ahead of current LSN (11:2425326). Please unmount and run xfs_repair (>= v4.3) to resolve. Oct 8 14:20:31 Tower kernel: XFS (md1p1): log mount/recovery failed: error -22 Oct 8 14:20:31 Tower kernel: XFS (md1p1): log mount failed Oct 8 14:20:31 Tower emhttpd: shcmd (34): exit status: 32 Oct 8 14:20:31 Tower emhttpd: /mnt/disk1 mount error: Unsupported or no file system Oct 8 14:20:31 Tower emhttpd: shcmd (35): rmdir /mnt/disk1 Using the GUI Check Filesystem Status I got: Phase 1 - find and verify superblock... superblock read failed, offset 0, size 524288, ag 0, rval -1 fatal error -- Input/output error I also tried: root@Tower:~# xfs_repair -v /dev/md1 /dev/md1: No such file or directory /dev/md1: No such file or directory fatal error -- couldn't initialize XFS library I’ve reseated all the drives. But no change. Can someone please point me in the right direction for the next steps? Diagnostics attached. Thanks for your help. Dom tower-diagnostics-20231009-0716.zip

I moved my GPU to another PC, so don't have a working XML at the moment, sorry. The attached are from around the time I got it working. Could be a clue in them. Win10GPUWorking.txt UbuntuGPUWorking.txt

Hi, been a while so I can't find the article that helped me. But as remember it, the issue was the GPU video and audio need to be on the same bus & 'top' slot which it isn't by default. The article I read suggested to think about the virtual motherboard you are trying to create, and the layout of the items on it. You wouldn't put your primary GPU in your bottom PICE slot in a physical MB, so you dont on a virtual one either. My VM thought 2 was the 'top' pcie slot. Your virtual top slot might be different. There was already something defined on slot 2, so I had to shuffle that to another slot before I could put the GPU there.

For anyone that comes across it. I have managed to get this working. Lots of old info on the forums that aren't current. Newer info that helped was: Latest Bios J06 04/04/2019 Patched unRaid to get around RMRR. The usual "append vfio_iommu_type1.allow_unsafe_interrupts=1 pcie_acs_override=id:XXXX:XXXX,YYYY:YYYY initrd=/bzroot" DVI to HDMI cable (the hdmi port on my GT 1030 wont output for a VM) No Bios specified in the xml for this GPU. Windows and Ubuntu, both running fine with no gpu bios. Nvidia drivers installed, no code 43 issue. Adding a Bios actually stopped the VM from working at all. In the VM XML add the multifunction = on and set sound and gpu to be same slot, different functions. In the VM XML I had to shuffle the bus and slots for some reason. Slot 5 was the default, but making it slot 2 seemed to be the final thing to make it work. Hyper-V = no for Win10 VM. Note, this was with a different CPU to the original post but hopefully doesn't matter. Now using a Intel Xeon E31-260L

For me the logs weren't loading on PC but fine on mobile. It ended up being my AV. Kaspersky Web-Anti Virus. Added my server IP to the Trusted URLS and started working fine.

Logs attached if you're still interested in taking a look. Cheers, Dom tower-diagnostics-20170203-1219.zip

Thanks for the detailed answer. Lots for me to test and check so might talk a day or two to get through (I only have remote access most of the time as the server is offsite at the moment). Making the syslinux.cfg change (thx for the tip on easier editing) didn’t help, and since it’s a Gen8 Microserver, there are no more pcie slots to try. I’m going to have another go with a different GPU this weekend, and will let you know how I get on. The link to the HP article looks like it was relevant, but I already have the bios it suggest as the resolution. I will double check though. I think unless I can track down someone with the same microserver who has resolved this (I’ve seen a couple of others on here who couldn’t and got new hardware), I might just have to chalk it up to hardware incompatibility and move on. While I’d love to get to a definitive answer about what the issue is, sometime you just need to accept the joys of tech and focus on more productive projects. This was only a long shot to save some money anyway. I should really focus on getting a proper solution in place, with dedicated fit for purpose hardware.

Hi, thanks for the quick reply. I've added the code you mentioned to my /boot/syslinux/syslinux.cfg using MC. but no luck, same error. Full content is: default /syslinux/menu.c32 menu title Lime Technology, Inc. prompt 0 timeout 50 label unRAID OS menu default kernel /bzimage append vfio_iommu_type1.allow_unsafe_interrupts=1 pcie_acs_override=downstream initrd=/bzroot label unRAID OS GUI Mode kernel /bzimage append initrd=/bzroot,/bzroot-gui label unRAID OS Safe Mode (no plugins, no GUI) kernel /bzimage append initrd=/bzroot unraidsafemode label Memtest86+ kernel /memtest My Win10 VM XML is: <domain type='kvm'> <name>Windows 10</name> <uuid>71292d03-255e-9f6a-9454-c7eb2a22793b</uuid> <metadata> <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/> </metadata> <memory unit='KiB'>6815744</memory> <currentMemory unit='KiB'>6815744</currentMemory> <memoryBacking> <nosharepages/> <locked/> </memoryBacking> <vcpu placement='static'>4</vcpu> <cputune> <vcpupin vcpu='0' cpuset='2'/> <vcpupin vcpu='1' cpuset='3'/> <vcpupin vcpu='2' cpuset='6'/> <vcpupin vcpu='3' cpuset='7'/> </cputune> <os> <type arch='x86_64' machine='pc-i440fx-2.5'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/71292d03-255e-9f6a-9454-c7eb2a22793b_VARS-pure-efi.fd</nvram> </os> <features> <acpi/> <apic/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> <vendor id='none'/> </hyperv> </features> <cpu mode='host-passthrough'> <topology sockets='1' cores='2' threads='2'/> </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='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/domains/Windows 10/vdisk1.img'/> <target dev='hdc' bus='virtio'/> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> <controller type='usb' index='0' model='ich9-ehci1'> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <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'> <master startport='2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x1'/> </controller> <controller type='usb' index='0' model='ich9-uhci3'> <master startport='4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2'/> </controller> <controller type='pci' index='0' model='pci-root'/> <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:0b:ea:04'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <channel type='unix'> <source mode='connect'/> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <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='0x00' slot='0x05' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x07' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </hostdev> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </memballoon> </devices> </domain>

Hi All, I recently installed a Xeon E3-1265L V2 into my gen8 microserver hoping to get GPU passthrough working for a Win10 casual gaming VM. I am able to select the GPU (and associated sound card) in the VM settings via the drop down, but when I start the VM I get an error (detailes below). I've looked around the forum and found a lot of old and conflicting reports on getting this fixed. Some user have given up, other say its working with brief mentions of fixes & hacks but no details on how to enable them. I've tried 'Enable PCIe ACS Override', and making a change to syslinuk.cfg. I've googled a lot about what I found in the "KVM VGA Passthrough" spreadsheet (https://docs.google.com/spreadsheets/d/1LnGpTrXalwGVNy0PWJDURhyxa3sgqkGXmvNCIvIMenk/edit#gid=0) there is one reference to a working gen8 with the notes "with libvirt, bus=0x00(meaning use pcie), add kvm hidden into features" but I cant track down the username associated with the record to learn what this means or how to do it. I'm leaning towards giving up and getting a refund on the CPU and putting my effort into a second machine build in a few months. Thanks for any help or advice. Dom Technical details: internal error: early end of file from monitor, possible problem: 2017-02-02T14:05:02.861779Z qemu-system-x86_64: -device vfio-pci,host=07:00.0,id=hostdev0,bus=pci.0,addr=0x5: vfio: failed to set iommu for container: Operation not permitted 2017-02-02T14:05:02.861806Z qemu-system-x86_64: -device vfio-pci,host=07:00.0,id=hostdev0,bus=pci.0,addr=0x5: vfio: failed to setup container for group 1 2017-02-02T14:05:02.861812Z qemu-system-x86_64: -device vfio-pci,host=07:00.0,id=hostdev0,bus=pci.0,addr=0x5: vfio: failed to get group 1 2017-02-02T14:05:02.861821Z qemu-system-x86_64: -device vfio-pci,host=07:00.0,id=hostdev0,bus=pci.0,addr=0x5: Device initialization failed Info from my Tools > System Devices: PCI Devices 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v2/Ivy Bridge DRAM Controller [8086:0158] (rev 09) 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port [8086:0151] (rev 09) 00:06.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port [8086:015d] (rev 09) 00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 05) 00:1c.0 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 [8086:1c10] (rev b5) 00:1c.4 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 [8086:1c18] (rev b5) 00:1c.6 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 7 [8086:1c1c] (rev b5) 00:1c.7 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 8 [8086:1c1e] (rev b5) 00:1d.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 [8086:1c26] (rev 05) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev a5) 00:1f.0 ISA bridge [0601]: Intel Corporation C204 Chipset Family LPC Controller [8086:1c54] (rev 05) 00:1f.2 SATA controller [0106]: Intel Corporation 6 Series/C200 Series Chipset Family SATA AHCI Controller [8086:1c02] (rev 05) 01:00.0 System peripheral [0880]: Hewlett-Packard Company Integrated Lights-Out Standard Slave Instrumentation & System Support [103c:3306] (rev 05) 01:00.1 VGA compatible controller [0300]: Matrox Electronics Systems Ltd. MGA G200EH [102b:0533] 01:00.2 System peripheral [0880]: Hewlett-Packard Company Integrated Lights-Out Standard Management Processor Support and Messaging [103c:3307] (rev 05) 01:00.4 USB controller [0c03]: Hewlett-Packard Company Integrated Lights-Out Standard Virtual USB Controller [103c:3300] (rev 02) 03:00.0 Ethernet controller [0200]: Broadcom Limited NetXtreme BCM5720 Gigabit Ethernet PCIe [14e4:165f] 03:00.1 Ethernet controller [0200]: Broadcom Limited NetXtreme BCM5720 Gigabit Ethernet PCIe [14e4:165f] 04:00.0 USB controller [0c03]: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller [1912:0014] (rev 03) 07:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 8400 GS Rev. 3] [10de:10c3] (rev a2) 07:00.1 Audio device [0403]: NVIDIA Corporation High Definition Audio Controller [10de:0be3] (rev a1) IOMMU Groups /sys/kernel/iommu_groups/0/devices/0000:00:00.0 /sys/kernel/iommu_groups/1/devices/0000:00:01.0 /sys/kernel/iommu_groups/1/devices/0000:07:00.0 /sys/kernel/iommu_groups/1/devices/0000:07:00.1 /sys/kernel/iommu_groups/2/devices/0000:00:06.0 /sys/kernel/iommu_groups/3/devices/0000:00:1a.0 /sys/kernel/iommu_groups/4/devices/0000:00:1c.0 /sys/kernel/iommu_groups/5/devices/0000:00:1c.4 /sys/kernel/iommu_groups/6/devices/0000:00:1c.6 /sys/kernel/iommu_groups/7/devices/0000:00:1c.7 /sys/kernel/iommu_groups/8/devices/0000:00:1d.0 /sys/kernel/iommu_groups/9/devices/0000:00:1e.0 /sys/kernel/iommu_groups/10/devices/0000:00:1f.0 /sys/kernel/iommu_groups/10/devices/0000:00:1f.2 /sys/kernel/iommu_groups/11/devices/0000:03:00.0 /sys/kernel/iommu_groups/11/devices/0000:03:00.1 /sys/kernel/iommu_groups/12/devices/0000:04:00.0 /sys/kernel/iommu_groups/13/devices/0000:01:00.0 /sys/kernel/iommu_groups/13/devices/0000:01:00.1 /sys/kernel/iommu_groups/13/devices/0000:01:00.2 /sys/kernel/iommu_groups/13/devices/0000:01:00.4

Was there any main reason you went for unassigned? My understanding is that it exposes you to risk due to no parity 'backup', so I assume it was for performance or that you considered the data less valuable?

Hi All, I'm looking to replace an old WHS2011 system with a new unrRAID one. The new system will need to continue doing a bunch of the things the old one did, so I'm considering using a WHS2011 VM to continue to run a few backup utilities like Resilio (BT Sync), Drop Box, Google Drive, and Google Photos. These are all part of various backup solutions for various media types I use. Once setup in the VM they don't support Network drives as targets, so I would be looking at creating a large virtual hard-drive of around 200GBs to be the target of these various backups. This would put the files in a vHD, in unRAID KVM, on an XFS file system (I think). How resilient is this to corruption/data-loss compared to my original setups of a bare-metal WHS2011 with NTFS drives? It feels like there are more layers between the disks and the files where things could go wrong. Thanks for any help, Dom