Orpheus123
-
Posts
21 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by Orpheus123
-
-
Updated to the new version of the container and the errors are gone. Successfully ran my first scan. Thanks for the fix.
-
5 hours ago, jbreed said:
For a temporary fix, I posted the commands to resolve this. I'll be pushing an update soon to resolve this without needing to console into the container and will also keep everything up to date without having to re-compile the image.
Thanks!
Thanks for the quick response. I will try the commands after work tonight.
-
On 4/23/2020 at 11:03 PM, westsola said:
Thanks OP for creating this. I just installed it to test it.. and encountered a couple of error messages. Hopefully they are helpful for your troubleshooting.
Upon initial login/setup of user account, I receive the following error when trying to start a scan.
Then upon logging in again I get this error
Just installed and encountered the same errors. Are there some settings to change in the docker? Other suggestions to debug?
-
On 5/12/2019 at 12:07 PM, niwmik said:
I had to replace my cache drive and recreate my docker.img. I restored my appdata using CA Appdata Backup / Restore v2 and installed Unifi-Controller LTS. Everything was working perfect before but the issue now is I can see my devices in the Unifi Controller but I can't see any clients.
The next step I took was to download a backup file from Unifi Controller. I then remove the existing docker and deleted the appdata/unifi folder and created a new docker and restored from the backup file. I had the same results of seeing devices but not clients.
Only thing I see different is that the current LTS is 5.6.42 and my backups are from 5.6.40. Not sure if that makes a difference. Any ideas as why I'm not seeing clients?
Thanks for posting this. I had the same issue. In the old docker, I was running Unifi Controller version 5.6.40. Before upgrading to the new docker, I backed up my appdata and also downloaded a backup of the controller settings from Settings/Maintenance in the Unifi Controller.
When I installed the LTS branch of the new docker, it installed Unifi Controller version 5.6.42. I followed the directions at the beginning of the thread and used the old appdata folder. All the APs connected and were working, but nothing was shown in the client list.
I tried restoring the backup of the 5.6.40 settings in the 5.6.42 controller, but that did not fix the missing client list and now the UI incorrectly showed the APs as disabled (even though they were still working).
So, I installed the new docker again, this time choosing the 5.9 branch and created a brand new appdata folder. Then, I restored the backup of my 5.6.40 controller settings. The APs and client list are now working and shown correctly in the UI.
-
Thanks, followed the instructions and cleared out a 3.7GB JSON log built up by CouchPotato.
-
Great price. Can anyone comment how well these cards work with unRAID? This thread about makes me concerned:
https://lime-technology.com/forum/index.php?topic=38071.0
-
Is the NZBGet plugin for v5 still available? It seems to be deleted from Github. I am not ready to move to v6 yet, and really wanted to install NZBGet on v5.
-
Thanks, I went ahead and ordered the SSD.
Glad you mentioned brtfs in 6.0 beta. I have not been following all the 6.0 threads. I did a quick search and seems with brtfs I can mount the SSD with -o discard or periodically run fstrim.
-
Yes, that is my concern.
I don't have room in the case for separate apps and cache drives, so using an SSD for an apps drive with ext4 and TRIM enabled is not an option.
-
Bump. No one using an SSD for their cache drive and running Plex on it?
-
I am thinking about replacing my cache drive with an SSD (probably the Crucial MX100 256GB). I know that unRAID does not support TRIM so the drive must rely on built-in garbage collection by the SSD. I use the cache drive for apps including Plex.
For those using an SSD for the cache drive, does Plex allow GC to work? My current mechanical cache drive rarely (if ever) spins down, and this seems to be due to Plex. GC requires the SSD to be idle for a good period of time?
-
First of all, thank you to the OP and other posters for the hard work on this thread.
I need to setup a Lenovo ThinkServer TS440 for unRAID. It has a Raid 500 card which is a rebranded LSI 9240-8i using the LSI SAS2008 chipset. I need to flash it to IT mode. A few questions:
1. Is the zip file for SAS2008 on the first page still current?
2. Do I use the P7 version of the firmware from the zip file (because the card is re-branded) or the latest 9211 firmware from LSI? P19 seems to be the latest.
3. I am concerned about getting the PAL error because I don't think the TS440 has a boot to EFI shell option. What is the easiest solution? Put the card into another motherboard to do the flash?
Any other advice would be appreciated. It is my first time doing this.
-
Just checked. The motherboard was running v904 bios. I will run memtest overnight to make sure the memory is ok.
-
Thanks. I went ahead and bought the Asus H87m-e and the G3220. I installed it last night and unRAID seems to run well. However, the syslog had several Machine Check Errors like this today:
Mar 31 06:55:50 helios kernel: mdcmd (35): spindown 0 (Routine)
Mar 31 06:55:50 helios kernel: mdcmd (36): spindown 1 (Routine)
Mar 31 07:25:51 helios kernel: mdcmd (37): spindown 0 (Routine)
Mar 31 07:25:51 helios kernel: mdcmd (38): spindown 1 (Routine)
Mar 31 07:27:42 helios kernel: mce: [Hardware Error]: Machine check events logged (Errors)
Mar 31 07:33:34 helios kernel: mce: [Hardware Error]: Machine check events logged (Errors)
Should I be concerned? I found this thread: http://lime-technology.com/forum/index.php?topic=32314.0 which suggests it is a problem with the unRAID 5.05 kernel, but it would be good to get confirmation. I have a very short time in which I can RMA the motherboard or CPU.
-
Good catch. Given that, I'd either use the AsRock B85M-Pro4 or the slightly more costly Asus H87M that I initially suggested (a decidedly better board than the lower-cost units).
Thanks for the help. In terms of chipset features, I googled a bit about B85 vs. H87. Other than 6 SATA 3 ports with H87 (vs. 4 SATA 3 and 2 SATA 2 with B85) I didn't see any differences that would be an advantage when running unRAID. Did I miss anything important about H87? Even with no extra features, I may likely get the Asus H87M just for quality reasons.
In future, I might upgrade the G3220 an i5 when they become inexpensive but this seems fine with either board.
-
Orpheus123 ---- Double check that the NIC on these boards are supported in unRAID. I seem to recall that people have had problems with Atheros NIC's.
Thanks for catching this. It is hard to tell from Hardware Compatibility page whether Atheros is supported or not, but I found this recent thread where a user reports the Atheros AR8171 on the ASRock B85M does not work with unRAID.
http://lime-technology.com/forum/index.php?topic=31333.0
If I rule out motherboards with Atheros, that leaves:
ASRock B85M-Pro4
Gigabyte GA-B85M-HD3
Asus B85M-G
-
Ok. I have been wondering about any of these mATX boards with 6 SATA ports. I have only ever owned Asus motherboards so don't really know ASRock or which of these might have issues with unRAID.
ASRock B85M-GL ($65 CDN after rebate)
http://www.newegg.ca/Product/Product.aspx?Item=N82E16813157375
- Atheros LAN, 6 SATA ports, 1 x PCIe x16, 1 x PCIe x1, 1 x PCI
ASRock B85M-Pro4 ($75 CDN after rebate)
http://www.newegg.ca/Product/Product.aspx?Item=N82E16813157388
- Intel LAN, 6 SATA ports, 2 x PCIe x16
Gigabyte GA-B85M-HD3 $75 CDN
http://www.newegg.ca/Product/Product.aspx?Item=N82E16813128608
- Realtek LAN, 6 SATA ports, 1 x PCIe x16, 2 x PCIe x1, 1 x PCI
ASRock H87M ($85 CDN after rebate)
- Atheros LAN, 6 SATA ports, 2 x PCIe x16
Asus B85M-G ($89 CDN)
http://www.newegg.ca/Product/Product.aspx?Item=N82E16813131986
- Realtek LAN, 6 SATA ports, 1 x PCIe x16, 2 x PCIe x1, 4 DIMM slots, some other features (useful?)
-
I need some recommendations for an LGA 1150 motherboard that will work well with unRAID.
Would like to spend $50 - $80 on the motherboard. Will be using a G3220 CPU
-
Never mind, solved it.
Turned out that the couchpotato_v2.cfg file had become corrupted somehow.
Instead of the following 2 lines:
INSTALLURL="https://github.com/RuudBurger/CouchPotatoServer"
BRANCH="master"
I suddenly had:
INSTALLURL="master"
BRANCH=""
I've seen something similar happen to the config for these plugins before. It seems to write the value for each setting into the setting above the setting it should be written into sometimes. I have NO idea why that happens, or how, but it does.
Just had this problem. After rebooting, the array would not start because of CouchPotato. Found this thread and sure enough INSTALLURL and BRANCH had somehow become corrupted in couchpotato_v2.cfg.
[Support] Linuxserver.io - Unifi-Controller
in Docker Containers
Posted
I just went through this process to upgrade from LTS (5.6) to 5.14 and wanted to share my experience.
One gotcha I ran into is that 5.10.24 supports device firmware 4.0.9 or later only. My APs (a mix of AP-AC-LR and AP-AC-Pro) were all on firmware 3.9.xxx. After upgrading the container to 5.10, the controller was unable to show any information about these APs. Even worse, 5.10 is unable to upgrade 3.9 devices, and it migrates the Unifi database in appdata to a new format. So you can't update the firmware or roll back easily to 5.6.
I could have updated the firmware on my AP's by SSH into each AP, but I didn't want to risk running into any more gotchas and problems from Ubiquity. I had made a backup of my appdata before moving to 5.10 and I restored it. It is the first time I have ever needed to restore the appdata in many years of running unRAID, but I am very appreciative of the developers of Community Applications Backup / Restore Appdata plugin. After restoring the original appdata, I changed the container back to 5.6 and used the 5.6 controller to upgrde the device firmware on the APs.
I was not sure what firmware version was best to move to on the APs. I went with 4.0.80 based on several comments in Ubiquity forums, but many also seem to like 4.3.20. Might need to revisit this again.
Once the firmware was updated, the migration to 5.10 and then to 5.14 went smoothly, and the APs appear to be working well.