Whoops, looks like something went wrong. Your database is out of date!

went to log into my libre server this morning and was prompted with “something went wrong”. logged into back end to find the output of ./validate requesting i run a migrate command. i’ve been unsuccessful in running the command and getting db errors of existing tables. anyone seen this before?

librenms@librenms:~$ ./validate.php

Component Version
LibreNMS 1.53.1
DB Schema (0)
PHP 7.2.19-0ubuntu0.18.04.1
MySQL 10.1.40-MariaDB-0ubuntu0.18.04.1
RRDTool 1.7.0
SNMP NET-SNMP 5.7.3
====================================

[OK] Composer Version: 1.8.6
[OK] Dependencies up-to-date.
[OK] Database connection successful
[FAIL] Your database is out of date!
[FIX]:
./lnms migrate
[FAIL] The poller (librenms) has not completed within the last 5 minutes, check the cron job.
[WARN] Some devices have not been polled in the last 5 minutes. You may have performance issues.
[FIX]:
Check your poll log and see: Performance - LibreNMS Docs
Devices:
ep-wap2.jetsonsys.com
[FAIL] Some devices have not completed their polling run in 5 minutes, this will create gaps in data.
[FIX]:
Check your poll log and see: Performance - LibreNMS Docs
Devices:
lm-router.jetsonsys.com
[FAIL] Discovery has not completed in the last 24 hours.
[FIX]:
Check the cron job to make sure it is running and using discovery-wrapper.py
librenms@librenms:~$ ./lnms migrate


  • Application In Production!     *
    

Do you really wish to run this command? (yes/no) [no]:

yes

Migrating: 2018_07_03_091314_create_access_points_table

In Connection.php line 664:

SQLSTATE[42S01]: Base table or view already exists: 1050 Table ‘access_points’ already exists (SQL: create table a ccess_points (accesspoint_id int unsigned not null auto_increment primary key, device_id int unsigned not null
, name varchar(255) not null, radio_number tinyint null, type varchar(16) not null, mac_addr varchar(24) no
t null, deleted tinyint(1) not null default ‘0’, channel tinyint unsigned not null default ‘0’, txpow tinyint
not null default ‘0’, radioutil tinyint not null default ‘0’, numasoclients smallint not null default ‘0’, nu mmonclients smallint not null default ‘0’, numactbssid tinyint not null default ‘0’, nummonbssid tinyint not n
ull default ‘0’, interference tinyint unsigned not null) default character set utf8 collate ‘utf8_unicode_ci’)

In PDOStatement.php line 119:

SQLSTATE[42S01]: Base table or view already exists: 1050 Table ‘access_points’ already exists

In PDOStatement.php line 117:

SQLSTATE[42S01]: Base table or view already exists: 1050 Table ‘access_points’ already exists

Any ideas on this one? My server is still offline and I am stuck. any help would be greatly appreciated.

What does ./daily.sh show ?

You could try to delete that particular migration e.g Can't get daily.sh running without any problems to see if you can get the database up-to-date

librenms@librenms:~$ ./daily.sh
Updating to latest release OK
Updating Composer packages OK
Updating SQL-Schema OK
Updating submodules OK
Cleaning up DB OK
Fetching notifications OK
Caching PeeringDB data OK

i have attempted to delete the migrations table and re-run ./lnms migrate but the error persists. i have also attempted ./lnms migrate:install but get the following:

librenms@librenms:~$ ./lnms migrate:install

In Connection.php line 664:

SQLSTATE[42S01]: Base table or view already exists: 1050 Table ‘migrations’ already exists (SQL: create table migr ations (id int unsigned not null auto_increment primary key, migration varchar(255) not null, batch int not
null) default character set utf8 collate ‘utf8_unicode_ci’)

In PDOStatement.php line 119:

SQLSTATE[42S01]: Base table or view already exists: 1050 Table ‘migrations’ already exists

In PDOStatement.php line 117:

SQLSTATE[42S01]: Base table or view already exists: 1050 Table ‘migrations’ already exists

