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 ?
why not just switch to the stable branch? No need to start over?
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:
librenms@librenms:~$ grep update_channel config.php
$config["update_channel"] = "release";
librenms@librenms:~$ 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
librenms@librenms:~$ ./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
librenms@librenms:~$
librenms@librenms:~$
librenms@librenms:~$ ./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
librenms@librenms:~$
librenms@librenms:~$
librenms@librenms:~$ ./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
librenms@librenms:~$
Going to try the --pretend switch.
librenms@librenms:~$ ./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'.
librenms@librenms:~$
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:
librenms@librenms:~$ ./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
librenms@librenms:~$
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.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.