Closed TinTin1969 closed 3 years ago
glyph-se
commented
3 years ago Could be the same as we talked about in https://github.com/hassio-addons/addon-unifi/issues/180 . I'm hoping that the soon to be released 0.23 solves this.
You can use the command posted here to see if it is the same problem https://github.com/hassio-addons/addon-unifi/issues/180#issuecomment-814390685
sermayoral
commented
3 years ago Yes, it's the same problem since 0.21.0. Unifi cannot fix this problem. It seems that only happen with 32-bit versions of the Operative System, which is a shame for all Rasbperry users.
Does anybody know a fix (dirty, clean, whichever...) to be able to hold on until a solution is found?
gralin
commented
3 years ago Same problem on 0.23 (RPi 4, Home Assistant OS 32bit). When it's accessible after first start, I tried restoring the controller from backup containing only settings, but still after addon restart I can't access it any more. I guess it's time to (again) restore 0.20.3 which works no problem. If anyone has a workaround or can confirm that running 64bit OS would solve the problem please share.
stocker85
commented
3 years ago Same problem on 0.23 (RPi 4, Home Assistant OS 32bit). When it's accessible after first start, I tried restoring the controller from backup containing only settings, but still after addon restart I can't access it any more. I guess it's time to (again) restore 0.20.3 which works no problem. If anyone has a workaround or can confirm that running 64bit OS would solve the problem please share.
Please try the first dirty fix for 32-bit I posted in the other issue, the problem I think you have is that MMAPv1 storage engine will not free up space after you remove data, so you need to run the pruning script and then repair the DB as that will free up the deleted data. https://github.com/hassio-addons/addon-unifi/issues/180#issuecomment-841446649
gralin
commented
3 years ago @stocker85 thank you, I saw that post about dirty fix and of course tried it but I still couldn't access the UI after restart. Since I reinstalled the addon and configured the controller from scratch, I was expecting the db issue (if that is the reason) to go away but it didn't. I can take another RPi, setup whole HA from scratch, then the addon, and see if that would work, but I would expect reinstalling the addon should be sufficient as it's running inside the container. right?
stocker85
commented
3 years ago @stocker85 thank you, I saw that post about dirty fix and of course tried it but I still couldn't access the UI after restart. Since I reinstalled the addon and configured the controller from scratch, I was expecting the db issue (if that is the reason) to go away but it didn't. I can take another RPi, setup whole HA from scratch, then the addon, and see if that would work, but I would expect reinstalling the addon should be sufficient as it's running inside the container. right?
I unfortunately don't have a RPi I can test on myself. could you possibly check the logs inside the container to see if they changed after the "fix". Looking at the log that was posted in the other issue it failed on memory allocation, which could indicate that the DB size is too big to do whatever memory operation it was doing. but could also be a dodgy RPi... actually I would prefer if people posted their logs because just stating that the error is the same does not really help without looking at the log.. it could be 3 different causes but the same error.
to my knowledge reinstalling the addon should be sufficient to test.
gralin
commented
3 years ago So. When I reinstall the addon, as usual, I can access the GUI. I didn't setup new configuration but simply restarted the addon, and I can't access the GUI any longer. So it doesn't seem to be related to my db data.
This is what I see in /usr/lib/unifi/logs/mongod.log
2021-05-15T00:31:25.722+0200 ***** SERVER RESTARTED *****
2021-05-15T00:31:25.731+0200 [initandlisten] MongoDB starting : pid=5241 port=27117 dbpath=/usr/lib/unifi/data/db 32-bit host=a0d7b954-unifi
2021-05-15T00:31:25.731+0200 [initandlisten]
2021-05-15T00:31:25.731+0200 [initandlisten] ** NOTE: This is a 32 bit MongoDB binary.
2021-05-15T00:31:25.731+0200 [initandlisten] ** 32 bit builds are limited to less than 2GB of data (or less with --journal).
2021-05-15T00:31:25.731+0200 [initandlisten] ** Note that journaling defaults to off for 32 bit and is currently off.
2021-05-15T00:31:25.731+0200 [initandlisten] ** See http://dochub.mongodb.org/core/32bit
2021-05-15T00:31:25.732+0200 [initandlisten]
2021-05-15T00:31:25.732+0200 [initandlisten] db version v2.6.10
2021-05-15T00:31:25.732+0200 [initandlisten] git version: nogitversion
2021-05-15T00:31:25.732+0200 [initandlisten] OpenSSL version: OpenSSL 1.0.2n 7 Dec 2017
2021-05-15T00:31:25.732+0200 [initandlisten] build info: Linux kishi10 3.2.0-84-highbank #121-Ubuntu SMP PREEMPT Tue May 5 19:44:15 UTC 2015 armv7l BOOST_LIB_VERSION=1_58
2021-05-15T00:31:25.732+0200 [initandlisten] allocator: tcmalloc
2021-05-15T00:31:25.732+0200 [initandlisten] options: { net: { bindIp: "127.0.0.1", port: 27117, unixDomainSocket: { pathPrefix: "/usr/lib/unifi/run" } }, processManagement: { pidFilePath: "/usr/lib/unifi/run/mongod.pid" }, storage: { dbPath: "/usr/lib/unifi/data/db", smallFiles: true }, systemLog: { destination: "file", logAppend: true, path: "/usr/lib/unifi/logs/mongod.log" } }
2021-05-15T00:31:25.750+0200 [initandlisten] waiting for connections on port 27117
2021-05-15T00:31:26.180+0200 [initandlisten] connection accepted from 127.0.0.1:51464 #1 (1 connection now open)
2021-05-15T00:31:26.188+0200 [initandlisten] connection accepted from 127.0.0.1:51466 #2 (2 connections now open)
2021-05-15T00:31:26.711+0200 [conn2] SEVERE: Invalid access at address: 0x1502
2021-05-15T00:31:26.715+0200 [conn2] SEVERE: Got signal: 11 (Segmentation fault).
Backtrace:0x7639be 0x762f6e 0x76300a 0xb66cc7d0 0xb666bce6 0xb6ed25e8 0xb6ed2a3e 0xb6ec736a 0xb6ec75e6 0xb6ec65ce 0xb6ec6760 0xb6ec67de 0xb6ec8a56 0xb6ed3a8e
bin/mongod(_ZN5mongo15printStackTraceERSo+0x25) [0x7639be]
bin/mongod() [0x762f6e]
bin/mongod() [0x76300a]
/lib/arm-linux-gnueabihf/libc.so.6(+0x257d0) [0xb66cc7d0]
/usr/lib/arm-linux-gnueabihf/libunwind.so.8(_ULarm_step+0x55) [0xb666bce6]
/usr/lib/arm-linux-gnueabihf/libtcmalloc.so.4(+0x255e8) [0xb6ed25e8]
/usr/lib/arm-linux-gnueabihf/libtcmalloc.so.4(_Z13GetStackTracePPvii+0x25) [0xb6ed2a3e]
/usr/lib/arm-linux-gnueabihf/libtcmalloc.so.4(_ZN8tcmalloc8PageHeap8GrowHeapEj+0xb9) [0xb6ec736a]
/usr/lib/arm-linux-gnueabihf/libtcmalloc.so.4(_ZN8tcmalloc8PageHeap3NewEj+0x79) [0xb6ec75e6]
/usr/lib/arm-linux-gnueabihf/libtcmalloc.so.4(_ZN8tcmalloc15CentralFreeList8PopulateEv+0x71) [0xb6ec65ce]
/usr/lib/arm-linux-gnueabihf/libtcmalloc.so.4(_ZN8tcmalloc15CentralFreeList21FetchFromOneSpansSafeEiPPvS2_+0x1b) [0xb6ec6760]
/usr/lib/arm-linux-gnueabihf/libtcmalloc.so.4(_ZN8tcmalloc15CentralFreeList11RemoveRangeEPPvS2_i+0x6d) [0xb6ec67de]
/usr/lib/arm-linux-gnueabihf/libtcmalloc.so.4(_ZN8tcmalloc11ThreadCache21FetchFromCentralCacheEjj+0x51) [0xb6ec8a56]
/usr/lib/arm-linux-gnueabihf/libtcmalloc.so.4(malloc+0x22d) [0xb6ed3a8e]And it keeps restarting. And here is /run/s6/services/unifi/logs/server.log
root@a0d7b954-unifi:/run/s6/services/unifi/logs# cat server.log
[2021-05-15T00:05:54,663] <localhost-startStop-1> INFO Version - HV000001: Hibernate Validator 6.1.2.Final
[2021-05-15T00:05:55,421] <localhost-startStop-1> INFO system - ======================================================================
[2021-05-15T00:05:55,424] <localhost-startStop-1> INFO system - UniFi 6.2.23 (build atag_6.2.23_15314 - release/release) is started
[2021-05-15T00:05:55,424] <localhost-startStop-1> INFO system - ======================================================================
[2021-05-15T00:05:55,426] <localhost-startStop-1> INFO system - BASE dir:/usr/lib/unifi
[2021-05-15T00:05:55,547] <localhost-startStop-1> INFO system - Current System IP: 172.30.33.1
[2021-05-15T00:05:55,548] <localhost-startStop-1> INFO system - Hostname: a0d7b954-unifi.local.hass.io
[2021-05-15T00:05:55,552] <localhost-startStop-1> INFO system - ubic.env: prod
[2021-05-15T00:05:56,824] <localhost-startStop-1> INFO db - waiting for db connection...
[2021-05-15T00:05:58,731] <db-server> INFO db - 2021-05-15T00:05:58.730+0200
[2021-05-15T00:05:58,732] <db-server> INFO db - 2021-05-15T00:05:58.731+0200 warning: 32-bit servers don't have journaling enabled by default. Please use --journal if you want durability.
[2021-05-15T00:05:58,732] <db-server> INFO db - 2021-05-15T00:05:58.731+0200
[2021-05-15T00:05:58,826] <localhost-startStop-1> INFO db - Connecting to mongodb://localhost:27117
[2021-05-15T00:05:58,977] <db-server> INFO db - DbServer stopped
[2021-05-15T00:05:58,978] <db-server> WARN db - DbServer not shutdown cleanly and need repairing on next startup
[2021-05-15T00:06:09,197] <db-server> INFO db - 2021-05-15T00:06:09.196+0200
[2021-05-15T00:06:09,197] <db-server> INFO db - 2021-05-15T00:06:09.196+0200 warning: 32-bit servers don't have journaling enabled by default. Please use --journal if you want durability.
[2021-05-15T00:06:09,198] <db-server> INFO db - 2021-05-15T00:06:09.196+0200
[2021-05-15T00:06:09,462] <localhost-startStop-1> ERROR db - Got error while connecting to db: null
[2021-05-15T00:06:11,440] <db-server> INFO db - DbServer stopped
[2021-05-15T00:06:11,441] <db-server> WARN db - DbServer not shutdown cleanly and need repairing on next startup
[2021-05-15T00:06:20,152] <db-server> INFO db - 2021-05-15T00:06:20.152+0200
[2021-05-15T00:06:20,152] <db-server> INFO db - 2021-05-15T00:06:20.152+0200 warning: 32-bit servers don't have journaling enabled by default. Please use --journal if you want durability.
[2021-05-15T00:06:20,153] <db-server> INFO db - 2021-05-15T00:06:20.152+0200
[2021-05-15T00:06:20,489] <localhost-startStop-1> ERROR db - Got error while connecting to db: null
[2021-05-15T00:06:21,596] <db-server> INFO db - DbServer stopped
[2021-05-15T00:06:21,597] <db-server> WARN db - DbServer not shutdown cleanly and need repairing on next startup
[2021-05-15T00:06:29,731] <db-server> INFO db - 2021-05-15T00:06:29.730+0200
[2021-05-15T00:06:29,731] <db-server> INFO db - 2021-05-15T00:06:29.731+0200 warning: 32-bit servers don't have journaling enabled by default. Please use --journal if you want durability.
[2021-05-15T00:06:29,731] <db-server> INFO db - 2021-05-15T00:06:29.731+0200
Gazoonky
commented
3 years ago [cont-init.d] 00-banner.sh: exited 0. [cont-init.d] 01-log-level.sh: executing... [cont-init.d] 01-log-level.sh: exited 0. [cont-init.d] unifi.sh: executing... [cont-init.d] unifi.sh: exited 0. [cont-init.d] done. [services.d] starting services [services.d] done. [11:18:13] INFO: Starting the UniFi Controller...
after this unable to connect to gui, just message that the connection refused, presumably the addon isn't starting. Any ideas, can I access previous version and install that>
sermayoral
commented
3 years ago Guys, I have found a way to be able to subsist while a solution is found. I'm going to describe the steps i've followed:
1.- Restore UniFi addon version to 0.20.3 2.- Restart Home Assistant (no host) 3.- Update UniFi addon to the last version from the supervisor menu (now is 0.23)
UniFi controller works in that way, but you cannot reboot the host. If you reboot the host, the addon stucks again and you have to repeat the three steps above.
This way at least allows you to run the latest UniFi version until a definitive solution is found.
Gazoonky
commented
3 years ago How do you install a previous version - I don’t have a full snapshot because they were all overwritten by partial snapshots related to updates. Reinstall and reboot supervisor does get you access to the setup wizard, however as soon as you try to restore from backup you lose access.
OneCyrus
commented
3 years ago it looks like this is an issue with the mongodb version used in this addon. e.g. https://stackoverflow.com/questions/22947465/mongodb-crashed-with-invalid-access-at-address-segmentation-fault-signal-11
also mongodb 2.6 is unsupported. we should move to a newer version. @frenck
sermayoral
commented
3 years ago it looks like this is an issue with the mongodb version used in this addon. e.g. https://stackoverflow.com/questions/22947465/mongodb-crashed-with-invalid-access-at-address-segmentation-fault-signal-11
also mongodb 2.6 is unsupported. we should move to a newer version. @frenck
It has sense!!!
sermayoral
commented
3 years ago How do you install a previous version - I don’t have a full snapshot because they were all overwritten by partial snapshots related to updates. Reinstall and reboot supervisor does get you access to the setup wizard, however as soon as you try to restore from backup you lose access.
Restoring a snapshot. If you dont have a snapshot with the 0.20.3 version you dont have alternative. Sorry
OneCyrus
commented
3 years ago the unifi controller for windows is currently bundled with mongodb version 3.2.20
glyph-se
commented
3 years ago According to the release notes for the UniFi controller 6.2 mongodb up to version 3.6 is supported, this is also the latest version in Ubuntu 18.04
pascalkrielen
commented
3 years ago My result is below, upgrade from 0.22 to 0.23.. Restoring 0.22 snapshot makes it work again, update to 0.23 gives back error directly after restarting add-on: _
[10:10:19] INFO: Starting the UniFi Controller... Exception in thread "launcher" java.lang.IllegalStateException: Tomcat failed to start up at com.ubnt.net.B.ö00000(Unknown Source) at com.ubnt.service.C.Óo0000(Unknown Source) at com.ubnt.ace.Launcher.main(Unknown Source) Caused by: java.lang.RuntimeException: Web context failed to initialize ... 3 more_
cromulus
commented
3 years ago I am getting the same tomcat error as @pascalkrielen
just updated to the latest version.
glyph-se
commented
3 years ago Yes, it's the same problem since 0.21.0. Unifi cannot fix this problem. It seems that only happen with 32-bit versions of the Operative System, which is a shame for all Rasbperry users.
Does anybody know a fix (dirty, clean, whichever...) to be able to hold on until a solution is found?
I changed my raspberry pi 3 32-bit to a raspberry pi 4 64-bit and it works for me now.
sermayoral
commented
3 years ago According to the release notes for the UniFi controller 6.2 mongodb up to version 3.6 is supported, this is also the latest version in Ubuntu 18.04
So, the only thing it can be done is to update the mongodb-server library to a 3.6 version? Do you know what is the exact release?
TinTin1969
commented
3 years ago Ok here is the strangest thing... Today for some reason I thought I'd give it a try to access the WebUI and out of the blue it worked. Nothing had changed, I'm still running 0.23 which I had never been able to access. And suddenly it works perfectly! I made some Ha backups (running Home Assistant in RPi 3) and Controller backups to make sure I won't get locked out again.
One reboot of the RPi and the WebUI is gone again, same Connection Refused error. Tried reinstalling Add-on, restoring from backup, etc. Doesn't work anymore...
So I really don't believe it has anything to do with database version etc, it must be some kind of port or SSL error, no idea.
Also, the controller is clearly up and running as there are functions like guest network configuration, which I wouldn't be able to have without a controller. So it is simply an WebUI access problem.
TinTin1969
commented
3 years ago After a lot of fiddling, I think I've figured out a solution to my problem:
When the Raspberry Pi reboots, the Unifi add-on is not accessible. However, if you then reboot only the core (Supervisor, restart core) in Home Assistant, the Unifi WebUI suddenly becomes accessible and works normally.
iZac85
commented
3 years ago After a lot of fiddling, I think I've figured out a solution to my problem:
When the Raspberry Pi reboots, the Unifi add-on is not accessible. However, if you then reboot only the core (Supervisor, restart core) in Home Assistant, the Unifi WebUI suddenly becomes accessible and works normally.
I tried this but it doesn't work for me. But maybe I'm having another issue as I also see this I my Home assistant log (
Error connecting to the UniFi controller at <IPxxx.xxx.x.xx>: Error requesting data from <IPxxx.xxx.x.xx>: Cannot connect to host <IPxxx.xxx.x.xx>:8443 ssl:default [Connect call failed ('<IPxxx.xxx.x.xx>', 8443)]
So it seems like it's not only a WEB UI issue for me but also an issue with the unifi controller not running at all... But the unifi-addon is using around 10-20% CPU so something is happening there..
cromulus
commented
3 years ago I think this is the same underlying problem as these other issues: #188 #206
The underlying problem, as far as I can tell, is with 32 bit installs on armv7 processors (RPI4)
If you run the command arch in an ssh shell, and you see armv7l , AND version 0.23.0 of the unifi addon works, then it's something else.
iZac85
commented
3 years ago I think this is the same underlying problem as these other issues: #188 #206
The underlying problem, as far as I can tell, is with 32 bit installs on armv7 processors (RPI4)
If you run the command
archin an ssh shell, and you see armv7l , AND version 0.23.0 of the unifi addon works, then it's something else.😞 Is there any known fix/workaround for the 32bit issue?
arch returns armv7l
nkm8
commented
3 years ago I am running aarch64 on a pi4 and ran into this same issue. The only withstood l workaround I found was to downgrade to 0.22.0
sermayoral
commented
3 years ago iZac85
commented
3 years ago I managed to work around this issue by installing UniFi AddOn version 0.20.3, by following the steps described here. E.g. what I did was:
Step 5 actually took me a while since all my backups included history data as well and restoring those on the Addon still seems to not work (reported issue here). So I had to follow these steps to set up the controller (version 6.0.45) on my laptop, restore the backup there and create a new backup with settings only which I finally could restore in the Addon!
sermayoral
commented
3 years ago Guys, I guess no, but has someone checked if this issue is fixed in 0.23.1?
pascalkrielen
commented
3 years ago Guys, I guess no, but has someone checked if this issue is fixed in 0.23.1?
I did 2 things, upgrade my Rpi4 to x64 and the plugin to 0.23.1 and now it is working fine...
johanostensson
commented
3 years ago Guys, I guess no, but has someone checked if this issue is fixed in 0.23.1?
It did not solve the issue for me on 32b Pi.
sermayoral
commented
3 years ago Guys, I guess no, but has someone checked if this issue is fixed in 0.23.1?
It did not solve the issue for me on 32b Pi.
I supposed. It seems that as long as MongoDB is not updated, the error will persist :-(
sinclairpaul
commented
3 years ago I supposed. It seems that as long as MongoDB is not updated, the error will persist :-(
MongoDB dropped 32 bit support a long time ago, I believe the version running in the addon is the latest that will support armv7. My suggestion would be move to a 64 bit OS version.
sermayoral
commented
3 years ago I supposed. It seems that as long as MongoDB is not updated, the error will persist :-(
MongoDB dropped 32 bit support a long time ago, I believe the version running in the addon is the latest that will support armv7. My suggestion would be move to a 64 bit OS version.
It depends on the raspberry pi os 64 bit development ☺️.
I suppose i will remain in 0.20.3 until the rpios64 is ready. Thanks anyway
sinclairpaul
commented
3 years ago I suppose i will remain in 0.20.3 until the rpios64 is ready. Thanks anyway
The HA OS supports 64 Bit, and afaik you can run Debian 10 on a Pi. Any other OS is likely to fall under the unsupported category....
iZac85
commented
3 years ago I suppose i will remain in 0.20.3 until the rpios64 is ready. Thanks anyway
The HA OS supports 64 Bit, and afaik you can run Debian 10 on a Pi. Any other OS is likely to fall under the unsupported category....
Are you running RaspberryPi OS 64bit without any issues?
sermayoral
commented
3 years ago I suppose i will remain in 0.20.3 until the rpios64 is ready. Thanks anyway
The HA OS supports 64 Bit, and afaik you can run Debian 10 on a Pi. Any other OS is likely to fall under the unsupported category....
I strongly need the gpios, and they don't work in debian/hassos 64. I have to wait until raspios64 is ready.
github-actions[bot]
commented
3 years ago There hasn't been any activity on this issue recently, so we clean up some of the older and inactive issues. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thanks!
sermayoral
commented
3 years ago This issue persists in 32 bit architectures
frenck
commented
3 years ago It happens on some 32 bits architectures, unfortunately, there is not much to do about it.
I've marked 32-bits system now officially deprecated in 0.23.2, and officially removing support for them completely in the upcoming release.
For more information see:
https://github.com/hassio-addons/addon-unifi/releases/tag/v0.23.2
BitTourette
commented
3 years ago It is not only 32 bit. I have the latest 64 bit hassio image on the raspberry 3B+ and after I start the Image the whole homeassistant freeze until I reboot with UniFi autostart disabled
frenck
commented
3 years ago the whole homeassistant freeze
That sounds like you are pushing your device to the memory limits. As add-on cannot effect Home Assistant itself otherwise. Its a Raspberry Pi 3, it has only 1Gb of memory. This is not an add-on issue.
sermayoral
commented
3 years ago It happens on some 32 bits architectures, unfortunately, there is not much to do about it.
I've marked 32-bits system now officially deprecated in 0.23.2, and officially removing support for them completely in the upcoming release.
For more information see:
https://github.com/hassio-addons/addon-unifi/releases/tag/v0.23.2
I hope Raspberry Pi OS 64 is ready soon, and there the GPIOs working in the HassOS 64 :-)
frenck
commented
3 years ago GPIO should be working in HassOS. I'm not sure how Raspberry Pi OS 64 and HAssOS are related in that one sentence, those are different things and do not go along together. That said, personally, I don't believe in using GPIO on a Pi in this setting, in almost every case one gets better and more stable results using an ESP32 chip with ESPHome for GPIO needs.
But that is of course an unrelated discussion for this issue and add-on.
sermayoral
commented
3 years ago If the Raspberry developer team get GPIOs working in the 64 bit arch, probably it would be working in HassOS 64 soon.
As I intended, Raspberry Pi GPIOs are not working in HassOS 64, if it has changed, i'm not aware.
I use the rpi gpios for things such as rebooting my router when HA detects connection problems. This approach is working perfectly, and the rpi can do it independent of router or access point. An ESP32 need a wireless connection to communicate with the rpi, which may not exist or be not working properly. This approach doen't even need the router to be working properly to perform the reboot.
Among other things, but I appreciate your advice and opinion on this :-)
cromulus
commented
3 years ago Could use an esphome device over the usb serial connection. No WiFi needed!
Cheers, Bill - sent on the move.
(he, his, him)
On Jul 16, 2021, at 8:53 AM, Sergio Mayoral Martínez @.***> wrote:
If the Raspberry developer team get GPIOs working in the 64 bit arch, probably it would be working in HassOS 64 soon.
As I intended, Raspberry Pi GPIOs are not working in HassOS 64, if it has changed, i'm not aware.
I use the rpi gpios for things such as rebooting my router when HA detects connection problems. This approach is working perfectly, and the rpi can do it independent of router or access point. An ESP32 need a wireless connection to communicate with the rpi, which may not exist or be not working properly. This approach doen't even need the router to be working properly to perform the reboot.
Among other things, but I appreciate your advice and opinion on this :-)
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
sermayoral
commented
3 years ago @cromulus how can i do that? The Home Assistant ESPHome integration ask me for an IP. No usb serial connection option appears
cromulus
commented
3 years ago glyph-se
commented
3 years ago It happens on some 32 bits architectures, unfortunately, there is not much to do about it.
I've marked 32-bits system now officially deprecated in 0.23.2, and officially removing support for them completely in the upcoming release.
For more information see:
https://github.com/hassio-addons/addon-unifi/releases/tag/v0.23.2
I think is the right way to go. Maybe also add something about 0.20.3 being the last version that worked fine on Raspberry 32-bit?
collse
commented
3 years ago same issue here and none of my backups allow me to revert back either and its not a 32bit platform
[cont-init.d] 00-banner.sh: exited 0. [cont-init.d] 01-log-level.sh: executing... [cont-init.d] 01-log-level.sh: exited 0. [cont-init.d] unifi.sh: executing... Importing keystore /tmp/tmp.2qcExhqnVN to /usr/lib/unifi/data/keystore... Warning: The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore /usr/lib/unifi/data/keystore -destkeystore /usr/lib/unifi/data/keystore -deststoretype pkcs12". [cont-init.d] unifi.sh: exited 0. [cont-init.d] done. [services.d] starting services [services.d] done. [21:20:46] INFO: Starting the UniFi Controller...
////// a.b.c.d:8443 doesn't seem to be a TLS/SSL enabled server Service detected: Couldn't determine what's running on port 8443, assuming no HTTP service => skipping all HTTP checks
Testing protocols via sockets except NPN+ALPN
SSLv2 not offered (OK) SSLv3 not offered (OK) TLS 1 not offered TLS 1.1 not offered TLS 1.2 not offered TLS 1.3 not offered
/// trying to start it from within the container gives it a lifetime of probably 1sec so I guess the service terminates while the supervisor believes all is well still .... logs dont update, even a trace seems like its responding while reading the options and thats it ...
further tests show the mongodb isnt starting so I assume this being a dependency for the unifi server - unfortunately I cant find any indicators ...
collse
commented
3 years ago ok after a few further tests and a hint this procedure does seem to work:
uninstall the current version, re-install the latest version - DONT start it - disable SSL - start the addon. Next connect via http://a.b.c.d:8080 - you will see the controller interface allowing you to import your previous configuration. Once this completes the controller is working and using the default unifi ssl certificate.
as soon as you try to use your own SSL certificates it will break again and can be recovered as explained above.
Problem/Motivation
Expected behavior
Actual behavior