thither

Members
 View Profile  See their activity

  • Posts

    51

  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

thither's Achievements

Rookie

Rookie (2/14)

2

Reputation

1

Community Answers

  1. thither
    As a historical note, I downgraded back to 6.11.5 and have had 7 days of uninterrupted uptime since then.
  2. thither
    Answering my own question about the docker images, what I did was to use "Add Container" from the docker page for every image I wanted to add, then under "templates" I selected the template from the "users" section, created new containers with names in the form "sonarr-6-11", and set them to autostart instead of the old ones. The "add container" form had all the right data prepopulated correctly and so far everything has worked without a hitch.
  3. thither started following Most docker apps not starting after downgrade from 6.12 to 6.11, "Unknown subsys name 'elogind'"
  4. thither
    Hi. Unraid 6.12 has been nothing but frustration for me, and after enduring several weeks of needing to power-cycle it once a day I've downgraded my server back down to 6.11.5. Some of the stuff I use unraid for is still working fine, notably the SMB shares and my Plex and Calibre docker images, but the majority of my docker images won't start; trying to run them from the docker panel gives me an error message "Execution error - Server error". (These were all working fine in 6.12.) I get this block of logs in the unRaid logs when this happens: Jan 24 10:48:33 Eurydice kernel: docker0: port 3(vethc95c9cf) entered blocking state Jan 24 10:48:33 Eurydice kernel: docker0: port 3(vethc95c9cf) entered disabled state Jan 24 10:48:33 Eurydice kernel: device vethc95c9cf entered promiscuous mode Jan 24 10:48:33 Eurydice kernel: docker0: port 3(vethc95c9cf) entered blocking state Jan 24 10:48:33 Eurydice kernel: docker0: port 3(vethc95c9cf) entered forwarding state Jan 24 10:48:33 Eurydice kernel: docker0: port 3(vethc95c9cf) entered disabled state Jan 24 10:48:33 Eurydice kernel: cgroup: Unknown subsys name 'elogind' Jan 24 10:48:33 Eurydice kernel: docker0: port 3(vethc95c9cf) entered disabled state Jan 24 10:48:33 Eurydice kernel: device vethc95c9cf left promiscuous mode Jan 24 10:48:33 Eurydice kernel: docker0: port 3(vethc95c9cf) entered disabled state I'm not really sure what do here, the elogind error doesn't kick up anything for me in a web search. Should I uninstall and reinstall these images? Fix Common Problems also gives me a warning about a docker patch that I need to download, but I can't download it, because Fix Common Problems sends me to the Community Apps page, which tells me I need to download 6.12 before I use it. Is there anywhere I can manually download and apply this patch?
  5. thither
    Sorry to piggyback on the thread, but is there any solution for re-downloading the 6.11 version of community applications? I've also downgraded from 6.12 back to 6.11 (to fix some server crashes that started during 6.12) and I'm seeing the same thing.
  6. thither
    Thinking about this a little more, the weird thing is that it seems like something is just eating up all the CPU, whereas I would expect a hardware fault to result in a kernel panic or something. Is there something I can run that will give me a graph or log of historical CPU load, or maybe load per docker container or something?
  7. thither
    I'm not running NFS, no. Actually I just downgraded back to 6.12.4 and while the system was stable for longer, it's now frozen up again. I'm guessing this points to some kind of hardware fault in my server, which just happened to rear its head after the upgrade.
  8. thither
    Well, the system froze again and I restarted it. Here's my syslog and syslog-previous from the flash drive. I restarted at around 4:00am, and then again this morning at 10:30. I personally can't see much suspicious here, I have community apps set to auto-update nightly and that runs. It does seem a little weird that the system boots at 4:08 and the "Unraid API started" message doesn't appear until 7:30, but I don't know how normal that is. Anyways, I'm going to roll back to 6.12.4 and will report back on whether that seems more stable. syslog.txt syslog-previous.txt
  9. thither
    Thanks! I ran memtest off the boot drive and it seemed to freeze after printing "Loading memtest... ok". I'll poke around to see what that's about; I don't see my exact motherboard listed here but there are some very similar ones that seem to have issues. Copying the 6.12.4 files into a "previously" folder did give me an option to rollback through the web GUI again, but I'm going to hold off to see if I can get useful syslog info out of the current distribution before I do so. If I do roll back, I assume it will still use my old configs, right? (So I won't need to set up my dockers and array again?)
  10. thither started following Server freezes in 6.12.6 - not macvlan or realtek related
  11. thither
    I'm seeing server crashes roughly once a day after going from 6.12.4 to 6.12.6. My symptoms are exactly the same as in this bug report: I can ping the machine and the console is responsive, but when I try to log in it just freezes after I enter the username. I get "504 Gateway Time-out" nginx errors on the web interface, and none of the dockers are responsive. Diagnostics attached. As far as I can tell I don't have realtek or adaptec hardware. My docker is running ipvlan, not macvlan (it was set to that in 6.12.4 already, and was working fine). (Edit to add: I don't have any VMs running, unlike in the above bug report, and "Fix common problems" doesn't show anything except a warning about syslog being mirrored to flash.) I set syslog to mirror to a cache directory, but I don't see any logs there. I've just checked the box to get it to mirror to flash, so if it happens again hopefully I'll have something useful (but I haven't see anything relevant in the logs I've looked at in the past, it just looks as if the server is working normally). I have some other very odd and vexing behavior which started happening at the time I upgraded, too, but it's all at the BIOS level, so it kind of seems impossible that the upgrade would have caused it. The first time the server went down, after I restarted the BIOS wouldn't recognize my flash drive as a bootable device (it just didn't appear in the menus at all). The drive was attached to an internal USB header. Eventually I reinstalled from an online backup onto a new thumb drive, re-registered it (blacklisting the old drive), and was able to boot from it. Things were working fine, but when the server went down again and I had to cold-restart it, the new thumb drive wasn't available as a bootable device. Through trial and error, and an eventual CMOS reset, I discovered that after rebooting the server I need to physically unplug the USB drive and plug it back in in order for it to be recognized and bootable. I have no idea what that's about. It's happening before the OS loads, so it doesn't seem possible that Unraid could be affecting it. I did verify that I'm running the latest firmware for my motherboard (an ASRock z170 Extreme 7+). I haven't seen this behavior before but I also have rarely needed to cold-boot my server in the past. At this point I'd like to roll back to Unraid 6.12.4, since it didn't have these issues, but since I'm on a new USB stick, I don't have the option to just roll back to it from Tools / Update OS. Are there files I can copy from the old USB stick to the new one that will let me do that? Or is there some other way to downgrade? eurydice-diagnostics-20240101-0940.zip
  12. thither
    It seems that the nzbget developers have gotten tired of working on it and archived all the github repos, so I'm guessing fixes for the VideoSort thing aren't likely from upstream (mine seems to have broken again, personally). Guess it's time to look into SABnzbd again...
  13. thither
    I can confirm that 6.5.0 is broken for me with the same error, and rolling back to 6.4.0 fixed it. Don't see anything obvious about this on the linuxserver.io github page.
  14. thither
    thither changed their profile photo
  15. thither
    I've noticed similar behavior where my unRaid (6.10.3) box will periodically seem to drop all inbound network traffic. This happens once every few weeks. Plugging in a monitor to it, I see the console still prompting me for a login, no kernel panic message or similar. (I wasn't able to hook up a keyboard to log in at the console, long story, and have wound up just cutting the power, though now I have a new keyboard ready for next time.) Weirdly, although inbound connections fail (HTTP to the web console / docker ports, SMB connections to shares, ICMP ECHO pings), from looking at my NZBGet history, it appears as though outbound traffic is still working - I see downloads that completed successfully during the time that I could not ping the box. I have just enabled syslog and will report back here with logs if I see the problem reoccurring. Edit to add that this is on a regular old Intel PC, I'm not running QNAP hardware.
  16. thither
    Just wanted to say thanks for the instructions, this has been working great for me!
  17. thither started following Soulseek Dockers
  18. thither
    Ok, well after a good deal of messing around I created a new config and am rebuilding parity now. I definitely lost a bunch of data, and without disk3 being readable it's a little hard to say what exactly went away, but the system is stable again and I definitely learned something through this whole process. Thanks very much for helping me out with this @JorgeB!
  19. thither
    Sorry about that. I first got a notification that disk3 was out on 2022-01-15, and I definitely didn't intentionally write anything to the disk after that. Most of the data going into the array since that time would be automatic downloads (from Sonarr etc) which are not super important and could be redownloaded if needed. After running for quite a while, ddrescue from disk2 to my new replacement for it succeeded, rescuing 99.99% of the data, and after running a xfs_repair on the replacement it mounts fine, with just a few random files (6GB or so) winding up in lost+found. Do you think it would be worthwhile to try to add in this replacement disk back into the array as disk2, and then once it's in there to try to rebuild my replacement for disk3 from parity, or would I just be risking 6GB or more of corrupt data on the replacement (since that would be changed on disk2 since parity was computed)? Or should I just start over with a new config and live without whatever was on disk3?