SpyisSandvich

Members
  • Posts

    21
  • Joined

  • Last visited

SpyisSandvich's Achievements

Noob

Noob (1/14)

0

Reputation

  1. EDIT: I've solved this by completely recreating everything, changed owners, and somehow it's working properly now. Couldn't tell you why. Hey all, trying to figure out the permission issue for the `prometheus` image. Marzel's post from 2022 didn't do anything for me. I made a `prometheus.yml` file myself, I assume one would be generated for me if permissions were working. Other than that, it doesn't seem like it can persist anything. Appdata folder is completely owned by `nobody:users` with permissions on `775`. prometheus.log prometheus.yml
  2. Unfortunately your config doesn't really help. What I ultimately did was downgrade my server version to 13.0.0, which seems to be the last good version that continues to work with my current setup. Looks like there was an announcement for this on their main site.
  3. Yeah, I've been running like this since I got it set up. One of the slots is bad, but I've never run into memory capacity issues, so I kinda just left it. I could do some troubleshooting and potentially reconfigure it to see all 4, just haven't seen the need.
  4. Okay, quickly breaking at my 6.9.2 test as I'm immediately seeing a flood of this message in my syslog: I'm going to halt the software regression test because it seems like my system can't handle going back this far. EDIT 2: This is still happening even now that I've gone back to 6.11.5, should I restore from my flash backup, or is this something deep in the system configuration that the flash wouldn't touch? I want to revisit the RAM speed, since I was told previously that might be an issue with servers. This system runs DDR4-2400 with unbuffered ECC. UEFI was already set to use that speed, and from what I gathered for this configuration, this should be okay. I could try bringing the speed down and seeing if that improves stability? EDIT: Downclocking my RAM only seems to have made things worse. My computer gets into this weird loop where it'll spin the fans for a few seconds, then power back down. It'll do this 3 times then stabilize, where I'm assuming it falls back to last good configuration. Even does this when setting the speed back to normal. It will eventually boot though. Attached logs from the 6.9.2 test in case they're helpful. ca-server-diagnostics-20221221-0832.zip
  5. Is there a better way to do this than the built-in Update OS screen? That screen only allows me to go back one version. EDIT: I suppose I can follow this nugget. I'll take a backup of my flash drive first though. EDIT 2: Currently testing unRAID 6.10.3, seemed to take the downgrade just fine. EDIT 3: 6.10.3 crashed last night. Testing 6.9.2 now. If this fails, then that should remove the software as the possible culprit because I should have easily been past this point when it was working well.
  6. There really isn't much here to go off of, it frequently crashes several hours ahead of the last logs. The part that gets me here is that this was stable until I updated unRAID a month or so ago. I realize it's possible that some of the BIOS settings got messed with, but I've been able to confirm that this hasn't happened. I would rather not downgrade my unRAID version, and it would be difficult to switch to comparable hardware I'm currently running. How does one troubleshoot this without any information?
  7. I checked again this morning. Global C-State Control is "Disabled", and Power Supply Idle Control is "Typical Current Idle". Tried with a local syslog server and it didn't capture anything around the time of the last crash (It crashed around 22:30 and the last log message was two hours prior). I also briefly tried remote syslog with a virtual Debian machine, but switched away from it because for most of the 11th, I only ever saw the line that indicated syslogging was started. Should I be mirroring to the flash drive, or should I try the remote solution again? syslog-192.168.2.251.log
  8. Reopening this again, as the hard crashes have started back up with an Unraid update (not sure exactly which but it was good until at the very earliest the beginning of October). I double-checked the UEFI settings and confirmed that the C-States options and RAM speed configurations have not changed.
  9. My Piwigo server stopped working at some point in the last few months. I noticed in the logs that it was complaining about a couple of the config files: /nginx/nginx.conf /nginx/site-confs/default.conf I tried renaming these with the suffix .old and the server started to function again, but it took me to the setup screen and I'm not sure exactly what in the configs was pointing everything to my existing library. Any thoughts? Attached are the current sample configs (.conf) and my old non-working configs (.conf.old) default.conf default.conf.old nginx.conf nginx.conf.old
  10. UPDATE: 4 days 1 hour up and counting. I ended up needing to change both "Power Supply Idle Control" and global C-states, but it appears to be stable now! Thanks for pointing that out! Will do. I was a little thrown since I've run unRAID without issue on this board before when I was running a 1900X, but it makes sense that something may have changed when I upgraded.
  11. Hello I'm experiencing an issue where my server will randomly crash completely. No web UI, no SAMBA, everything hard crashes and the box requires a hard restart. It sounds like a kernel panic but I can't confirm this. At first the server would last between 12-24 hours before crashing, but recently this window has been cut to around 2-6 hours. I was originally under the impression that I had a failing flash drive. Sometimes before it would crash, I would see the "License file not found" error and that the boot USB device had been moved to Unassigned Devices. However, I've already swapped to a brand new drive and have been moving it around to different USB ports and controllers, and this hasn't fixed anything. ca-server-diagnostics-20220915-0935.zip
  12. I'm going to continue to use the server despite the unmountable drive. As long as it's not being mounted and, crucially, I exclude all shares from using that drive, it should be okay, right? Right?
  13. I've updated my previous post, the check finished predictably. In the meantime, what's the risk of running the server provided I don't use the broken drive? The data on there isn't the most critical on my server, but keeping it in Maintenance mode (or off, since I'm still unsure about what to do next) has obvious impacts to usability.
  14. It does give me the option to cancel, so I did. Removed the -n flag and running it again. EDIT 2: The check finished, looks like it didn't find anything. unable to verify superblock, continuing... (this line is continuously expanding with `.` characters) Sorry, could not find valid secondary superblock Exiting now.
  15. I figured as much. I didn't remove the -n flag. Will update when it finally finishes.