Willing to start over, but want to keep device definitions at least

I would like to retreat from the bleeding edge of daily updates, and adopt a more conservative update strategy, but I really don’t want to lose all my device data. I’d like to keep the history too, but that’s secondary.

Is anyone else in this situation ? Is there a best practice for getting back to something that works, even if it’s not the latest ?

1 Like

why not just switch to the stable branch? No need to start over?

https://docs.librenms.org/General/Updating/

Will read with interest… Hopefully the db stays in one piece. Thanks for the pointer.

Here’s my attempt at getting back to the released version:

[email protected]:~$ grep update_channel config.php
$config["update_channel"] = "release";

[email protected]:~$ cd /opt/librenms && git fetch --tags && git checkout $(git describe --tags $(git rev-list --tags --max-count=1))
HEAD is now at 5f7682d4f Bump version to 21.4.0
[email protected]:~$ ./daily.sh
Fetching new release information                   OK
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
[email protected]:~$
[email protected]:~$
[email protected]:~$ ./validate.php
====================================
Component | Version
--------- | -------
LibreNMS  | 21.4.0
DB Schema | 2020_12_14_091314_create_port_group_port_table (202)
PHP       | 7.3.27-9+ubuntu18.04.1+deb.sury.org+1
Python    | 3.8.5
MySQL     | 10.3.25-MariaDB-0ubuntu0.20.04.1
RRDTool   | 1.7.2
SNMP      | NET-SNMP 5.8
====================================

[OK]    Composer Version: 2.0.12
[OK]    Dependencies up-to-date.
[OK]    Database connection successful
[FAIL]  Your database is out of date!
        [FIX]:
        ./lnms migrate
[email protected]:~$
[email protected]:~$

[email protected]:~$ ./lnms migrate
**************************************
*     Application In Production!     *
**************************************

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

Migrating: 2020_12_14_091314_create_port_groups_table

In Connection.php line 678:

  SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'port_groups' already exists (SQL: create table `port_groups` (`id` int unsigned not null
  auto_increment primary key, `name` varchar(255) not null, `desc` varchar(255) null) default character set utf8mb4 collate 'utf8mb4_unicode_ci')


In Exception.php line 18:

  SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'port_groups' already exists


In PDOStatement.php line 112:

  SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'port_groups' already exists


[email protected]:~$

Going to try the --pretend switch.

[email protected]:~$ ./lnms migrate --pretend
**************************************
*     Application In Production!     *
**************************************

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

CreatePortGroupsTable: create table `port_groups` (`id` int unsigned not null auto_increment primary key, `name` varchar(255) not null, `desc` varchar(255) null) default character set utf8mb4 collate 'utf8mb4_unicode_ci'
CreatePortGroupsTable: alter table `port_groups` add unique `port_groups_name_unique`(`name`)
MigrateToUtf8mb4: ALTER SCHEMA `librenms` DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_unicode_ci;
MigrateToUtf8mb4: select `TABLE_NAME` from `information_schema`.`tables` where `table_schema` = ?
MigrateToUtf8mb4: select * from `information_schema`.`columns` where `table_schema` = ? and `CHARACTER_SET_NAME` is not null and `COLLATION_NAME` is not null and (`CHARACTER_SET_NAME` != ? or `COLLATION_NAME` != ?)
RenameTonerTable: rename table `toner` to `printer_supplies`

In SchemaException.php line 86:

  There is no column with name 'toner_id' on table 'printer_supplies'.


[email protected]:~$

So I understand what I did better, but I’m still stuck. Thanks in advance for any help.

I am in a similar boat… I inherited parts of my LibreNMS config and it still acts like there are issues, even though daily has been run and validate is clean… For example, my health menu ended up with blank entries on it that were all from ipmi sensors in the sensors table… I’d rather not lose the historical data, since it does help to correlate what is normal versus odd over time… but I have a feeling the whole thing needs a good scrub and do-over.

If you switch to the stable branch from daily, will it try to roll back updates from the daily branch that had been running? Which it seems is what it being mentioned above with the db updates and menu issues.

Might it be better to disable daily updates for a while if everything is working, and then wait until the next stable release to run an update from that branch. Thinking that the stable would have all the previous updates from daily included at that point?

So I don’t have any idea what actions I could take to recover. My system is broken - when you log in I see “Whoops, looks like something went wrong. Check your librenms.log.”

In librenms.log I see:

Error in printer-supplies module. SQLSTATE[42S02]: Base table or view not found: 1146 Table 'libre
nms.printer_supplies' doesn't exist (SQL: select * from `printer_supplies` where `printer_supplies
`.`device_id` = 23 and `printer_supplies`.`device_id` is not null)

in daily.log I see

Updating SQL-Schema

In Connection.php line 678:

  SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'port_groups
  ' already exists (SQL: create table `port_groups` (`id` int unsigned not nu
  ll auto_increment primary key, `name` varchar(255) not null, `desc` varchar
  (255) null) default character set utf8mb4 collate 'utf8mb4_unicode_ci')


In Exception.php line 18:

  SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'port_groups
  ' already exists


In PDOStatement.php line 112:

  SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'port_groups
  ' already exists

when I run validate.php I see this:

[email protected]:~$ ./validate.php
====================================
Component | Version
--------- | -------
LibreNMS  | 21.4.0
DB Schema | 2020_12_14_091314_create_port_group_port_table (202)
PHP       | 7.3.27-9+ubuntu18.04.1+deb.sury.org+1
Python    | 3.8.5
MySQL     | 10.3.25-MariaDB-0ubuntu0.20.04.1
RRDTool   | 1.7.2
SNMP      | NET-SNMP 5.8
====================================

[OK]    Composer Version: 2.0.13
[OK]    Dependencies up-to-date.
[OK]    Database connection successful
[FAIL]  Your database is out of date!
        [FIX]:
        ./lnms migrate
[email protected]:~$

When I try to do lnms migrate it is as described above. If this system is irrevocably broken and I have to start over, is there any way to export just my list of devices and their snmp credentials? Or some other subset of my configuration?

Well then… I went through the output of ‘lnms migrate --pretend’ and tried each command manually. A few succeeded.

But I got it back up !

Now validate.php still fails with your database is out of date’. Should I insert a row in the migrations table to make it happy ? If so what value should go in the batch column?

Also, some of the statements failed with syntax errors, like this:

MariaDB [librenms]> select `TABLE_NAME` from `information_schema`.`tables` where `table_schema` = ?;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '?' at line 1
MariaDB [librenms]>

Any pointers on how to proceed from here would be greatly appreciated.