FTL Crashes if FTLCONF_webserver_api_password has a value set #2242
Comments
|
crash log |
|
Might be fixed by #2240 |
|
Same issue on It's not crashing, but UI isn't asking for password event if it was set before migration to v6 |
|
Please try again after running to get the latest bug fixing attempts for this problem. The issue here is that your VMs somehow do not provide cryptographically sound randomness and we need find out why. |
|
I have the same issue with my installation in a Synology DS415+. If I configure my docker with a blank password I was able to open the admin page. |
|
@DL6ER thanks, tried, but it's not working on Docker also tried |
|
If your are on docker, you need to build the image yourself. https://github.com/pi-hole/docker-pi-hole?tab=readme-ov-file#building-the-image-locally
|
|
While I think it's within my capabilities to build locally, I'm not sure how to use a local image with my pihole container project, and deploy it reliably within my environment. |
|
If you use the build script, it will create an image tagged You can simply change one line in your docker compose file to load this instead of the one from dockers repository. |
where does the image live? just put it in the docker/pihole directory? |
|
I did grab the latest Docker tag this morning but it still crashes FTL if I set a password in the docker container script, doesn't generate its own password if I don't and runs no password in that situation. Looks like the latest docker image is still behind Core version. |
It lives in your local host's repo rigth on your own machine. |
Just tagged a new one now, should be about 10 mins. I didn't tag before because there wasn't anything massively relevant to docker in the core hotfix.
If you just run |
|
I just tried with 2025.02.5 and it still doesn't work.
Il giorno lun 24 feb 2025 alle ore 16:13 Adam Warner <
***@***.***> ha scritto:
… latest docker image is still behind Core version.
Just tagged a new one now, should be about 10 mins. I didn't tag before
because there wasn't anything massively relevant to docker in the core
hotfix.
where does the image live?
If you just run docker images on your CLI - it should be listed there
among any others you have downloaded
—
Reply to this email directly, view it on GitHub
<#2242 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOIGK5MWVXHOL7GKKU5N2UL2RMZKXAVCNFSM6AAAAABXT4Y5ZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZYG42TMMZXHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
[image: PromoFaux]*PromoFaux* left a comment (pi-hole/FTL#2242)
<#2242 (comment)>
latest docker image is still behind Core version.
Just tagged a new one now, should be about 10 mins. I didn't tag before
because there wasn't anything massively relevant to docker in the core
hotfix.
where does the image live?
If you just run docker images on your CLI - it should be listed there
among any others you have downloaded
—
Reply to this email directly, view it on GitHub
<#2242 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOIGK5MWVXHOL7GKKU5N2UL2RMZKXAVCNFSM6AAAAABXT4Y5ZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZYG42TMMZXHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Sorry, no it wont be, the fix is not in those tags, rather still in development. Please try with the |
|
@PromoFaux tried on nightly, function in error message is different, but still failing |
If everyone here is on Synology, what versions are you running? @uurf is the above. I am running OK on a DS218+ with:
|
|
|
Same issue here with an older Synology:
It appears to crash immediately when My original thinking was an internal network loop (with FTL) but even after tweaking the compose file with multiple network flavors, the results were always the same. One thing to note, and this could just be a bug with our version of Docker, the PORTS column under the docker ps command is empty. I can't recall if this was normally the case with other containers and this version of Docker/Synology:
Edit: Another thing to note- the container crashes as well, which could be triggered by FTL's crash.:
|
|
@DL6ER does this (changed) error message from the comment 4 above from here indicate a new direction to look in? @UnnaturalFlavors - are you seeing the same issue with getRandom()? |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
In testing I did discover that visiting I've flipped this thing upside down so many times that it's possible I was misremembering seeing the 403 page under the pi.hole URL. |
Can you post a screenshot of the page? It looks like |
|
This is from a clean docker image pulled from pihole:development with no other services running on that docker host or IP. Screenshot taken visiting To add, this is a vanilla set up with no proxy or additional layers. Just a Docker container plopped onto an older Synology. |
|
This is expected. You need to visit: |
|
Agreed, just mentioning here to showcase that the webserver is pushing content appropriately (at least on my instance) until visiting /admin 👍 |
|
Apologies to keep spamming this thread but it does seem similar to #2288 and others listed in that thread regarding a segment fault (which is the same or similar to what I'm getting) and it got me thinking. After somewhat diving into the code and following the chain, during the initial processing there's generation of certificate(s) and x509 is listed as a key. While slamming my face against the keyboard to test the host instance of openssl, I got the following error while running the following: And to share: I swear I remember reading or seeing something about older Synology and crypto issues but haven't taken any time to poke the search engines. Now it's certainly not definitive but could at least be part of the overall culprit to the issues we're experiencing. The type of processor could also play a part: @uurf and I are both running Synology units with the @vitaliy-sk is running I believe the @PromoFaux is running the There's a commonality between the processor that is working and the ones that aren't (Realtek vs Intel) with the Intel chips ~2013 and the Realtek ~2018 (best guess based on data found), there should be a fundamental difference in feature sets with supported cryptography being one but also backwards compatibility (not to mention architecture, x86 vs ARM). Just a hunch so take the above with a grain of salt but considering we're all receiving similar errors regarding getrandom and hashes along with the hard crashes, there might be something to it. Edit: To add, the openssl command does create the appropriate files but whether they are correct, I didn't go to that length yet. A quick search shows that you can manually create the .rnd file (successfully) into /root using the following and it eliminates the "Can't load..." error above while using openssl: Edit 2: Using certtool, I was able to verify the pem cert that was created using the above is valid (or at least properly structured): |
|
For the missing |
|
FTL is an all-static batteries-included binary that can run on any (even ancient) operating system regardless of the installed libc. To achieve this, we use a static variant of https://musl.libc.org/, there is no dynamic linkage at all to avoid dependency issues. This is relevant for Pi-hole as users install and use it on operating systems with older libc which in the past limited is in what we could use as to not break compatibility with them (or going the extra lengths of providing individual build per architecture and per glibc version) |
|
Having said that, please also see my comment here: #2281 (comment) It is worth trying this if you still see the issue. I started working on a software-entropy source - initialized at the very beginning of the |
This comment has been minimized.
This comment has been minimized.
|
Lets try and put a bit of a spreadsheet together here to capture the range of this issue. Link below is open to edit by anyone with link, please add to it if you are running on a Synology device (even if not facing this issue!) https://docs.google.com/spreadsheets/d/13crEk428bO87JOkIhT6xbX7MU6QQCCJONzP9xU3yxo8/edit?usp=sharing |
This comment has been minimized.
This comment has been minimized.
|
Seems like it is an issue with Kernel versions < 3.16: bugs.debian.org/cgi-bin/bugreport.cgi?bug=978045 (apparently Synology does not update the kernel even when new versions of DSM are released: https://www.reddit.com/r/synology/comments/y5nzm9/comment/it12gf8/ |
"Function not implemented" = It really seems to be a Synology issue, I have found other reports all over the web for various projects
Some users reported (for other projects) that upgrading their kernels helped but I guess that's no option for Synology? I will come back to you later with a proposed fix how to source "sufficiently good" randomness even without hardware randomness support. |
|
I also have the same issue with a DS716+II on 7.2.2-72806 Update 3 with an INTEL Celeron N3160. |
This comment has been minimized.
This comment has been minimized.
|
I pushed my proposed suggestion after doing careful randomness quality tests of all involved fallback layers. Please verify if FTL's branch |
This comment has been minimized.
This comment has been minimized.
|
I would have thought it would be fine to build locally per normal instructions - there is one way to find out! But I will also build and push a special tag for x86_64 |
|
OK I have pushed a special tag for this: |
I will give this a try later this evening. |
|
@PromoFaux Good catch! I took specs from the wrong model (oops): The non-plus version apparently uses the Pulling the special tag now 👍 |
|
I rebuilt the image with the API password commented out just to make sure things were running but still have a password set via This is a good sign! We weren't even getting this page before: And utilizing https: Confirmed removing the password via CLI allowed immediate access into the site (as was our only means previously). 🥁 Removed the commented API password field in my compose, removed and rebuilt the container again and the first page to appear is correct!: And after using the set password (*not the CLI command, the static password in the compose), successfully logged in, well done! |
|
Not specifically related to this issue (besides the consistent crashes 😂) but it looks like there's now db issues on my instance. The system isn't technically production so a wipe isn't out of the question but was working at least yesterday at some point per the logs. Just a heads up if anyone else with a kernel-laden Synology had the crash issue and didn't back up the databases prior to the upgrade. FYI, the issues below are not the fault of the special tag
I'll make a copy of that db and dive into it later. |
|
Browsing through the FTL log and noticed this which I'm assuming was one of the workarounds for the getrandom/kernel issue: Sounds like a
|
|
The last line will not be shown if you disable all debug options. |
|
@PromoFaux thanks, working as expected with First start took 3 mins due to DB migration, next start is ok (first start logs) Fallback to /dev/urandom is working Tested Web UI with and without password, and HTTP and HTTPs are also working |
I tested this image also on my Synology and it fixes the crashes. |
on my instance:
|
|
This hasn't resolved what I had hoped was a related problem of the set webpassword not being recognized , but did get rid of the randomness errors in the log, but a sudo pihole setpassword is at least working |
Versions
Platform
DSM 7.2.2-72806 Update 3
Docker Compose via Synology Container Manager 20.10.23-1437
Expected behavior
Having set a password using
FTLCONF_webserver_api_password: '<password>'I expect the web service to load onhttps://<adress>:8181/adminand to be challenged for the password I set.Actual behavior / bug
FTL Crashes.
Steps to reproduce
Steps to reproduce the behavior:
https://<adress>:8181/adminDebug Token
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
if I comment out # FTLCONF_webserver_api_password: '' it starts and the FTL ui is accessible where expected, but there's no password. Not even a randomly generated one.
I am able to set a password via
pihole setpasswordbut it doesn't seem to be used - after setting it the admin UI still loads without a login challenge.The text was updated successfully, but these errors were encountered: