Here’s the skinny: Running the Netdata install/register script on RHEL 10 didn’t completely work on the two VM servers I recently constructed for a future post diving into Netdata. I spun up a Debian 13 and Ubuntu 24.04 server as well, and these installed Netdata and its plugins without any issues, so it seems it might be a problem with RHEL 10 or just RHEL in general. I haven’t tried this on RHEL 9 or a RHEL comparable like Rocky or Alma Linux, so that might an additional edit add-on in the future if I test those. All the VM’s used a Bridged Network Adapter to access the internet running in Virtual Box, and were all registered with a Red Hat Developer account. Even after booting up a third RHEL 10 server, it still gave the same error, so I was able to get a screenshot.
Update Sept 30th 2025:
I did a test run with Rocky 10 to further narrow down this issue, and it worked with no problem. The only real difference in RHEL and Rocky is the subscription needed to register the device on RHEL, and if it’s not registered it won’t have access to the app repositories. That being said, it can now be narrowed down to something going on in RHEL that causes the epel-release package from not properly pulling during the Netdata installation via their script. Something in the script is causing it to crash while loading the RHEL repositories.
Update Oct 3rd 2025:
After a little more digging, and a fruitful post on Reddit, it seems you still have to manually install the EPEL repo using the conventional means. One commenter on Reddit perfectly described it as a “chicken or the egg” scenerio: the epel-release command activates the EPEL repo, but that command can only be run after you enable the EPEL repo, because it’s only in the EPEL repo… Pretty brutal. Rocky 10 was able to circumvent this by including their Rocky Linux 10 - Extras repo by default, giving the option to activate EPEL with only epel-release (hence the screenshot above showing it working with no issues). This should be something in RHEL by default as well, since it gets rid of the extra commands to get EPEL, but it’s not on by default until you activate it.
This is, ultimately though, a Netdata issue with their script. It is because it should have a way to pull EPEL repo activation command when it recognizes a RHEL operating system. This could be done when the script checks all active repos, and depending on which RHEL product and version number it’s on, be able to pull the correct commands down before moving on with the rest of the process. This would alleviate any hiccups in the process, and we could’ve avoided this whole blog post in the first place!
What Exactly Happened?
When using the Linux script to add a node it seemed to fail installing it with their rpm package with RHEL, and notified its falling back to a different install method, which is grabbing the files directly from the Netdata GitHub. This way will still install Netdata and connect your node, but the script installing this way didn’t include everything that is provided in the former install method.
I noticed this initially after connecting my two RHEL 10 VM instances with my dashboard. Under the logging section for both RHEL servers, there wasn’t logging enabled at all, so I couldn’t see any of that data being reported and categorized into the Netdata console display. It was completely absent of any data display, and just contained text noting that logging is not set up and had a hyperlink to learn more about Netdata’s logging features. This is a default setting that shouldn’t require any setup, and obviously seeing system logs in a dashboard is one of the attractive features about a monitoring service like Netdata, so I had to find a way to fix this for my own sanity.
The Fix
Skipping the details as to not bore you with my about-an-hour-or-so of testing a couple different methods, the way I ultimately found to fix this is to pull the netdata.run file straight from the Netdata GitHub and manually execute it outside of the original setup script. This eliminates the need to use the Epel repository, which they utilize on their kickoff script, since epel-release was part of the original issue. I already had these two RHEL 10 server instances running and attached to Netdata, but running netdata.run didn’t cause any disconnection to Netdata during or after execution: It just added the missing packages, restarted the services, and what do you know the services that were missing now showed up. The script can detect already installed files and connected nodes, so luckily it just filled in the gaps and didn’t do a complete overwrite.
Before I pulled the stable release of netdata.run from GitHub, I made sure to cd into the /tmp directory to keep the file out of the way since we only need it just this once. Also since we’re manually downloading and running this file, you have to make it executable with the chmod command after you download it. I did run this while I was root, but remember you have to start these with sudo if you are opting to run these under a user account with sudoer privileges instead:
cd /tmp
wget https://github.com/netdata/netdata/releases/latest/download/netdata-latest.gz.run -O netdata.run
chmod +x netdata.run
sh netdata.run
Additional Thoughts
The only thing I wish I would’ve done differently is used something like tmux in the terminal so I could scroll back and see what it said when it failed, instead of the red blurs that I did see fly by during the install. It is common practice to use tmux when accessing a machine via ssh anyways, but since this was a local install for testing purposes I omitted it during this process. Another option could’ve been sending the output to a log file, which would be a more permanent solution that I could access to review the material.
