starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-13 13:53:31 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Upgrade from 3.3.10 to 3.4.0 fails - ValueError: Found wrong number (0) of constraints for dcim_device(virtual_chassis_id, vc_position) #7469

New Issue
Closed
opened 2025-12-29 20:23:45 +01:00 by adam · 9 comments
adam commented 2025-12-29 20:23:45 +01:00
Owner
Copy Link

Originally created by @TnTBass on GitHub (Jan 6, 2023).

NetBox version

v3.4.0

Python version

3.10

Steps to Reproduce

Upgrade netbox from 3.3.10 to 3.4.0

  • Using docker, but this looks to be a DB migration issue within Netbox itself.

Seems to be a similar issue to:
https://github.com/netbox-community/netbox/issues/11385

I applied the fix found in the discussion:
https://github.com/netbox-community/netbox/discussions/11387

However, that didn't make any difference in my case. Looks like a different constraint is missing.

I did check to see if I had any duplicate named devices, but I do not see any.

Expected Behavior

I would expect the DB to upgrade and netbox 3.4.0 to launch

Observed Behavior

⚙️ 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'
🧬 loaded config '/etc/netbox/config/whipcord.py'
Operations to perform:
  Apply all migrations: admin, auth, circuits, contenttypes, dcim, django_rq, extras, ipam, sessions, social_django, taggit, tenancy, users, virtualization, wireless
