Fresh install and I turned on the preset QoS with my speeds.
I get blanks for the graphs:
and I can’t see any of the RRD files.
Fresh install and I turned on the preset QoS with my speeds.
I get blanks for the graphs:
and I can’t see any of the RRD files.
If it is a completely fresh install then you will probable need to wait for some time for the first data point or points to be collected.
I remember this being mentioned before about graphs with no history on a previous thread but I can’t remember how long you have to wait.
After updating to 175, the QOS graphs do not work
( previously fine )
you can always repair your logging and graphing system using this procedure.
I have already tried this procedure, unfortunately it did not help
I tried again now (doesn’t help)
qos does not create log files in /var/log/rrd
I’m sorry, I’m writing through a translator
If @otadr had the graphs working in CU174 and they are giving the error message in CU175 then that looks like there is a bug present.
To confirm, I started QOS up on CU175 and after 30 mins I still had the following status
/var/log/rrd/
directory had the following files
drwxr-xr-x 4 root root 4.0K Jun 13 20:22 .
drwxr-xr-x 18 root root 4.0K Jun 13 11:56 …
-rw-r–r-- 1 root root 745K Jun 13 20:40 class_1-1_red0.rrd
-rw-r–r-- 1 root root 745K Jun 13 20:40 class_2-1_imq0.rrd
drwxr-xr-x 3 root root 4.0K Mar 6 2017 collectd
-rw-r–r-- 1 root root 29K Jun 13 20:40 hddshutdown-sda.rrd
-rw-r–r-- 1 root root 29K Jun 13 20:40 hddtemp-sda.rrd
drwxr-xr-x 2 root root 4.0K Apr 24 00:00 wio
Then I installed CU174 on a vm system and started QOS the same way and virtually straight away I had a graph, even if there was no content on it yet.
/var/log/rrd/
directory contained the following files:-So in CU175 there are many files missing which in CU174 are created straight away when QOS is started.
I would suggest that @otadr raises a bug for this issue.
https://wiki.ipfire.org/devel/bugzilla
https://bugzilla.ipfire.org/
Your IPFire People Email Adrress and Password will act as your login credentials for the IPFire Bugzilla.
Since I only write English in front of a translator,
and I haven’t posted the error report yet, I’ll ask someone knowledgeable to do it, so it’s meaningful. Thanks
@otadr I encourage you to do the job yourself using chatGPT from https://chat.openai.com/
I composed a short message in my native language, requesting the Language Model (LLM) to write a persuasive message to you in English on my behalf. The intention was to encourage you to prepare a comprehensive bug report by providing instructions to the LLM in your own language. Additionally, I suggested including two supporting arguments for this approach. Please note that the instructions were hastily written in less than a minute IN MY NATIVE LANGUAGE, resulting in their subpar quality. The following text is what the AI has generated based on those instructions.
Dear IPFire User,
I understand that you feel hesitant about preparing a bug report due to your reliance on a translator. However, I have a suggestion that might help you overcome this challenge. I recommend creating an account with OpenAI and using ChatGPT 3.5 in your native language, just as I am doing now.
There are two significant advantages to this approach. Firstly, using ChatGPT 3.5 will provide you with high-quality text output that closely matches the language you input. This will help ensure the accuracy and clarity of your bug report. Secondly, by observing how ChatGPT formulates responses, you can gradually improve your English language skills, absorbing sentence structures and expanding your vocabulary along the way.
I encourage you to give it a try. Begin by asking ChatGPT 3.5 to switch to English and then compose your message following the instructions provided. You can rely on ChatGPT to assist you throughout the process, just like I am doing now. Embracing this approach will not only help you create a more effective bug report but also enhance your English language proficiency.
Best regards,
[Your Name]
I am back, this is cfusco using his own poor English skills. For your own best interest, do the bug report yourself. You will quickly learn how to use this new tool to compose good quality messages in a new language, to write code in any computer programming language and ultimately to make you in a better position in life. Remember what in the AI community they say, quote:
You will not lose your job to an AI. You will lose your job to someone else using an AI
I want to leave you with a final thought. There are many short-comings to OpenAI. To mention just two, they generate code which is subpar at best and wrong at worst. Also, Microsoft will exploit its users and violate their privacy, you can be certain of that. However, this is the way forward. Learn to use these tools, and learn to work around their limitations. Follow the development of LLM and as soon as you are comfortable, install one to run LOCALLY, without giving up your privacy to multinationals companies.
Bug has been reported by @otadr
thank you I’ve already seen
The same here. Since the update from 174 → 175,
the old rrd-files are all there and have a current date and time stamp, but no new added content.
Ah. When I did my test on my vm testbed I saw that the graphs were still present but didn’t notice that no new data was being added.
Could you add your input into the bug in the IPFire Bugzilla - see post #9
Another “me too” reply. I had QoS and graphs working fine on 174, then updated to 175 and they stopped displaying. Interestingly, QoS appears to continue working for me, perhaps because I already had the rules set up prior to updating. I say that based on running speed test and buffer bloat tests and getting similar results to 174. So for me, it appears as if the graphs just stopped displaying anything.
Hi, I am trialing IPFire mainly for its cake feature, brand new install IPFire 2.27 - Core Update 175
Proxmox VM
Upon installation I only configured QoS and error shown above appears.
QoS settings are understood by the wiki, I simply set it to 50000/20000 and hit preset save.
Did a search before posting, of the dozen or so similar posts, there only appears to be 1 similar to mine, however the post went unresolved.
Cant really give anymore info other than fresh install and changed one thing, the QoS.
Hall @tidehunter
Welcome to the IPFire community.
See thread https://community.ipfire.org/t/qos-graphs-not-working-in-175/9885 for the topic covering what you have experienced and this specific post https://community.ipfire.org/t/qos-graphs-not-working-in-175/9885/9 for the link to the bug report which gives details of the status.
Fix has been implemented into Core Update 176 which is currently in Testing phase.
Several people have already reported in the bug report that the fix in CU176 Testing has resolved the problem for them.
Please test Core Update 176 Testing and report back the results.
To give an overall picture of what happened.
There was an earlier bug raised Bug#13075 in Core Update 174.
The root cause for the problem was that a change occurred in the tc package used to create the data for QOS. A change was made to the regex for tc which solved the problem but then tc was updated upstream to fix the problem and so the graphs again were not properly created when the updated tc was implemented in Core Update 175.
The regex change was then reverted in Core Update 176 which then allows the upstream corrected tc package to properly deal with the data for the graphs.