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).