Jorgo

I found the problem, I had set the generel VM settings to not autostart VM. After I changed that value, everything initiated itself correctly. Thanks for you work, @SpaceInvaderOne!

Update: On every restart try of the container it creates a new NVRAM file with owner root. Almost seems like a permission problem.

I can't seem to get this running, Error: text error warn system array login % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 341M 100 341M 0 0 31.3M 0 0:00:10 0:00:10 --:--:-- 28.2M /config/vdisk1.qcow2.xz: 341.4 MiB / 866.9 MiB = 0.394, 35 MiB/s, 0:24 error: Failed to define domain from /config/tmp.xml error: internal error: Failed to start QEMU binary /usr/local/sbin/qemu for probing: Start/autostart is disabled in VM settings. sleep: invalid time interval '' Try 'sleep --help' for more information. Version check passed. Continuing... Host path for '/domains' is /mnt/user/domains Highest Q35 machine type available is pc-q35-9.1 The default VM network type is vhost0 Icon already there skipping..... mkdir: created directory '/domains/Home Assistant' I have created the Home Assistant directories. Found .qcow2.xz file: https://github.com/home-assistant/operating-system/releases/download/13.2/haos_ova-13.2.qcow2.xz downloading the Home Assistant vdisk from the official source extracting the vdisk to /config/vdisk1.qcow2.xz (removing the .xz)... Moving the extracted vdisk to /domains/Home Assistant/vdisk1.img... vdisk downloaded and moved to /domains/Home Assistant/vdisk1.img. As this is an OVMF VM, I need to create an NVRAM file. Creating now .... Formatting '/etc/libvirt/qemu/nvram/0bde0555-8a11-4213-8f16-c10b571d3c36_VARS-pure-efi.fd', fmt=raw size=65536 All required files are present. Attempting to define the VM... Failed to define the VM. There was an error during the VM definition process. Any ideas?

OK, I phrased that wrong... I just looked for a possiblity to acknowledge the smart warnings in the Unraid GUI (dashboard) but that is already possible through the context menu.

Hmm.... now the drives are working well but I am stuck with (old) smart warnings about high UDMA CRC error counts. The numbers aren't rising... is there any way to get rid of those?

Just a heads up. My problems seem to be fixed after I have replaced ALL cabling with fabric-covered, tight-locking versions, including Molex and SATA-cables. It seems to have been a mix of bad cabling, loose connections and case vibrations which made the error hard to track to a single source. Funny how this only showed up after almost a year of seemingly reliable operation. I came out of it with minimal data loss and learned a lot, although I don't know how much creeping corruption may have ocurred during the last year.

webGUI refused to work without -n and there was no text field to change that option.

I took your advice and used md3p1 so parity would be updated.

Thanks, that was a life-saver... repaired with minimal damage (lost+found 0 byte).

xfs_repair /dev/sdb

I can see from the read operations that it seems to be the correct drive. I am asking myself, though, why the disk checker returns different messages in GUI mode and command line mode? Also, in previous Unraid versions there existed the possibility to add/change flags in a text field after the button - how can I get that back in 7 beta 2? In case manual repair will fail because of superblock problems... would I be able to unassign that disk, assign a new one and get the contents back from parity? And/or should I rather run repair on the emulated drive after unassigning it?

OK, while still in maintenance mode I ran xfs_repair from command prompt on the drive without any arguments but in verbose mode. Here the output is Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! 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... and now it just prints dots, presumably searching the whole drive.... argh.

Sorry to bother you again, the troubles with my system won't end.... Now one of my drives in the array shows as unmountable. The file check shows some errors but overall doesn't look that bad... but xfs_repair doesn't offer to fix the file system. How do I go about this now (manually?)? Repair log follows: tower-diagnostics-20240909-1245.zip

Thanks, I'll keep investigating.

One 12TB Seagate is currently still connected, the other connected drives are fine and are not in quetion here. I had to disconnect 2 Seagate 12 TB because any access would make the system unresponsive after a short time (the drive controller keeps resettting).

A little over a year ago I bought 3 supposedly new Seagate Exos X16 12TB drives. I checked their warranty status and all seemed well. In the last weeks all 3 drives have started to exhibit similar bevhavior, namely command timeouts which on some operations eventually hang up the whole system. I tried different bays and even another controller - always the same results. I am posting Disagnostics and smart values for one of them - should I RMA them or could there be another problem? Thanks in advance! tower-diagnostics-20240907-2225.zip tower-smart-20240907-2221.zip

Well, I started the array again normally, then stopped and started in maintenance mode again and ran another check on the unmountable disk. Now the result 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... - 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 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - 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 = 3 - agno = 5 - agno = 8 - agno = 2 - agno = 7 - agno = 4 - agno = 9 - agno = 10 - agno = 6 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... Maximum metadata LSN (1:3393433) is ahead of log (1:3393409). Would format log to cycle 4. No modify flag set, skipping filesystem flush and exiting. The check button now offers FIX. Should I do that or something else?

I find myself in a pretty horrible situation and need some help. I'm on 7 beta 2 with 6 SATA disks attached to an ASMEDIA AS1166 PCIe card. File system is xsf. A few days ago I found that the server had locked up and I had to hard reset it. Since then, I noticed one or more disks show errors like "failed command: READ FPDMA QUEUED" - "hard resetting link". This included the parity disk. I then proceed to attach that directly to the Mobo and Unraid didn't find that disk on next reboot and I had to reassign that same disk as parity disk, losing parity. I tried to rebuild parity but the system repeatedly had mini freezes when another disk hard resetted its controller link. I let that run over night but the whole system froze again, presumably because the log overran with controller messages. On another attempt, the system got unresponsive and I short-pressed the power button. The system shut down after a while but after the next boot, one of the data disks is now unmountable. I ran a filesystem check from the GUI and xfs_repair_status tells me: 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. My first priority before tackling the other problems is to restore the data on this disk and back it up but I am unclear on how to proceed. The Checker button now says "ZERO LOG"... should I do that or something else? Thanks in advance!