Running migrations:
  Applying circuits.0039_unique_constraints... OK
  Applying circuits.0040_provider_remove_deprecated_fields... OK
  Applying circuits.0041_standardize_description_comments... OK
  Applying tenancy.0008_unique_constraints... OK
  Applying tenancy.0009_standardize_description_comments... OK
  Applying ipam.0061_fhrpgroup_name... OK
  Applying ipam.0062_unique_constraints... OK
  Applying ipam.0063_standardize_description_comments... OK
  Applying extras.0078_unique_constraints... OK
  Applying extras.0079_scheduled_jobs... OK
  Applying extras.0080_customlink_content_types... OK
  Applying extras.0081_exporttemplate_content_types... OK
  Applying extras.0082_savedfilter... OK
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.10/site-packages/django/core/management/__init__.py", line 446, in execute_from_command_line
    utility.execute()
  File "/opt/netbox/venv/lib/python3.10/site-packages/django/core/management/__init__.py", line 440, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/opt/netbox/venv/lib/python3.10/site-packages/django/core/management/base.py", line 402, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/opt/netbox/venv/lib/python3.10/site-packages/django/core/management/base.py", line 448, in execute
    output = self.handle(*args, **options)
  File "/opt/netbox/venv/lib/python3.10/site-packages/django/core/management/base.py", line 96, in wrapped
    res = handle_func(*args, **kwargs)
  File "/opt/netbox/venv/lib/python3.10/site-packages/django/core/management/commands/migrate.py", line 349, in handle
    post_migrate_state = executor.migrate(
  File "/opt/netbox/venv/lib/python3.10/site-packages/django/db/migrations/executor.py", line 135, in migrate
    state = self._migrate_all_forwards(
  File "/opt/netbox/venv/lib/python3.10/site-packages/django/db/migrations/executor.py", line 167, in _migrate_all_forwards
    state = self.apply_migration(
  File "/opt/netbox/venv/lib/python3.10/site-packages/django/db/migrations/executor.py", line 252, in apply_migration
    state = migration.apply(state, schema_editor)
  File "/opt/netbox/venv/lib/python3.10/site-packages/django/db/migrations/migration.py", line 130, in apply
    operation.database_forwards(
  File "/opt/netbox/venv/lib/python3.10/site-packages/django/db/migrations/operations/models.py", line 564, in database_forwards
    alter_together(
  File "/opt/netbox/venv/lib/python3.10/site-packages/django/db/backends/base/schema.py", line 533, in alter_unique_together
    self._delete_composed_index(
  File "/opt/netbox/venv/lib/python3.10/site-packages/django/db/backends/base/schema.py", line 589, in _delete_composed_index
    raise ValueError(
ValueError: Found wrong number (0) of constraints for dcim_device(virtual_chassis_id, vc_position)
Originally created by @TnTBass on GitHub (Jan 6, 2023). ### NetBox version v3.4.0 ### Python version 3.10 ### Steps to Reproduce Upgrade netbox from 3.3.10 to 3.4.0 - Using docker, but this looks to be a DB migration issue within Netbox itself. Seems to be a similar issue to: https://github.com/netbox-community/netbox/issues/11385 I applied the fix found in the discussion: https://github.com/netbox-community/netbox/discussions/11387 However, that didn't make any difference in my case. Looks like a different constraint is missing. I did check to see if I had any duplicate named devices, but I do not see any. ### Expected Behavior I would expect the DB to upgrade and netbox 3.4.0 to launch ### Observed Behavior ``` ⚙️ 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' 🧬 loaded config '/etc/netbox/config/whipcord.py' Operations to perform: Apply all migrations: admin, auth, circuits, contenttypes, dcim, django_rq, extras, ipam, sessions, social_django, taggit, tenancy, users, virtualization, wireless Running migrations: Applying circuits.0039_unique_constraints... OK Applying circuits.0040_provider_remove_deprecated_fields... OK Applying circuits.0041_standardize_description_comments... OK Applying tenancy.0008_unique_constraints... OK Applying tenancy.0009_standardize_description_comments... OK Applying ipam.0061_fhrpgroup_name... OK Applying ipam.0062_unique_constraints... OK Applying ipam.0063_standardize_description_comments... OK Applying extras.0078_unique_constraints... OK Applying extras.0079_scheduled_jobs... OK Applying extras.0080_customlink_content_types... OK Applying extras.0081_exporttemplate_content_types... OK Applying extras.0082_savedfilter... OK 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.10/site-packages/django/core/management/__init__.py", line 446, in execute_from_command_line utility.execute() File "/opt/netbox/venv/lib/python3.10/site-packages/django/core/management/__init__.py", line 440, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/opt/netbox/venv/lib/python3.10/site-packages/django/core/management/base.py", line 402, in run_from_argv self.execute(*args, **cmd_options) File "/opt/netbox/venv/lib/python3.10/site-packages/django/core/management/base.py", line 448, in execute output = self.handle(*args, **options) File "/opt/netbox/venv/lib/python3.10/site-packages/django/core/management/base.py", line 96, in wrapped res = handle_func(*args, **kwargs) File "/opt/netbox/venv/lib/python3.10/site-packages/django/core/management/commands/migrate.py", line 349, in handle post_migrate_state = executor.migrate( File "/opt/netbox/venv/lib/python3.10/site-packages/django/db/migrations/executor.py", line 135, in migrate state = self._migrate_all_forwards( File "/opt/netbox/venv/lib/python3.10/site-packages/django/db/migrations/executor.py", line 167, in _migrate_all_forwards state = self.apply_migration( File "/opt/netbox/venv/lib/python3.10/site-packages/django/db/migrations/executor.py", line 252, in apply_migration state = migration.apply(state, schema_editor) File "/opt/netbox/venv/lib/python3.10/site-packages/django/db/migrations/migration.py", line 130, in apply operation.database_forwards( File "/opt/netbox/venv/lib/python3.10/site-packages/django/db/migrations/operations/models.py", line 564, in database_forwards alter_together( File "/opt/netbox/venv/lib/python3.10/site-packages/django/db/backends/base/schema.py", line 533, in alter_unique_together self._delete_composed_index( File "/opt/netbox/venv/lib/python3.10/site-packages/django/db/backends/base/schema.py", line 589, in _delete_composed_index raise ValueError( ValueError: Found wrong number (0) of constraints for dcim_device(virtual_chassis_id, vc_position) ```
adam added the type: bugstatus: under review labels 2025-12-29 20:23:45 +01:00
adam closed this issue 2025-12-29 20:23:45 +01:00
adam commented 2025-12-29 20:23:46 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 6, 2023):

A few people have reported similar issues, but with different indexes on different tables. We've not been able to identify any common root cause among them, nor has it been determined how these indexes (which exist on a clean build) may have been removed.

You can work around this specific error by manually creating the expected index on the SQL table:

ALTER TABLE dcim_device ADD CONSTRAINT temp_fix UNIQUE (virtual_chassis_id, vc_position);

Migrations should complete successfully after adding the index (unless others are also missing). Still, it would be best to determine how the database arrived in this state to begin with.

@jeremystretch commented on GitHub (Jan 6, 2023): A few people have reported similar issues, but with different indexes on different tables. We've not been able to identify any common root cause among them, nor has it been determined how these indexes (which exist on a clean build) may have been removed. You can work around **this specific error** by manually creating the expected index on the SQL table: ``` ALTER TABLE dcim_device ADD CONSTRAINT temp_fix UNIQUE (virtual_chassis_id, vc_position); ``` Migrations should complete successfully after adding the index (unless others are also missing). Still, it would be best to determine how the database arrived in this state to begin with.
adam commented 2025-12-29 20:23:46 +01:00
Author
Owner
Copy Link

@TnTBass commented on GitHub (Jan 6, 2023):

What can I do to help identify how it got into this state?

I have gone through various pg_dumps and recreating the database (migrating from postgres 10 to 12, migrating from an external DB to a postgres container). Seems to be always be generating fine and worked right up until v3.4.0.

As mentioned in the discussion https://github.com/netbox-community/netbox/discussions/11387 I also seem to be missing an index. Not sure what's up there.

@TnTBass commented on GitHub (Jan 6, 2023): What can I do to help identify how it got into this state? I have gone through various pg_dumps and recreating the database (migrating from postgres 10 to 12, migrating from an external DB to a postgres container). Seems to be always be generating fine and worked right up until v3.4.0. As mentioned in the discussion https://github.com/netbox-community/netbox/discussions/11387 I also seem to be missing an index. Not sure what's up there.
adam commented 2025-12-29 20:23:46 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Jan 7, 2023):

Was there any point where an ./upgrade.sh only completed partially? As far as I know, application of migrations is not atomic.

I am hypothesising something like this (untested):

  • In 3.3, you have two devices with names "foo" and "Foo" (i.e. differ only by capitalization)
  • You run ./upgrade.sh to 3.4. It deletes the old constraint, tries to create a new constraint but fails
  • You fix the device names so they don't clash
  • You re-run ./upgrade.sh, but since the old constraint doesn't exist any more, it fails to delete it
@candlerb commented on GitHub (Jan 7, 2023): Was there any point where an `./upgrade.sh` only completed partially? As far as I know, application of migrations is not atomic. I am hypothesising something like this (untested): * In 3.3, you have two devices with names "foo" and "Foo" (i.e. differ only by capitalization) * You run `./upgrade.sh` to 3.4. It deletes the old constraint, tries to create a new constraint but fails * You fix the device names so they don't clash * You re-run `./upgrade.sh`, but since the old constraint doesn't exist any more, it fails to delete it
adam commented 2025-12-29 20:23:47 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Jan 7, 2023):

As far as I know, application of migrations is not atomic.

The individual migrations are atomic by default when using postgres in django.

I am hypothesising something like this (untested):

I went through that exact process with our test environment at work. Upgrade fra 3.3.10 to 3.4.2, fails due to duplicates, fixed it directly in the database, re-ran the migration. No issues.

The missing index could be older, it would be interesting to see if someone with the problem has backup dumps over a long period. Then it would be possible to see if the index has always been missing or if it went missing at some point.

@kkthxbye-code commented on GitHub (Jan 7, 2023): > As far as I know, application of migrations is not atomic. The individual migrations are atomic by default when using postgres in django. > I am hypothesising something like this (untested): I went through that exact process with our test environment at work. Upgrade fra 3.3.10 to 3.4.2, fails due to duplicates, fixed it directly in the database, re-ran the migration. No issues. The missing index could be older, it would be interesting to see if someone with the problem has backup dumps over a long period. Then it would be possible to see if the index has always been missing or if it went missing at some point.
adam commented 2025-12-29 20:23:47 +01:00
Author
Owner
Copy Link

@TnTBass commented on GitHub (Jan 9, 2023):

Was there any point where an ./upgrade.sh only completed partially? As far as I know, application of migrations is not atomic.

I am hypothesising something like this (untested):

* In 3.3, you have two devices with names "foo" and "Foo" (i.e. differ only by capitalization)

* You run `./upgrade.sh` to 3.4.  It deletes the old constraint, tries to create a new constraint but fails

* You fix the device names so they don't clash

* You re-run `./upgrade.sh`, but since the old constraint doesn't exist any more, it fails to delete it

I don't believe this is the case here - I am running through the upgrade process on a dev/test environment. If I find duplicates (thanks to the one report this became very easy - https://github.com/netbox-community/reports/blob/master/reports/dcim-reports/case_insensitive_check.py) I fix them in my prod environment first, then run a pg_dump on the prod and re-import it back to my dev environment (dropping and recreating the netbox DB) to start all over. Hence, I have zero duplicates going into a fresh migration and I still receive this error.

The missing index could be older, it would be interesting to see if someone with the problem has backup dumps over a long period. Then it would be possible to see if the index has always been missing or if it went missing at some point.

I don't have a database dump going back that far, however, I do have a db snapshot from before I started down this migration path. It looks like the index and constraint is missing there as well. Perhaps it wasn't needed in versions before 3.4.x, and hence didn't bark when netbox started? The missing constraint does pre-date this migration, I just couldn't tell you when it went missing.

# \d dcim_device
 status             | character varying(50)    |           | not null |
 comments           | text                     |           | not null |
 device_role_id     | bigint                   |           | not null |
 device_type_id     | bigint                   |           | not null |
 platform_id        | bigint                   |           |          |
 rack_id            | bigint                   |           |          |
 primary_ip4_id     | bigint                   |           |          |
 primary_ip6_id     | bigint                   |           |          |
 tenant_id          | bigint                   |           |          |
 asset_tag          | character varying(50)    |           |          |
 site_id            | bigint                   |           | not null |
 cluster_id         | bigint                   |           |          |
 virtual_chassis_id | bigint                   |           |          |
 vc_position        | smallint                 |           |          |
 vc_priority        | smallint                 |           |          |
 local_context_data | jsonb                    |           |          |
 _name              | character varying(100)   |           |          |
 custom_field_data  | jsonb                    |           | not null |
 location_id        | bigint                   |           |          |
 airflow            | character varying(50)    |           | not null |
Indexes:
    "dcim_device_pkey" PRIMARY KEY, btree (id)
    "dcim_device_asset_tag_key" UNIQUE CONSTRAINT, btree (asset_tag)
    "dcim_device_primary_ip4_id_key" UNIQUE CONSTRAINT, btree (primary_ip4_id)
    "dcim_device_primary_ip6_id_key" UNIQUE CONSTRAINT, btree (primary_ip6_id)
    "dcim_device_rack_id_43208a79_uniq" UNIQUE CONSTRAINT, btree (rack_id, "position", face)
    "dcim_device_site_id_tenant_id_name_93f4f962_uniq" UNIQUE CONSTRAINT, btree (site_id, tenant_id, name)
    "dcim_device_136ca3fc" btree (device_role_id)
    "dcim_device_21556361" btree (rack_id)
    "dcim_device_38543614" btree (tenant_id)
    "dcim_device_asset_tag_8dac1079_like" btree (asset_tag varchar_pattern_ops)
    "dcim_device_bddcf45f" btree (device_type_id)
    "dcim_device_cb857215" btree (platform_id)
    "dcim_device_cluster_id_cf852f78" btree (cluster_id)
    "dcim_device_location_id_11a7bedb" btree (location_id)
    "dcim_device_site_id_ff897cf6" btree (site_id)
    "dcim_device_virtual_chassis_id_aed51693" btree (virtual_chassis_id)
Check constraints:
    "dcim_device_vc_position_check" CHECK (vc_position >= 0)
    "dcim_device_vc_priority_check" CHECK (vc_priority >= 0)
Foreign-key constraints:
    "dcim_device_cluster_id_cf852f78_fk" FOREIGN KEY (cluster_id) REFERENCES virtualization_cluster(id) DEFERRABLE INITIALLY DEFERRED
    "dcim_device_device_role_id_682e8188_fk" FOREIGN KEY (device_role_id) REFERENCES dcim_devicerole(id) DEFERRABLE INITIALLY DEFERRED
    "dcim_device_device_type_id_d61b4086_fk" FOREIGN KEY (device_type_id) REFERENCES dcim_devicetype(id) DEFERRABLE INITIALLY DEFERRED
    "dcim_device_location_id_11a7bedb_fk_dcim_location_id" FOREIGN KEY (location_id) REFERENCES dcim_location(id) DEFERRABLE INITIALLY DEFERRED
    "dcim_device_platform_id_468138f1_fk" FOREIGN KEY (platform_id) REFERENCES dcim_platform(id) DEFERRABLE INITIALLY DEFERRED
    "dcim_device_primary_ip4_id_2ccd943a_fk" FOREIGN KEY (primary_ip4_id) REFERENCES ipam_ipaddress(id) DEFERRABLE INITIALLY DEFERRED
    "dcim_device_primary_ip6_id_d180fe91_fk" FOREIGN KEY (primary_ip6_id) REFERENCES ipam_ipaddress(id) DEFERRABLE INITIALLY DEFERRED
    "dcim_device_rack_id_23bde71f_fk" FOREIGN KEY (rack_id) REFERENCES dcim_rack(id) DEFERRABLE INITIALLY DEFERRED
    "dcim_device_site_id_ff897cf6_fk" FOREIGN KEY (site_id) REFERENCES dcim_site(id) DEFERRABLE INITIALLY DEFERRED
    "dcim_device_tenant_id_dcea7969_fk" FOREIGN KEY (tenant_id) REFERENCES tenancy_tenant(id) DEFERRABLE INITIALLY DEFERRED
    "dcim_device_virtual_chassis_id_aed51693_fk" FOREIGN KEY (virtual_chassis_id) REFERENCES dcim_virtualchassis(id) DEFERRABLE INITIALLY DEFERRED
Referenced by:
    TABLE "dcim_cabletermination" CONSTRAINT "dcim_cabletermination__device_id_f5884934_fk_dcim_device_id" FOREIGN KEY (_device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED
    TABLE "dcim_consoleport" CONSTRAINT "dcim_consoleport_device_id_f2d90d3c_fk" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED
    TABLE "dcim_consoleserverport" CONSTRAINT "dcim_consoleserverport_device_id_d9866581_fk" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED
    TABLE "dcim_devicebay" CONSTRAINT "dcim_devicebay_device_id_0c8a1218_fk" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED
    TABLE "dcim_devicebay" CONSTRAINT "dcim_devicebay_installed_device_id_04618112_fk" FOREIGN KEY (installed_device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED
    TABLE "dcim_frontport" CONSTRAINT "dcim_frontport_device_id_950557b5_fk" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED
    TABLE "dcim_interface" CONSTRAINT "dcim_interface_device_id_359c6115_fk" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED
    TABLE "dcim_inventoryitem" CONSTRAINT "dcim_inventoryitem_device_id_033d83f8_fk" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED
    TABLE "dcim_module" CONSTRAINT "dcim_module_device_id_53cfd5be_fk_dcim_device_id" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED
    TABLE "dcim_modulebay" CONSTRAINT "dcim_modulebay_device_id_3526abc2_fk_dcim_device_id" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED
    TABLE "dcim_poweroutlet" CONSTRAINT "dcim_poweroutlet_device_id_286351d7_fk" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED
    TABLE "dcim_powerport" CONSTRAINT "dcim_powerport_device_id_ef7185ae_fk" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED
    TABLE "dcim_rearport" CONSTRAINT "dcim_rearport_device_id_0bdfe9c0_fk" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED
    TABLE "dcim_vcmembership" CONSTRAINT "dcim_vcmembership_device_id_7e4d276c_fk_dcim_device_id" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED
    TABLE "dcim_virtualchassis" CONSTRAINT "dcim_virtualchassis_master_id_ab54cfc6_fk" FOREIGN KEY (master_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED
    TABLE "ipam_service" CONSTRAINT "ipam_service_device_id_b4d2bb9c_fk" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED
    TABLE "virtualization_virtualmachine" CONSTRAINT "virtualization_virtu_device_id_5a49ed18_fk_dcim_devi" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED
    TABLE "wireless_wirelesslink" CONSTRAINT "wireless_wirelesslin__interface_a_device__6c8e042e_fk_dcim_devi" FOREIGN KEY (_interface_a_device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED
    TABLE "wireless_wirelesslink" CONSTRAINT "wireless_wirelesslin__interface_b_device__43d5101a_fk_dcim_devi" FOREIGN KEY (_interface_b_device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED
@TnTBass commented on GitHub (Jan 9, 2023): > Was there any point where an `./upgrade.sh` only completed partially? As far as I know, application of migrations is not atomic. > > I am hypothesising something like this (untested): > > * In 3.3, you have two devices with names "foo" and "Foo" (i.e. differ only by capitalization) > > * You run `./upgrade.sh` to 3.4. It deletes the old constraint, tries to create a new constraint but fails > > * You fix the device names so they don't clash > > * You re-run `./upgrade.sh`, but since the old constraint doesn't exist any more, it fails to delete it I don't believe this is the case here - I am running through the upgrade process on a dev/test environment. If I find duplicates (thanks to the one report this became very easy - https://github.com/netbox-community/reports/blob/master/reports/dcim-reports/case_insensitive_check.py) I fix them in my prod environment first, then run a pg_dump on the prod and re-import it back to my dev environment (dropping and recreating the netbox DB) to start all over. Hence, I have zero duplicates going into a fresh migration and I still receive this error. > The missing index could be older, it would be interesting to see if someone with the problem has backup dumps over a long period. Then it would be possible to see if the index has always been missing or if it went missing at some point. I don't have a database dump going back that far, however, I do have a db snapshot from before I started down this migration path. It looks like the index and constraint is missing there as well. Perhaps it wasn't needed in versions before 3.4.x, and hence didn't bark when netbox started? The missing constraint does pre-date this migration, I just couldn't tell you *when* it went missing. ``` # \d dcim_device status | character varying(50) | | not null | comments | text | | not null | device_role_id | bigint | | not null | device_type_id | bigint | | not null | platform_id | bigint | | | rack_id | bigint | | | primary_ip4_id | bigint | | | primary_ip6_id | bigint | | | tenant_id | bigint | | | asset_tag | character varying(50) | | | site_id | bigint | | not null | cluster_id | bigint | | | virtual_chassis_id | bigint | | | vc_position | smallint | | | vc_priority | smallint | | | local_context_data | jsonb | | | _name | character varying(100) | | | custom_field_data | jsonb | | not null | location_id | bigint | | | airflow | character varying(50) | | not null | Indexes: "dcim_device_pkey" PRIMARY KEY, btree (id) "dcim_device_asset_tag_key" UNIQUE CONSTRAINT, btree (asset_tag) "dcim_device_primary_ip4_id_key" UNIQUE CONSTRAINT, btree (primary_ip4_id) "dcim_device_primary_ip6_id_key" UNIQUE CONSTRAINT, btree (primary_ip6_id) "dcim_device_rack_id_43208a79_uniq" UNIQUE CONSTRAINT, btree (rack_id, "position", face) "dcim_device_site_id_tenant_id_name_93f4f962_uniq" UNIQUE CONSTRAINT, btree (site_id, tenant_id, name) "dcim_device_136ca3fc" btree (device_role_id) "dcim_device_21556361" btree (rack_id) "dcim_device_38543614" btree (tenant_id) "dcim_device_asset_tag_8dac1079_like" btree (asset_tag varchar_pattern_ops) "dcim_device_bddcf45f" btree (device_type_id) "dcim_device_cb857215" btree (platform_id) "dcim_device_cluster_id_cf852f78" btree (cluster_id) "dcim_device_location_id_11a7bedb" btree (location_id) "dcim_device_site_id_ff897cf6" btree (site_id) "dcim_device_virtual_chassis_id_aed51693" btree (virtual_chassis_id) Check constraints: "dcim_device_vc_position_check" CHECK (vc_position >= 0) "dcim_device_vc_priority_check" CHECK (vc_priority >= 0) Foreign-key constraints: "dcim_device_cluster_id_cf852f78_fk" FOREIGN KEY (cluster_id) REFERENCES virtualization_cluster(id) DEFERRABLE INITIALLY DEFERRED "dcim_device_device_role_id_682e8188_fk" FOREIGN KEY (device_role_id) REFERENCES dcim_devicerole(id) DEFERRABLE INITIALLY DEFERRED "dcim_device_device_type_id_d61b4086_fk" FOREIGN KEY (device_type_id) REFERENCES dcim_devicetype(id) DEFERRABLE INITIALLY DEFERRED "dcim_device_location_id_11a7bedb_fk_dcim_location_id" FOREIGN KEY (location_id) REFERENCES dcim_location(id) DEFERRABLE INITIALLY DEFERRED "dcim_device_platform_id_468138f1_fk" FOREIGN KEY (platform_id) REFERENCES dcim_platform(id) DEFERRABLE INITIALLY DEFERRED "dcim_device_primary_ip4_id_2ccd943a_fk" FOREIGN KEY (primary_ip4_id) REFERENCES ipam_ipaddress(id) DEFERRABLE INITIALLY DEFERRED "dcim_device_primary_ip6_id_d180fe91_fk" FOREIGN KEY (primary_ip6_id) REFERENCES ipam_ipaddress(id) DEFERRABLE INITIALLY DEFERRED "dcim_device_rack_id_23bde71f_fk" FOREIGN KEY (rack_id) REFERENCES dcim_rack(id) DEFERRABLE INITIALLY DEFERRED "dcim_device_site_id_ff897cf6_fk" FOREIGN KEY (site_id) REFERENCES dcim_site(id) DEFERRABLE INITIALLY DEFERRED "dcim_device_tenant_id_dcea7969_fk" FOREIGN KEY (tenant_id) REFERENCES tenancy_tenant(id) DEFERRABLE INITIALLY DEFERRED "dcim_device_virtual_chassis_id_aed51693_fk" FOREIGN KEY (virtual_chassis_id) REFERENCES dcim_virtualchassis(id) DEFERRABLE INITIALLY DEFERRED Referenced by: TABLE "dcim_cabletermination" CONSTRAINT "dcim_cabletermination__device_id_f5884934_fk_dcim_device_id" FOREIGN KEY (_device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED TABLE "dcim_consoleport" CONSTRAINT "dcim_consoleport_device_id_f2d90d3c_fk" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED TABLE "dcim_consoleserverport" CONSTRAINT "dcim_consoleserverport_device_id_d9866581_fk" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED TABLE "dcim_devicebay" CONSTRAINT "dcim_devicebay_device_id_0c8a1218_fk" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED TABLE "dcim_devicebay" CONSTRAINT "dcim_devicebay_installed_device_id_04618112_fk" FOREIGN KEY (installed_device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED TABLE "dcim_frontport" CONSTRAINT "dcim_frontport_device_id_950557b5_fk" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED TABLE "dcim_interface" CONSTRAINT "dcim_interface_device_id_359c6115_fk" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED TABLE "dcim_inventoryitem" CONSTRAINT "dcim_inventoryitem_device_id_033d83f8_fk" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED TABLE "dcim_module" CONSTRAINT "dcim_module_device_id_53cfd5be_fk_dcim_device_id" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED TABLE "dcim_modulebay" CONSTRAINT "dcim_modulebay_device_id_3526abc2_fk_dcim_device_id" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED TABLE "dcim_poweroutlet" CONSTRAINT "dcim_poweroutlet_device_id_286351d7_fk" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED TABLE "dcim_powerport" CONSTRAINT "dcim_powerport_device_id_ef7185ae_fk" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED TABLE "dcim_rearport" CONSTRAINT "dcim_rearport_device_id_0bdfe9c0_fk" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED TABLE "dcim_vcmembership" CONSTRAINT "dcim_vcmembership_device_id_7e4d276c_fk_dcim_device_id" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED TABLE "dcim_virtualchassis" CONSTRAINT "dcim_virtualchassis_master_id_ab54cfc6_fk" FOREIGN KEY (master_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED TABLE "ipam_service" CONSTRAINT "ipam_service_device_id_b4d2bb9c_fk" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED TABLE "virtualization_virtualmachine" CONSTRAINT "virtualization_virtu_device_id_5a49ed18_fk_dcim_devi" FOREIGN KEY (device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED TABLE "wireless_wirelesslink" CONSTRAINT "wireless_wirelesslin__interface_a_device__6c8e042e_fk_dcim_devi" FOREIGN KEY (_interface_a_device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED TABLE "wireless_wirelesslink" CONSTRAINT "wireless_wirelesslin__interface_b_device__43d5101a_fk_dcim_devi" FOREIGN KEY (_interface_b_device_id) REFERENCES dcim_device(id) DEFERRABLE INITIALLY DEFERRED ```
adam commented 2025-12-29 20:23:47 +01:00
Author
Owner
Copy Link

@TnTBass commented on GitHub (Jan 24, 2023):

Adding this comment as I was advised this may fix my existing database prior to upgrade:

unit@e16693834c60:/opt/netbox/netbox$ python3 manage.py makemigrations --dry-run
🧬 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'
🧬 loaded config '/etc/netbox/config/my.py'
No changes detected

However, it doesn't look like anything was detected to fix.

@TnTBass commented on GitHub (Jan 24, 2023): Adding this comment as I was advised this may fix my existing database prior to upgrade: ``` unit@e16693834c60:/opt/netbox/netbox$ python3 manage.py makemigrations --dry-run 🧬 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' 🧬 loaded config '/etc/netbox/config/my.py' No changes detected ``` However, it doesn't look like anything was detected to fix.
adam commented 2025-12-29 20:23:47 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Jan 24, 2023):

End-users should never run makemigrations.

The fix / workaround is to create the missing unique index, as described here, although the exact details of that index will depend on exactly the one which was missing.

@candlerb commented on GitHub (Jan 24, 2023): End-users should never run makemigrations. The fix / workaround is to create the missing unique index, as described [here](https://github.com/netbox-community/netbox/issues/11424#issuecomment-1374180931), although the exact details of that index will depend on exactly the one which was missing.
adam commented 2025-12-29 20:23:47 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 24, 2023):

End-users should never run makemigrations.

To be fair, I've suggested that people run it with --dry-run just to rule out inconsistencies in their schema/code.

@jeremystretch commented on GitHub (Jan 24, 2023): > End-users should never run makemigrations. To be fair, I've suggested that people run it **with `--dry-run`** just to rule out inconsistencies in their schema/code.
adam commented 2025-12-29 20:23:47 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 5, 2023):

It doesn't look like we were ever able to determine the root cause for this, so I'm going to close this out. Happy to revisit this in the future if specific reproduction steps can be pinpointed.

@jeremystretch commented on GitHub (Apr 5, 2023): It doesn't look like we were ever able to determine the root cause for this, so I'm going to close this out. Happy to revisit this in the future if specific reproduction steps can be pinpointed.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: under review type: bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#7469
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?