Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

discussion #15

Closed
technicalpyro opened this issue Apr 7, 2017 · 6 comments
Closed

discussion #15

technicalpyro opened this issue Apr 7, 2017 · 6 comments

Comments

@technicalpyro
Copy link
Contributor

::: Downloading latest version of FTL...
:::  Detected ARM-hf architecture (armv7+)
:::  Installing FTL... transferred... done.
::: Restarting services...

Above appeared today when i ran an update despite being on the most up to date version we may want to look at making that a little more clear before FTL is live

@DL6ER
Copy link
Member

DL6ER commented Apr 7, 2017

Can you reproduce it?

@technicalpyro
Copy link
Contributor Author

I've seen it happen when there is a core update I'm at work and unable to remote in but I left my god session running this morning and I do believe it happened on both devices this morning

@DL6ER
Copy link
Member

DL6ER commented Apr 7, 2017

Hmm, it doesn't happen for me.

Please post your pihole-FTL version output

@technicalpyro
Copy link
Contributor Author

pi@raspberrypi:~ $ pihole-FTL version
v1.10.3

i have noticed it seemed like everytime i have run the update script if it is either a core or FTL update that echo shows

@DL6ER
Copy link
Member

DL6ER commented Apr 8, 2017

Ah! Now I understand what you mean. When Pi-hole core is updated, it will always re-run the installer to be sure that all components are up-to-date. I think this should not be changed. And won't happen often for users that are only pulling updates in master (which come only rarely, if ever, a month).

@DL6ER DL6ER closed this as completed Apr 8, 2017
@technicalpyro
Copy link
Contributor Author

makes sense i have myself primarily ignored that text thinking nothing of it. Thought it best to be sure

DL6ER pushed a commit that referenced this issue Oct 14, 2019
Return 404 pages instead of 500 errors when a page is not found
@jens1205 jens1205 mentioned this issue Dec 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants