Upgrade from Netbox 2.9.11 to 2.10.10 Error #12302
Unanswered
TravAJohn
asked this question in
Help Wanted!
Replies: 2 comments 4 replies
-
|
Can you show the whole migration log? 0051_migrate_customfields.py has a number of dependencies, i.e. migrations which should have run before this one: Therefore, either:
You can check case (2) by doing a SQL query on your machine. I don't have an old Netbox lying around, but you should have a table called something like Incidentally, although there's no harm going stepwise as you are, in reality you only need to do two steps: one to 2.11.12, and then to 3.4.8. Between those two you'll have to upgrade the other requirements: definitely python to 3.8+, and postgres to 11+. Maybe redis too. If you have multiple versions of python on your box, then you can do this to tell upgrade.sh which one to use (you'll have to remember to do this every time you upgrade in future too)
You may find it's easier to build a fresh modern VM with 3.4.8, import the SQL data (and media files) from the 2.11.12 instance, and then run |
Beta Was this translation helpful? Give feedback.
4 replies
-
|
Sure here it is: Luckily this is a clone VM of our prod server and I have plenty of backups and snapshots to play with in case things go pear shaped :) Additionally, I was looking at this last night and I found a code block someone suggested that I place into 0051_migrate_customfields.py: I added it and well, it generated quite a lof of output, I'll attatch a file instead of code block for sanity's sake. And you are absolutely right, it would be easier to rebuild. I actually have an Alma Linux 9 VM built and ready to go on the latest netbox version, Postgresql 15 and Python 3.11. The goal is to get the existing data in our CentOS 7 VM in a good enough state where I can take an SQL dump, and import it into the netbox database on the new Alma 9 server. |
Beta Was this translation helpful? Give feedback.
-
OK, it looks all the pre-reqs were done.
Hmm, looks like you had custom field data attached to lots of "DeviceBayTemplate" and "TaggedItem models" (which shouldn't have it). I reckon those CustomFieldValue rows are corrupted. Taking one example: I suggest you If it's correct, then you could do a bulk replace in customfieldvalue from the old object_type_id to the new object_type_id. Repeat for DeviceBayTemplate (should that perhaps be Device? What types of object have You'd have to wonder quite how the object_type_id got corrupted in the first place - and whether any other object types have broken custom fields. The good news is, it's much better in Netbox 2.10+: the custom field data is a JSON field directly attached to every object, so there's no chance of it getting detached in this way again. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the insight! I'm running through you suggestions now to see if we can do a bulk replace. The |
Beta Was this translation helpful? Give feedback.
-
Makes sense, in which case that looks like data which should be attached to "Device" not "DeviceBayTemplate". Is it actually working as expected? Or perhaps this is just obsolete/duplicate data, i.e. you have ConfigBackup='1' on device 123, and also have a stale ConfigBackup='1' on "devicebaytemplate" 123? If that's the case, then you can just skip over the bad ones as your little patch already does. But it would be worth investigating a few by hand, and also checking what the GUI shows for the custom fields on those devices. |
Beta Was this translation helpful? Give feedback.
-
|
You may find it's easier to build a fresh modern VM with 3.4.8, import the SQL data (and media files) from the 2.11.12 instance, and then run ./upgrade.sh to complete the upgrade of the database.
It is possible to get Netbox 3.4.8 running cleanly on EL7 but you'll need the rh-python-python38 and rh-redis5-redis packages from SCL in addition to upgrading PostgreSQL (which may require a dump/restore) using postgresql.org packages (or SCL if they exist), but as Brian said, just migrating the DB to a new server and running upgrade.sh there after upgrading to 2.11.12 in-place may be a simpler process since you have to change so much of the underlying dependancies.
Getting the latest pynetbox and Ansible collection running on EL7 with Ansible 2.9 is a problem I haven't yet solved.
—
Mark Tinberg ***@***.***>
Division of Information Technology-Network Services
University of Wisconsin-Madison
Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello,
I'm working to get our very old Netbox instance upgraded from 2.9.11 to 3.4 We're currently running CentOS 7.9 and Postgres 9.6.
Due to the amount of changes between the versions I am upgrading using the git version tags going from one version to the next. After I git pull and checkout the tag for 2.10.10 I run the upgrade script. It gets through some migrations until the extras.0051_migrate_customfields.py script is run.
Here is the error I am getting:
Clearly there is something wrong with one of our custom field values but I cannot determine which one is the problem.
I did find this older thread: #5475
The fix is to add a block to a function that skips invalid custom field values. When I run that it upgrades successfully but it removed all of the values from our custom fields (we use them for automation).
I've dug through the extras_customfieldvalue table in the netbox database but none of the values appears to be assigned to a null or empty object.
Any help would be greatly appreciated at this point because I'm out of ideas at this point.
Beta Was this translation helpful? Give feedback.
All reactions