Hi,
During the last monthly update, or if it was even before, the # character was added to for example the os field in the database. An os that previously was ‘comware’ is now ‘#comware’. That definitely feels like a big bug and it’s causing all sorts of problems. Can’t rerun discovery even, it just adds # to the OS after it runs.
Tomas Andersson
If you mean the os field within the database is showing that then I’m not sure I see how that could be.
You haven’t provided any evidence on what you’re seeing and where though so it’s kind of hard to help
Evidence? You want me to show the database? Sorry, but that’s not going to happen for a number of reasons…
I have not checked all OS fields but I can tell you that even if I change it back to ‘comware’ directly in the database, it will be back to ‘#comware’ on next discovery. I know it’s weird but it’s the same on my lab server as in production. I have also discovered other database records having a leading ‘#’ after the latest update.
I have no idea how that is even possible so that’s why I am asking.
I can add that we have a bit over 4000 devices, and roughly a little below 3000 comware devices. The only ones till having the correct OS are the ones that have been down since the update so it has to happen at discovery.
You really think I’m asking you to dump your database here? 
Anyway you ignored all the information we ask for when creating a help topic so not really much we can do
When asking for help and support, please provide as much information as possible. This should include:
./validate.phpIf it’s an issue with the WebUI then please consider including a screenshot and the browser version you are using.
If you are having troubles with discovery/polling include the pastebin output of:
./discovery.php -h HOSTNAME -d | ./pbin.sh
./poller.php -h HOSTNAME -r -f -d | ./pbin.sh
If you need to post any text longer than a few lines, please use a pastebin service such as https://p.libren.ms using non-expiring pastes.
Sorry, but the https://p.libren.ms site keeps dying on me and I am not entitled to enclose any IP information, so I can’t share all of the information from a discovery. I have verified that the only OS this happens with are with Comware switches, the others don’t get the # added when the os field is set at discovery. I guess I have to reverse engineer where it sets that field in the discovery process if it’s not possible to get that help from here.
Here’s the information from validation from the lab server:
===========================================
| Component | Version |
|---|---|
| LibreNMS | 24.12.0-71-g75ff1c66c (2025-01-16T23:27:04+01:00) |
| DB Schema | 2024_11_22_135845_alert_log_refactor_indexes (310) |
| PHP | 8.3.12 |
| Python | 3.8.10 |
| Database | MariaDB 10.3.39-MariaDB-0ubuntu0.20.04.2 |
| RRDTool | 1.7.2 |
| SNMP | 5.8 |
| =========================================== |
[OK] Composer Version: 2.8.4
[OK] Dependencies up-to-date.
[OK] Database connection successful
[OK] Database connection successful
[OK] Database Schema is current
[OK] SQL Server meets minimum requirements
[OK] lower_case_table_names is enabled
[OK] MySQL engine is optimal
[OK] Database and column collations are correct
[OK] Database schema correct
[OK] MySQL and PHP time match
[OK] Active pollers found
[OK] Locks are functional
[OK] No active python wrapper pollers found
[OK] Redis is unavailable
[OK] rrd_dir is writable
[OK] rrdtool version ok
You can obfuscate the info that’s sensitive.
You’re just not providing us anything to go on. The comware os definition files haven’t been touched in 4 years librenms/includes/definitions/comware.yaml at master · librenms/librenms · GitHub librenms/includes/definitions/discovery/comware.yaml at master · librenms/librenms · GitHub
I am well aware of the comware.yaml file but since the OS is seen as ‘#comware’ rather than ‘comware’, it doesn’t even read it during discovery. If I rename the file to ‘#comware.yaml’, then it runs, not otherwise. So the problem occurs before reading the yaml file.
I’ve done a workaround to fix this, but it’s not a permanent fix. I’ve pinned it down to the 24.12 update. I updated from 24.10 to 24.12. All sensor monitoring for comware switches got lost when I updated to 24.12, I have rrd files from before the date when I updated.
The workaround I did is that I edited LibreNMS/Modules/Core.php to add the following code from row 78:
if ($device->os == '#comware') {
$device->os = 'comware';
}
I don’t know enough about the core functions to analyze this more but this is at least working now and if I find the real reason behind this, I will change accordingly.