Database Schema is from 2019, but otherwise everything is fine?

Help
1

Good Afternoon!

I have LibreNMS running in a few places, and today while updating the installs to Php8.4 I noticed one of my installs is different. The DB Schema listed is from 2019. This is one of my older installs, so its very possible that it has been in continuous operation since 2019.

root@librenms:/opt/librenms# sudo -u librenms ./validate.php
===========================================
Component | Version
--------- | -------
LibreNMS  | 26.8.0-dev.101+9aafc9a88e (2026-08-11T11:52:45-04:00)
DB Schema | 2019_12_14_000001_create_personal_access_tokens_table (396)
PHP       | 8.4.24
Python    | 3.13.5
Database  | MariaDB 11.8.6-MariaDB-0+deb13u1 from Debian
RRDTool   | 1.7.2
SNMP      | 5.9.4.pre2
===========================================

[OK]    Composer Version: 2.10.2
[OK]    Dependencies up-to-date.
[OK]    Database Connected
[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]    Dispatcher Service is enabled
[OK]    Locks are functional
[OK]    No active python wrapper pollers found
[OK]    Redis is unavailable
[OK]    rrd_dir is writable
[OK]    rrdtool version ok

I’ve also tried updating via the CLI:

root@librenms:/opt/librenms# sudo -u librenms lnms update
PHP Error(8192): strtolower(): Passing null to parameter #1 ($string) of type string is deprecated from vendor/laravel/framework/src/Illuminate/Console/GeneratorCommand.php:495 in /opt/librenms/lnms:35
Clearing caches                                    OK
Updating to latest codebase                        OK
Updating Composer packages                         OK
Updating SQL-Schema                                OK
Cleaning up DB                                     OK
Caching PeeringDB data                             OK
root@librenms:/opt/librenms#
root@librenms:/opt/librenms# sudo -u librenms bash daily.sh
Clearing caches                                    OK
Updating to latest codebase                        OK
Updating Composer packages                         OK
Updating SQL-Schema                                OK
Cleaning up DB                                     OK
Caching PeeringDB data                             OK

Nothing is actually broken, so I’m not sure if its actually a problem, but if anyone has any idea how I borked this one, let me know how to fix it!

Thanks!

2

Actually your schema is current. Just somehow it thinks that migration was the last one run…

3

If that’s the case, I’m just going to back away slowly and not look to hard at this one.

Thanks!

4

If you clock was wrong when the migration was run, it could have a bad timestamp storred in the migrations table. You could go update the timestamp if it bothers you :slight_smile:

5

I’m on the fence if I want to make more work for myself if something goes wrong.

However, if I wanted to update the timestamp, how would I do that? Is it a DB thing, filesystem thing or something else?

6

DB thing, the migrations table, which is an extremely simple table.

7

When I came in this morning to work on the timestamp thing, the Database Schema was reporting 2026_07_30, which seems like its fixed. I’m going to assume an update pushed in the last few days fixed it.

Thanks!

root@librenms:/opt/librenms# sudo -u librenms ./validate.php
===========================================
Component | Version
--------- | -------
LibreNMS  | 26.8.0-dev.116+9831e4e438 (2026-08-13T15:04:07-04:00)
DB Schema | 2026_07_30_162514_add_device_refresh_config_permission (397)
PHP       | 8.4.24
Python    | 3.13.5
Database  | MariaDB 11.8.6-MariaDB-0+deb13u1 from Debian
RRDTool   | 1.7.2
SNMP      | 5.9.4.pre2
===========================================

[OK]    Composer Version: 2.10.2
[OK]    Dependencies up-to-date.
[OK]    Database Connected
[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]    Dispatcher Service is enabled
[OK]    Locks are functional
[OK]    No active python wrapper pollers found
[OK]    Redis is unavailable
[OK]    rrd_dir is writable
[OK]    rrdtool version ok
8

possibly just a new migration that added to the list. The “last run migration” is not really deterministic. We only check the total migrations run count really.