Migrations failing with "core_objecttype already exists" when upgrading from 4.3.7 to 4.4.x #11724

Closed
opened 2025-12-29 21:49:01 +01:00 by adam · 10 comments
Owner

Originally created by @mraerino on GitHub (Oct 14, 2025).

NetBox Edition

NetBox Community

NetBox Version

v4.4.2

Python Version

3.12

Steps to Reproduce

  • Run Netbox 4.3.7
  • Update to Netbox 4.4.0 or 4.4.1 or 4.4.2
  • See migrations fails with django.db.utils.ProgrammingError: relation "core_objecttype" already exists

This feels related to https://github.com/netbox-community/netbox/issues/20290 but is also different.

Expected Behavior

I expect an upgrade from 4.3.7 to 4.4.0 to work seamlessly.

Observed Behavior

Full stacktrace
⚙️ Applying database migrations
🧬 loaded config '/etc/netbox/config/configuration.py'
🧬 loaded config '/etc/netbox/config/extra.py'
🧬 loaded config '/etc/netbox/config/logging.py'
🧬 loaded config '/etc/netbox/config/plugins.py'
Operations to perform:
  Apply all migrations: account, auth, circuits, contenttypes, core, dcim, django_rq, extras, ipam, sessions, social_django, taggit, tenancy, thumbnail, users, virtualization, vpn, wireless
Running migrations:
Traceback (most recent call last):
  File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/backends/utils.py", line 103, in _execute
    return self.cursor.execute(sql)
           ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/netbox/venv/lib/python3.12/site-packages/psycopg/cursor.py", line 97, in execute
    raise ex.with_traceback(None)