so still showing same error after login attempt.
here is librenms.log contents.

librenms@librenms:~$ tail -n 20 logs/librenms.log
#61 /opt/librenms/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(163): Fideloper\Proxy\TrustProxies->handle(Object(Illuminate\Http\Request), Object(Closure))
#62 /opt/librenms/vendor/laravel/framework/src/Illuminate/Routing/Pipeline.php(53): Illuminate\Pipeline\Pipeline->Illuminate\Pipeline\{closure}(Object(Illuminate\Http\Request))
#63 /opt/librenms/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/TransformsRequest.php(31): Illuminate\Routing\Pipeline->Illuminate\Routing\{closure}(Object(Illuminate\Http\Request))
#64 /opt/librenms/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(163): Illuminate\Foundation\Http\Middleware\TransformsRequest->handle(Object(Illuminate\Http\Request), Object(Closure))
#65 /opt/librenms/vendor/laravel/framework/src/Illuminate/Routing/Pipeline.php(53): Illuminate\Pipeline\Pipeline->Illuminate\Pipeline\{closure}(Object(Illuminate\Http\Request))
#66 /opt/librenms/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/TransformsRequest.php(31): Illuminate\Routing\Pipeline->Illuminate\Routing\{closure}(Object(Illuminate\Http\Request))
#67 /opt/librenms/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(163): Illuminate\Foundation\Http\Middleware\TransformsRequest->handle(Object(Illuminate\Http\Request), Object(Closure))
#68 /opt/librenms/vendor/laravel/framework/src/Illuminate/Routing/Pipeline.php(53): Illuminate\Pipeline\Pipeline->Illuminate\Pipeline\{closure}(Object(Illuminate\Http\Request))
#69 /opt/librenms/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/ValidatePostSize.php(27): Illuminate\Routing\Pipeline->Illuminate\Routing\{closure}(Object(Illuminate\Http\Request))
#70 /opt/librenms/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(163): Illuminate\Foundation\Http\Middleware\ValidatePostSize->handle(Object(Illuminate\Http\Request), Object(Closure))
#71 /opt/librenms/vendor/laravel/framework/src/Illuminate/Routing/Pipeline.php(53): Illuminate\Pipeline\Pipeline->Illuminate\Pipeline\{closure}(Object(Illuminate\Http\Request))
#72 /opt/librenms/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/CheckForMaintenanceMode.php(62): Illuminate\Routing\Pipeline->Illuminate\Routing\{closure}(Object(Illuminate\Http\Request))
#73 /opt/librenms/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(163): Illuminate\Foundation\Http\Middleware\CheckForMaintenanceMode->handle(Object(Illuminate\Http\Request), Object(Closure))
#74 /opt/librenms/vendor/laravel/framework/src/Illuminate/Routing/Pipeline.php(53): Illuminate\Pipeline\Pipeline->Illuminate\Pipeline\{closure}(Object(Illuminate\Http\Request))
#75 /opt/librenms/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(104): Illuminate\Routing\Pipeline->Illuminate\Routing\{closure}(Object(Illuminate\Http\Request))
#76 /opt/librenms/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php(151): Illuminate\Pipeline\Pipeline->then(Object(Closure))
#77 /opt/librenms/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php(116): Illuminate\Foundation\Http\Kernel->sendRequestThroughRouter(Object(Illuminate\Http\Request))
#78 /opt/librenms/html/index.php(53): Illuminate\Foundation\Http\Kernel->handle(Object(Illuminate\Http\Request))
#79 {main}
"}

Anyone seen this before? Able to assist in resolution? I dont even mind if i have to wipe DB as long as I dont have to reinstall/rebuild.

hey jetonsys

I am facing a similar issue. I can see the graphs getting build now on my server thou

But this migration issue is still there

I’m still not even able to log into the web UI due to this issue

for me I want to understand how this will effect operations I am able to login to the UI and graphs are also updating for me

When you shifted did you update the config.php file with the new server’s sql credentials?

I’m not sure I understand your question. the migration never successfully completes nor have the server or server sql credentials changed.