thither
Members
-
Joined
-
Last visited
-
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.
-
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?
-
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.
-
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
-
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...
-
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.
-
thither changed their profile photo
-
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.
-
Just wanted to say thanks for the instructions, this has been working great for me!
-
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!
-
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?
-
Ah, right. Well I just wanted to see whether I could get any data off of it at all, but it seemed to be totally unresponsive. I've got ddrescue running right now on disk2 (current remaining time: 222d 15h, though I'm hopeful that will improve). Am I correct in saying that at this point my existing parity drive isn't useful any more, since it's been trying to check two faulty drives at once and whatever parity information is on it is unreliable now? So my best course of action is just to recover as much stuff as I can from disk2 and then recompute parity from scratch with whatever recovered data I can get off of it?
-
As a brief update, I removed disk3 (the disabled one) from the array and tried to add it back in to rebuild, but it started throwing SMART errors, and then finally wouldn't mount at all. xfs_repair told me to run it again with -L, which I may try to do, but in theory everything in there should be rebuildable from parity, so I'll likely just get rid of the disk. I'll be trying a ddrescue from disk2 to the new disk as soon as the new disk's extended SMART test is complete.
-
Thanks for the link to ddrescue. So If I'm understanding correctly, my next steps would be: install a new disk as disk5 try to ddrescue as much stuff as I can from disk2 to disk5 remove disk2 from the array, add disk5 Rebuild parity based on the recovered data, probably with some data loss Is there any chance of un-disabling disk3? Should I just uninstall the disk and trash it?
-
Ok, so The disk2 and disk3 reports completed. disk3, the disabled one, shows the test completing without error in that same section of the report: SMART Extended Self-test Log Version: 1 (1 sectors) Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed without error 00% 21383 - # 2 Short offline Completed without error 00% 21365 - # 3 Short offline Completed without error 00% 21328 - disk2, which is doomed, shows 4218 errors (and unraid shows the test as "completed: read failure"). SMART Extended Self-test Log Version: 1 (1 sectors) Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 90% 46611 43138432 # 2 Extended offline Completed: read failure 90% 46566 3145072 # 3 Short offline Completed without error 00% 46557 - So it looks like only disk2 fails the SMART tests, and if I'm lucky I'll be able to swap it out and rebuild from parity. One thing I still don't understand is how I can get disk3 back into the array. Just starting the array doesn't seem to do it. Do I need to erase the disk or something? Remove it from the array and re-add it? Will a cold reboot do it? (I've rebooted, but haven't turned the power all the way off.) Relatedly, I would think it would be best to get disk3 back online before I swap out disk2 for a fresh drive, but is that the wrong order to do it in? I would think that as long as disk2 is unreliable, the system as a whole wouldn't be able to reliably compute the parity. disk3-eurydice-smart-20220225-0900.zip disk2-eurydice-smart-20220225-0038.zip
-
Thanks for taking a look. I've got SMART tests running on disk2 and disk3 and will post them once they're done. The disk1 test finished and reported a passing test, as far as I can make out from the logs ("SMART overall-health self-assessment test result: PASSED"), but I'm not super familiar with what I should be looking for in there. disk1-eurydice-smart-20220224-2352.zip
