Is it known, that the “Fireinfo” links are broken since many releases now? On all machines the links lead to page saying “oops, something went wrong” here.
Fireinfo is working fine for me currently and has for some time.
However about a year ago I also sometimes had that same effect. I couldn’t find what the problem was but stopping sending the profile info and then reconnecting it made it work for me at that time. Give that a try and see if it helps with the problem you are currently experiencing.
1 Like
For example, this is the link that is displayed on my staging instance:
https://fireinfo.ipfire.org/profile/cb1c468b17369db11cde5b284d654c522703ea90
It was freshly installed with Core 168 and then upgraded to Core 169 Testing. The link, however, never worked.
We have the same issue on our produtives instances since a long time, while I’m sure the link worked that days when I installed them many years ago.
I know that issue from restoring a backup to a different machine / hardware environment. I just disable and re-enable it again. Afterwards the link is working.
Wow, I didn’t try that as it seemed too simple to work for me. But actually, that solves the issue. 
Interesting is, that the link ID obviously did not change by dis- and re-enabling it. That’s strange!
Yeah I know. I don’t know why that fixes the issue but it does. As I have encountered some times before the shown status of enabled/disabled settings or services may not be always true.
Actually it does not solve it completely: I just saw that the ID displayed is exactly the same on all machines, though I did not restore them from the same image. 
How is that ID caclulated? Seems to be a bit to coarse eventually?
The ID is generated with your hardware components and serial numbers that are supposed to be unique (especially in sum of a hardware configuration).
But I don’t know how it actually behaves on virtual environments.
1 Like
I just found this thread here: How to reset fireinfo profile id - #12 by cibgiu
Looks like the calculation expects certain DMI fields to be set. This seems not to be true for some motherboards, at least for Jetway which we also have here.
I thought this is outdated and the service has been improved by involving other hardware components as well. Maybe that was just the plan and I don’t remember right because that “inconvenience” is nothing new.
Since this hasn’t been fixed yet and I couldn’t find a bug report that fits, I just created a new one:
https://bugzilla.ipfire.org/show_bug.cgi?id=12896
1 Like
Works as normal under core 168… at least for me 
Will be fixed in Core 170 release.
2 Likes