• Posts

  • Joined

  • Last visited

augot's Achievements


Newbie (1/14)



  1. Hmm, interesting. I've had some USB devices being a bit quirky since I started running a Windows VM as my daily driver on my server (5950x paired with an Asus X570-P Prime). I've got a few things plugged into a nine-port USB 3.0 hub - when I was running Windows on bare metal I never noticed anything strange, but now if I plug in more than 4-5 devices things definitely get... inconsistent. Windows doesn't register disconnections/connections, but for anything bluetooth (keyboards, mice, game controllers, etc) their connection is liable to have dropouts for a couple of seconds, up to half a dozen times a day. It's not a dealbreaker, it happens infrequently enough that I can live with it, but the possibility that it could corrupt my boot drive is not something I had considered...
  2. Not sure how I missed that there was a ceiling to the supported RAM speeds for 3rd gen Ryzen - woops. Somewhat of a shame, since I went for a 3400MHz/C16 combo for gaming performance with my Windows VM rather than just for the sake of it, upgrading from 2667MHz sticks which, it turns out, would actually have been more appropriate all along... Hmm. The parity check has about an hour left to run. I'll still run memtest overnight just to be sure, but if nothing bad comes up I'll see whether it happens again and tune down the RAM in bios. I had been having some weird issues with USB devices in my Windows VM, with bluetooth devices having connection dropouts if connected to the same passed-through USB 3.0 hub (which never happened on bare metal) - would incorrect RAM speed play a part in that, perhaps?
  3. At some point this afternoon my server appears to have rebooted itself. When I realised and logged back in, Fix Common Problems alerted me: "Your server has detected hardware errors. You should install mcelog via the NerdPack plugin, post your diagnostics and ask for assistance on the unRaid forums. The output of mcelog (if installed) has been logged." So... Here I am! Diagnostics zip attached. I'm on 6.9.0-rc2. Specs: CPU: Ryzen 9 5950x RAM: 4x16GB G.Skill Ripjaws V 3400 DDR4 C16 Motherboard: Asus X570-P Prime Storage: 2x1TB SSD cache pool for appdata and downloads and stuff like that, 2x2TB nvmes for the vdisk for a Windows 10 VM, 8x8TB HDD array GPU: GTX1660 (used for Plex), GTX2070 Super (passed through to Windows VM) PSU: 1000W Corsair HX1000i Looking through the log, there's a repeating error message that came around a bunch of times before Unraid booted up normally: Not sure if this is the specific problem that caused the reboot/Machine Check Events warning or not. I searched "kernel taint" and it seems it's not the kind of thing that would usually indicate a hardware failure, but maybe I'm mistaken there? My other guess is that the RAM is new as of about six weeks ago, and it might be a fault with that - once the parity check finishes I'm gonna reboot properly and run a memtest. But any help appreciated!
  4. Same issue here for me (although I upgraded from beta35 to rc2, skipping rc1). Seems stable otherwise. Have eight spinners connected in two pairs of four to an LSI 9205-8e. Disks ignore my default spindown delay setting of 15 minutes, and if I manually spin any individual disk down it immediately spins back up. No dockers/VMs are actually accessing the disks to make this happen, as far as I can tell.
  5. I had been planning to upgrade to one of the new Ryzen 5000s early next year, and upgrade the PSU with it - I think I'll just move the PSU upgrade up and see whether that helps. Thank you.
  6. Thanks for taking a look! Hmm - I think I have a spare SATA power cable somewhere. I'll swap it in and check, but the disks that have been going down have been on separate cables before now. But I wonder if more likely is that it's the PSU isn't handling the power surge when all eight array disks spin up under heavy load simultaneously? It handles all the disks being spun up and used fine, but then that's not a max load, all at once. And it's a six-year-old PSU at this point (salvaged from a previous desktop), so this could be the first signs of it dying. It's been a year since I flashed the LSI card, but I remember there being some issue that meant was the most recent firmware it would accept... I'll look into that though, thanks for flagging, I hadn't even thought that might be problematic since I hadn't had any kinds of disk problems since I first flashed it. Can't hurt to try and use the most stable release.
  7. Yeah, I figured that'd be required. Ah well. Bit the bullet and started a parity check just now - immediately, Disk 2 was disabled this time (after 2048 errors, which I remember being identical each time this has happened, and the read/write/print errors in the log look the same as well). Cancelled the check and generated a diagnostics zip which hopefully will shed more light on what's happening...
  8. I've been using Unraid for a year now, and - after getting over each new learning curve as a total Linux newbie - I've been loving it. However, I've been having some issues over the last month with disks becoming disabled, and, while I'm currently thinking it might be a hardware rather than disk issue (probably my LSI card), I was hoping for some advice before I continue troubleshooting. Hardware: Processor: AMD Ryzen 5 1600AF Motherboard: ASUS Prime X570-P Memory: Corsair Vengeance LPX 2x8GB 2666MHz DDR4 Graphics Card: Gigabyte GeForce NVIDIA GTX 1660 OC (passed through to Plex) Case: Uh well it's an Ikea Alex (with added intake fans), with a PC workbench + drive caddy inside (made more sense than a case inside a cupboard for cooling!) PSU: 500W Silverstone SX500-LG Hard Drives: (Cache) 2 x 1Tb Samsung 860 PRO + 1 x 2TB WD Blue m.2, (Array) 7 x 8TB WD (mixture of shucked EFAZ, EFAX, EFZX, EMAZ) + 1 x 8TB shucked Seagate ST8000AS0002 HBA: HP H221 660087-001 LSI SAS 9207-8e (flashed to IT mode, array is connected in two groups of 4 disks) The first time the issue appeared was when I rebooted the array around five weeks ago. When the server came back online, the server had detected an unclean shutdown (strangely, it was a normal reboot sequence), initiated a parity check, and immediately disabled one of the disks. I went into maintenance mode, ran a long SMART test, checked cabling, etc, etc, all the usual steps. It was a fairly new disk (<6mo old) and everything came back fine, so I figured I'd take the chance it was a one-off and rebuild. Worked fine for a week... until my scheduled parity check started on the first of the month. I was immediately hit with an alert that a disk had been disabled, but, this time, a different disk to the last one. Checked everything again over the couple of days or so, disk itself seemed fine, so rebuilt again and continued on for another week or so until I had to reboot the server again. When it came back up... again, it had tried to start a parity check on boot, but now there were two disks disabled, and they were also completely different to either of the first two. Checked the disks again, again nothing seemed amiss, so rebuilt and everything seemed fine... until it happened again on the first of this month, when parity check starting knocked out one of my array disks again. So at this point I know for sure that I obviously have something very wrong, somewhere, and I can't keep rebuilding my array like this if I want my drives to last. (Also worth noting, these disks have been on either of the two cables coming from the H221.) Every time this had happened, too, it seemed to be happening immediately on starting a parity check. Since I have everything on my array backed up and can recover later, I felt I could test things a little more, so once the last round of parity rebuilding finished in maintenance mode I initiated a reboot to try and manually recreate the issue. No disks disabled! OK, but that's maintenance mode - what about normally? Started the array, waited for all dockers to finish starting up, hit reboot, and... yep, another random disk disabled after parity check was attempted on boot. Now, because I'm an idiot, I forgot that unraid logs don't persist between reboots and didn't save them before the last reboot and rebuild. (It's been the same error each time, some kind of read error about whichever disk goes down, with the number "2048" in there too.) Since I feel like I can now recreate the issue if I need to - but to also save my drives unecessary stress from more rebuilding if possible - I was hoping for some help on figuring out what might be the likely issue, and some other troubleshooting steps I might be able to take, before I deliberately cause another disabled disk (or two) and generate new logs with the error. My hunch is the H221 is failing, but any ideas or advice would be greatly appreciated.
  9. That's what I had suspected - I saw that I had a few "permissions denied" for creating various folders in the logs, but I couldn't work out why that was. We're talking about a completely default installation, with the same 99/100 user permission choices that your other dockers (which are wonderful, btw) also use. Yet for this one, nope, it just wasn't being allowed until perms.txt was deleted. Odd!
  10. Ah, thank you! I was trying to get the Bedrock docker to work and couldn't work out what I was missing - installing it with default settings would lead to exactly the same behaviour. \security was the only folder being created, and perms.txt and supervisord.log the only files created, and when trying to open the web GUI/attach to the screen using cli I'd just get a "There is no screen to be resumed matching Minecraft" message. Deleting perms.txt and restarting the container fixed it immediately. I thought I was going crazy and missing an obvious first step during initial install, but no matter how much I read and re-read the documentation there didn't seem to be anything about this issue. I'm assuming it's either a bug, or a quirk of how our unraids are set up.
  11. Aha, thanks for the clarification! (And nice one tracking down that SQL corruption bug btw.)
  12. Well funny you should say that... Apologies for bumping an older thread, but I've spent the last hour or so confused as to why I haven't been able to perform one of my regular backups to an encrypted external USB HDD using Unassigned Devices, like I've been doing without hiccups for months. Was confused as to why the log kept spitting out "luksOpen: key file not found" every time I tried to mount the HDD when I knew that Unraid generated a temp keyfile upon array start, but after a little googling and finding this thread I realized what's happening - this is the first time I've tried backup up to this disk since switching to the RC branch a couple of weeks ago. I presume that the solution is that I should manually generate a keyfile containing my array passphrase and place it in /root every time I want to backup for the foreseeable, and then also manually delete that file once the backup is finished? Guess this is one of those bugs (or perhaps better to call it an unintended side effect?) that can come from going with RC...
  13. Wow, somehow I missed that BTRFS actually does this by default in its version of RAID1 with any number of mixed-size drives. Wonderful. Thank you!
  14. Apologies in advance if I've used the terminology in the subject title incorrectly, but I'm creating this post due to my confusion over exactly what might be the solution to my particular query. I have been using Unraid for several months, and found it excellent for my purposes. My setup currently is 2x8TB WD Red drives as parity, and an array of 3x8TB WD Reds plus 1x3TB Seagate ST3000DM001. (I'm aware of the reliability problems that have been reported with this Seagate model, but it yet to give me any issues.) When I first built my system, I used two old 256GB Sandisk SSDs that I salvaged from a couple of old laptops as a mirrored cache; I abhor e-waste, and try to re-use components wherever possible. My issue is that while my 256GB cache pool has served admirably for hosting my appdata, domains, isos, etc, it is far too small when I am often dealing with files which are 50GB+, and as a result for my actual file shares I have been stuck writing directly to the array each time. This is obviously not ideal in terms of speed nor mitigating drive wear, but it is also an issue for me in terms of power consumption (it's rare that more than two HDDs are able to spin down at any one time) and noise (I have a home studio, and can isolate and deal with irregular spin-up/spin-down noise, particularly when not during working hours; the constant low-level hum of multiple HDDs spinning 24/7 is more problematic.) This week I finally upgraded my cache to a single 1TB Samsung EVO, and it's solved those issues for me. However, I again find myself wanting not to waste my two existing 256GB SSDs; they still work fine, after all. I could add them to the array I guess, but they're both so small that seems somewhat ridiculous (not to mention their speeds would be crippled by having to match HDD speeds). I've been trying to educate myself about different RAID configs, and from my research it seems that there are ways of creating a RAID 1 setup from two "disks" where one of the disks is two or more smaller disks in a RAID0 (or is it more accurately called concatenated? JBOD?) setup. My thinking here is instead of buying another 1TB SSD in the near future and regaining mirroring in the pool for redundancy, I could get a 512GB one at some point and stripe it across with the other two SSDs to create something which is treated by the system as one single 1TB drive (give or take the vagaries of how different manufacturers calculate disk size, of course), and then use that as the other half of my cache pool. Is this something that Unraid would support? (Is it even a good idea?) Apologies if this is documented somewhere already, too, but I haven't been able to find anything on this forum or elsewhere that clarifies this. Any advice would be greatly appreciated.