psycopg.errors.DuplicateTable: relation "core_objecttype" already exists
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
  File "/opt/netbox/netbox/./manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/opt/netbox/venv/lib/python3.12/site-packages/django/core/management/__init__.py", line 442, in execute_from_command_line
    utility.execute()
  File "/opt/netbox/venv/lib/python3.12/site-packages/django/core/management/__init__.py", line 436, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/opt/netbox/venv/lib/python3.12/site-packages/django/core/management/base.py", line 416, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/opt/netbox/venv/lib/python3.12/site-packages/django/core/management/base.py", line 460, in execute
    output = self.handle(*args, **options)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/netbox/venv/lib/python3.12/site-packages/django/core/management/base.py", line 107, in wrapper
    res = handle_func(*args, **kwargs)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/netbox/venv/lib/python3.12/site-packages/django/core/management/commands/migrate.py", line 353, in handle
    post_migrate_state = executor.migrate(
                         ^^^^^^^^^^^^^^^^^
  File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/migrations/executor.py", line 135, in migrate
    state = self._migrate_all_forwards(
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/migrations/executor.py", line 167, in _migrate_all_forwards
    state = self.apply_migration(
            ^^^^^^^^^^^^^^^^^^^^^
  File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/migrations/executor.py", line 255, in apply_migration
    state = migration.apply(state, schema_editor)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/migrations/migration.py", line 132, in apply
    operation.database_forwards(
  File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/migrations/operations/models.py", line 97, in database_forwards
    schema_editor.create_model(model)
  File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/backends/base/schema.py", line 512, in create_model
    self.execute(sql, params or None)
  File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/backends/postgresql/schema.py", line 45, in execute
    return super().execute(sql, params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/backends/base/schema.py", line 204, in execute
    cursor.execute(sql, params)
  File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/backends/utils.py", line 122, in execute
    return super().execute(sql, params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/backends/utils.py", line 79, in execute
    return self._execute_with_wrappers(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/backends/utils.py", line 92, in _execute_with_wrappers
    return executor(sql, params, many, context)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/backends/utils.py", line 100, in _execute
    with self.db.wrap_database_errors:
  File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/utils.py", line 91, in __exit__
    raise dj_exc_value.with_traceback(traceback) from exc_value
  File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/backends/utils.py", line 103, in _execute
    return self.cursor.execute(sql)
           ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/netbox/venv/lib/python3.12/site-packages/psycopg/cursor.py", line 97, in execute
    raise ex.with_traceback(None)
django.db.utils.ProgrammingError: relation "core_objecttype" already exists
  Applying core.0018_concrete_objecttype...
Originally created by @mraerino on GitHub (Oct 14, 2025). ### NetBox Edition NetBox Community ### NetBox Version v4.4.2 ### Python Version 3.12 ### Steps to Reproduce - Run Netbox 4.3.7 - Update to Netbox 4.4.0 or 4.4.1 or 4.4.2 - See migrations fails with `django.db.utils.ProgrammingError: relation "core_objecttype" already exists` This feels related to https://github.com/netbox-community/netbox/issues/20290 but is also different. ### Expected Behavior I expect an upgrade from 4.3.7 to 4.4.0 to work seamlessly. ### Observed Behavior <details> <summary>Full stacktrace</summary> ``` ⚙️ Applying database migrations 🧬 loaded config '/etc/netbox/config/configuration.py' 🧬 loaded config '/etc/netbox/config/extra.py' 🧬 loaded config '/etc/netbox/config/logging.py' 🧬 loaded config '/etc/netbox/config/plugins.py' Operations to perform: Apply all migrations: account, auth, circuits, contenttypes, core, dcim, django_rq, extras, ipam, sessions, social_django, taggit, tenancy, thumbnail, users, virtualization, vpn, wireless Running migrations: Traceback (most recent call last): File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/backends/utils.py", line 103, in _execute return self.cursor.execute(sql) ^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/netbox/venv/lib/python3.12/site-packages/psycopg/cursor.py", line 97, in execute raise ex.with_traceback(None) psycopg.errors.DuplicateTable: relation "core_objecttype" already exists The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/opt/netbox/netbox/./manage.py", line 10, in <module> execute_from_command_line(sys.argv) File "/opt/netbox/venv/lib/python3.12/site-packages/django/core/management/__init__.py", line 442, in execute_from_command_line utility.execute() File "/opt/netbox/venv/lib/python3.12/site-packages/django/core/management/__init__.py", line 436, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/opt/netbox/venv/lib/python3.12/site-packages/django/core/management/base.py", line 416, in run_from_argv self.execute(*args, **cmd_options) File "/opt/netbox/venv/lib/python3.12/site-packages/django/core/management/base.py", line 460, in execute output = self.handle(*args, **options) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/netbox/venv/lib/python3.12/site-packages/django/core/management/base.py", line 107, in wrapper res = handle_func(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/netbox/venv/lib/python3.12/site-packages/django/core/management/commands/migrate.py", line 353, in handle post_migrate_state = executor.migrate( ^^^^^^^^^^^^^^^^^ File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/migrations/executor.py", line 135, in migrate state = self._migrate_all_forwards( ^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/migrations/executor.py", line 167, in _migrate_all_forwards state = self.apply_migration( ^^^^^^^^^^^^^^^^^^^^^ File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/migrations/executor.py", line 255, in apply_migration state = migration.apply(state, schema_editor) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/migrations/migration.py", line 132, in apply operation.database_forwards( File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/migrations/operations/models.py", line 97, in database_forwards schema_editor.create_model(model) File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/backends/base/schema.py", line 512, in create_model self.execute(sql, params or None) File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/backends/postgresql/schema.py", line 45, in execute return super().execute(sql, params) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/backends/base/schema.py", line 204, in execute cursor.execute(sql, params) File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/backends/utils.py", line 122, in execute return super().execute(sql, params) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/backends/utils.py", line 79, in execute return self._execute_with_wrappers( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/backends/utils.py", line 92, in _execute_with_wrappers return executor(sql, params, many, context) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/backends/utils.py", line 100, in _execute with self.db.wrap_database_errors: File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/utils.py", line 91, in __exit__ raise dj_exc_value.with_traceback(traceback) from exc_value File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/backends/utils.py", line 103, in _execute return self.cursor.execute(sql) ^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/netbox/venv/lib/python3.12/site-packages/psycopg/cursor.py", line 97, in execute raise ex.with_traceback(None) django.db.utils.ProgrammingError: relation "core_objecttype" already exists Applying core.0018_concrete_objecttype... ``` </details>
adam added the type: bugnetbox labels 2025-12-29 21:49:01 +01:00
adam closed this issue 2025-12-29 21:49:02 +01:00
Author
Owner

@mraerino commented on GitHub (Oct 14, 2025):

actually, this might be an artifact from some earlier work. I'll try from a clean backup

@mraerino commented on GitHub (Oct 14, 2025): actually, this might be an artifact from some earlier work. I'll try from a clean backup
Author
Owner

@bctiemann commented on GitHub (Oct 14, 2025):

@mraerino Any luck?

@bctiemann commented on GitHub (Oct 14, 2025): @mraerino Any luck?
Author
Owner

@arnaudvre commented on GitHub (Oct 14, 2025):

Seeing a similar issue, I'm reverting to a snapshot of a clean 3.7.1 install and importing a 3.7.1 db to test the upgrade script.

After applying Fix #20290 I get this:

  File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/backends/utils.py", line 105, in _execute
    return self.cursor.execute(sql, params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/netbox/venv/lib/python3.12/site-packages/psycopg/cursor.py", line 97, in execute
    raise ex.with_traceback(None)
psycopg.errors.UndefinedTable: relation "core_objecttype" does not exist
LINE 1: ...type"."public", "core_objecttype"."features" FROM "core_obje...
@arnaudvre commented on GitHub (Oct 14, 2025): Seeing a similar issue, I'm reverting to a snapshot of a clean 3.7.1 install and importing a 3.7.1 db to test the upgrade script. After applying Fix #20290 I get this: ``` File "/opt/netbox/venv/lib/python3.12/site-packages/django/db/backends/utils.py", line 105, in _execute return self.cursor.execute(sql, params) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/netbox/venv/lib/python3.12/site-packages/psycopg/cursor.py", line 97, in execute raise ex.with_traceback(None) psycopg.errors.UndefinedTable: relation "core_objecttype" does not exist LINE 1: ...type"."public", "core_objecttype"."features" FROM "core_obje... ```
Author
Owner

@arnaudvre commented on GitHub (Oct 15, 2025):

Conscious this could be muddling things a bit but perhaps the workaround I found may be helpful for this issue too.

  1. Clean install 3.7.1 on Ubuntu 24.04 + import db
  2. Upgrade to 4.0.0 (taking care to keep the build documentation section in upgrade.sh commented out)
  3. Upgrade to 4.1.0 (taking care to keep the build documentation section in upgrade.sh commented out)
  4. Upgrade to 4.2.0 (taking care to keep the build documentation section in upgrade.sh commented out)
  5. Upgrade to 4.3.0 (taking care to keep the build documentation section in upgrade.sh commented out)
  6. Upgrade to 4.4.0 (taking care to keep the build documentation section in upgrade.sh commented out)
  7. Upgrade to 4.4.3 (at this point leave in the document build section, it doesn't fail anymore)
  8. Don't wait so long before upgrading next time
@arnaudvre commented on GitHub (Oct 15, 2025): Conscious this could be muddling things a bit but perhaps the workaround I found may be helpful for this issue too. 1. Clean install 3.7.1 on Ubuntu 24.04 + import db 2. Upgrade to 4.0.0 (taking care to keep the build documentation section in upgrade.sh commented out) 3. Upgrade to 4.1.0 (taking care to keep the build documentation section in upgrade.sh commented out) 4. Upgrade to 4.2.0 (taking care to keep the build documentation section in upgrade.sh commented out) 5. Upgrade to 4.3.0 (taking care to keep the build documentation section in upgrade.sh commented out) 6. Upgrade to 4.4.0 (taking care to keep the build documentation section in upgrade.sh commented out) 7. Upgrade to 4.4.3 (at this point leave in the document build section, it doesn't fail anymore) 8. Don't wait so long before upgrading next time
Author
Owner

@jnovinger commented on GitHub (Oct 15, 2025):

@arnaudvre , thanks for the extra context and full on ❤️ to "Don't wait so long before upgrading next time"! Stepping through each minor version while upgrading is the definitive workaround at this point.

Since your exception is different (psycopg.errors.UndefinedTable: relation "core_objecttype" does not exist vs the original django.db.utils.ProgrammingError: relation "core_objecttype" already exists) and suggests that the #20290 fix did not fix all cases, please open a new bug so that we can discuss these issues individual. Please provide as much detail as you possibly can so that we can understand what edge case we missed with that fix.

@jnovinger commented on GitHub (Oct 15, 2025): @arnaudvre , thanks for the extra context and full on ❤️ to "Don't wait so long before upgrading next time"! Stepping through each minor version while upgrading is the definitive workaround at this point. Since your exception is different (`psycopg.errors.UndefinedTable: relation "core_objecttype" does not exist` vs the original `django.db.utils.ProgrammingError: relation "core_objecttype" already exists`) and suggests that the #20290 fix did not fix all cases, please open a new bug so that we can discuss these issues individual. Please provide as much detail as you possibly can so that we can understand what edge case we missed with that fix.
Author
Owner

@jnovinger commented on GitHub (Oct 15, 2025):

@mraerino , checking in to see if you've had any luck re-visiting this after trying a clean backup? This feels very much like a case where the migration state table (django_migrations) is out of sync with actual database state. I've personally done this more times than I can remember while jumping between code reviews, patch release work, and minor release work.

I expect an upgrade from 4.3.7 to 4.4.0 to work seamlessly.

Unfortunately, since 4.4.0, 4.4.1, and 4.4.2 are released and essentially frozen, this particular expectation will have to remain broken. We did ship a fix for the original issue in 4.4.3, which was released yesterday.

I completely misspoke here, this expectation should absolutely hold. Apologies for confusing the issue.

@jnovinger commented on GitHub (Oct 15, 2025): @mraerino , checking in to see if you've had any luck re-visiting this after trying a clean backup? This feels very much like a case where the migration state table (`django_migrations`) is out of sync with actual database state. I've personally done this more times than I can remember while jumping between code reviews, patch release work, and minor release work. > I expect an upgrade from 4.3.7 to 4.4.0 to work seamlessly. ~~Unfortunately, since 4.4.0, 4.4.1, and 4.4.2 are released and essentially frozen, this particular expectation will have to remain broken. We did ship a fix for the original issue in 4.4.3, which was released yesterday.~~ I completely misspoke here, this expectation should absolutely hold. Apologies for confusing the issue.
Author
Owner

@aloonj commented on GitHub (Oct 16, 2025):

Similar issue here 3.7.8 > 4.4.4 failed. Then had success with 3.7.8 > 4.1.11 > 4.4.4

@aloonj commented on GitHub (Oct 16, 2025): Similar issue here 3.7.8 > 4.4.4 failed. Then had success with 3.7.8 > 4.1.11 > 4.4.4
Author
Owner

@jnovinger commented on GitHub (Oct 16, 2025):

Similar issue here 3.7.8 > 4.4.4 failed. Then had success with 3.7.8 > 4.1.11 > 4.4.4

@aloonj, is there any chance you can share more details? Stacktraces and STR are incredibly valuable for things like this.

@jnovinger commented on GitHub (Oct 16, 2025): > Similar issue here 3.7.8 > 4.4.4 failed. Then had success with 3.7.8 > 4.1.11 > 4.4.4 @aloonj, is there any chance you can share more details? Stacktraces and STR are incredibly valuable for things like this.
Author
Owner

@mraerino commented on GitHub (Oct 21, 2025):

worked fine for me from a fresh backup, sorry for the noise.

@mraerino commented on GitHub (Oct 21, 2025): worked fine for me from a fresh backup, sorry for the noise.
Author
Owner

@jnovinger commented on GitHub (Oct 21, 2025):

worked fine for me from a fresh backup, sorry for the noise.

Appreciate the time and effort you took to make NetBox better!

@jnovinger commented on GitHub (Oct 21, 2025): > worked fine for me from a fresh backup, sorry for the noise. Appreciate the time and effort you took to make NetBox better!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#11724