Error upgrading from 4.0.11 to 4.1.0 #10200

See https://github.com/netbox-community/netbox/discussions/17379#discussioncomment-10576206

@candlerb commented on GitHub (Sep 7, 2024):

From that, it appears to be that migration dependencies haven't been declared properly, so they are applied in a non-deterministic order. Hence it works for some people and not for others.

Making this something that could be reproduced would be difficult: I don't know what affects the order in which they're applied (e.g. the order in which the files were created in the directory?)

It might be a good idea if the migrations were sorted by name, so that any which don't explicitly depend on each other are still applied in a deterministic order, but that could involve changing the internals of the migrations library.

@candlerb commented on GitHub (Sep 7, 2024): See https://github.com/netbox-community/netbox/discussions/17379#discussioncomment-10576206 From that, it appears to be that migration dependencies haven't been declared properly, so they are applied in a non-deterministic order. Hence it works for some people and not for others. Making this something that could be reproduced would be difficult: I don't know what affects the order in which they're applied (e.g. the order in which the files were created in the directory?) It might be a good idea if the migrations were sorted by name, so that any which don't explicitly depend on each other are still applied in a deterministic order, but that could involve changing the internals of the migrations library.

adam commented

@avbor commented on GitHub (Sep 7, 2024):

Not sure about this.
Migration 0117_move_objectchange.py falls on 16f74f7b03/netbox/extras/migrations/0117_move_objectchange.py (L8)

i.e. all code up to 16f74f7b03/netbox/extras/migrations/0117_move_objectchange.py (L116) is executed normally.
We can see it in postgre log (ALTER TABLE, ALTER INDEX... etc).
But, when it comes to the update_content_types function a SELECT from an already deleted table happens (SELECT "extras_objectchange"."id",...).

But, I understand absolutely nothing about django and very little about python =(

@avbor commented on GitHub (Sep 7, 2024): Not sure about this. Migration `0117_move_objectchange.py` falls on https://github.com/netbox-community/netbox/blob/16f74f7b03092424554aa85e2043f434feeb807d/netbox/extras/migrations/0117_move_objectchange.py#L8 i.e. all code up to https://github.com/netbox-community/netbox/blob/16f74f7b03092424554aa85e2043f434feeb807d/netbox/extras/migrations/0117_move_objectchange.py#L116 is executed normally. We can see it in postgre log (ALTER TABLE, ALTER INDEX... etc). But, when it comes to the `update_content_types` function a SELECT from an already deleted table happens (`SELECT "extras_objectchange"."id",...`). But, I understand absolutely nothing about django and very little about python =(

adam commented

@avbor commented on GitHub (Sep 8, 2024):

Great suggestion about 0011_move_objectchange - https://github.com/netbox-community/netbox/discussions/17388#discussioncomment-10582898
In my case, in addition to deleting this entry, it was also necessary to delete the redis caches - https://github.com/netbox-community/netbox/discussions/17388#discussioncomment-10583097

After that, the netbox successfully updated and started up!

@avbor commented on GitHub (Sep 8, 2024): Great suggestion about 0011_move_objectchange - https://github.com/netbox-community/netbox/discussions/17388#discussioncomment-10582898 In my case, in addition to deleting this entry, it was also necessary to delete the redis caches - https://github.com/netbox-community/netbox/discussions/17388#discussioncomment-10583097 After that, the netbox successfully updated and started up!

adam commented

@amhn commented on GitHub (Sep 8, 2024):

As I said in the comment linked by @avbor the problem is that extras.0117_move_objectchange depends on core.0011_move_objectchange running in the same migration run. This would not be a problem, but core.0011_move_objectchange

is a state only migration, so only records the content type in the database
is the first migration running on an update from 4.0.9

If the second migration fails, the user is left with a state that is not recoverable without manual intervention. I do not know if it is possible to prevent the failure on the second run.

Reproduction:

Create database with netbox 4.0.9
Remove alter permission from netbox user
Checkout 4.1.0 and run migrations
This will fail but core.0011_move_objectchange is applied
Grant alter permission to netbox user
Run migrations (Keeps failing unless core.0011_move_objectchange is removed from django_migrations)

@amhn commented on GitHub (Sep 8, 2024): As I said in the comment linked by @avbor the problem is that extras.0117_move_objectchange depends on core.0011_move_objectchange running in the same migration run. This would not be a problem, but core.0011_move_objectchange - is a state only migration, so only records the content type in the database - is the first migration running on an update from 4.0.9 If the second migration fails, the user is left with a state that is not recoverable without manual intervention. I do not know if it is possible to prevent the failure on the second run. Reproduction: - Create database with netbox 4.0.9 - Remove alter permission from netbox user - Checkout 4.1.0 and run migrations - This will fail but core.0011_move_objectchange is applied - Grant alter permission to netbox user - Run migrations (Keeps failing unless core.0011_move_objectchange is removed from django_migrations)

adam commented

2025-12-29 21:28:11 +01:00

@candlerb commented on GitHub (Sep 9, 2024):

May or may not be related, but there is a reported dependency issue with core_configrevision in 0062_clear_secrets_changelog.py, see https://github.com/netbox-community/netbox/discussions/17412#discussioncomment-10588147

This is on a database being upgraded from v2.11.11 to v3.7.8 schema.

@candlerb commented on GitHub (Sep 9, 2024): May or may not be related, but there is a reported dependency issue with `core_configrevision` in `0062_clear_secrets_changelog.py`, see https://github.com/netbox-community/netbox/discussions/17412#discussioncomment-10588147 This is on a database being upgraded from v2.11.11 to v3.7.8 schema.

adam commented

@quantum909 commented on GitHub (Sep 10, 2024):

After the problem has been recognized and a manual fix is ready. What would be the best course of action now? Better to wait if it is possible to fix this problem with a future update. Or make the appropriate fixes yourself with the risk that future updates could cause problems again.

@quantum909 commented on GitHub (Sep 10, 2024): After the problem has been recognized and a manual fix is ready. What would be the best course of action now? Better to wait if it is possible to fix this problem with a future update. Or make the appropriate fixes yourself with the risk that future updates could cause problems again.

adam commented

2025-12-29 21:28:11 +01:00

@jeremystretch commented on GitHub (Sep 10, 2024):

What would be the best course of action now?

We still have not identified the source of the failure. As demonstrated above, upgrading from v4.0.11 to v4.1.0 does not reproduce the issue; at least not with Python 3.10 and PostgreSQL 14.

@amhn indicated in another thread that the initial failure was due to missing permissions:

On the first run there was a permission problem on the database, which caused extras.0117_move_objectchange to fail

It's not clear to me why this would be an issue if you're simply upgrading an existing database as suggested in the discussion above, as the necessary permissions should already be in place.

As for backing out core.0011_move_objectchange, you can run the management command manage.py migrate core 0010 to undo the application of the migration. However, it's also not clear why that would be necessary as each migration should be atomic AFAIK.

@jeremystretch commented on GitHub (Sep 10, 2024): > What would be the best course of action now? We still have not identified the source of the failure. As demonstrated [above](https://github.com/netbox-community/netbox/issues/17401#issuecomment-2334746401), upgrading from v4.0.11 to v4.1.0 does not reproduce the issue; at least not with Python 3.10 and PostgreSQL 14. @amhn [indicated in another thread](https://github.com/netbox-community/netbox/discussions/17388#discussioncomment-10582898) that the initial failure was due to missing permissions: > On the first run there was a permission problem on the database, which caused extras.0117_move_objectchange to fail It's not clear to me why this would be an issue if you're simply upgrading an existing database as suggested in the discussion above, as the necessary permissions should already be in place. As for backing out `core.0011_move_objectchange`, you can run the management command `manage.py migrate core 0010` to undo the application of the migration. However, it's also not clear why that would be necessary as each migration should be atomic AFAIK.

adam commented

2025-12-29 21:28:11 +01:00

@avbor commented on GitHub (Sep 10, 2024):

@amhn indicated in another thread that the initial failure was due to missing permissions:

I think it could be any of the problems in the migration process. For @amhn it was a permissions issue, for me I suspect it was a redis issue.
As a result, it turns out that in case of any problem interfering with the migration, we first of all get a non-obvious error ("extras_objectchange" does not exist), and secondly, even after solving this problem, we cannot move on without manual rollback core.0011_move_objectchange (direct in DB or through manage.py migrate core 0010).

@avbor commented on GitHub (Sep 10, 2024): > @amhn [indicated in another thread](https://github.com/netbox-community/netbox/discussions/17388#discussioncomment-10582898) that the initial failure was due to missing permissions: I think it could be any of the problems in the migration process. For @amhn it was a permissions issue, for me I suspect it was a redis issue. As a result, it turns out that in case of any problem interfering with the migration, we first of all get a non-obvious error ("extras_objectchange" does not exist), and secondly, even after solving this problem, we cannot move on without manual rollback core.0011_move_objectchange (direct in DB or through manage.py migrate core 0010).

adam commented

https://docs.djangoproject.com/en/5.1/ref/migration-operations/#separatedatabaseandstate

@amhn commented on GitHub (Sep 10, 2024):

I think the problem here is using SeparateDatabaseAndState:

If the actual state of the database and Django’s view of the state get out of sync, this can break the migration framework, even leading to data loss.

I think after the core.0011_move_objectchange state and database are out of sync. Because this migration created a new Model but no corresponding database change.

I do not know if there is a better way to move a model between apps. This one [https://realpython.com/move-django-model/#the-django-way-rename-the-table] suggests deleting the old object and renaming the table in the first part of the migration.

Since this is triggered by a misconfiguration of the database or in the netbox-docker case of the redis/valkey service, it might not be worth the effort to fix it. Plain upgrades should just work.

@avbor I also hit the redis/valkey issue, although I could not reproduce it without netbox-docker, even after stopping the redis server I was using for the replication of this issue.

@amhn commented on GitHub (Sep 10, 2024): I think the problem here is using SeparateDatabaseAndState: > If the actual state of the database and Django’s view of the state get out of sync, this can break the migration framework, even leading to data loss. https://docs.djangoproject.com/en/5.1/ref/migration-operations/#separatedatabaseandstate I think after the `core.0011_move_objectchange ` state and database are out of sync. Because this migration created a new Model but no corresponding database change. I do not know if there is a better way to move a model between apps. This one [https://realpython.com/move-django-model/#the-django-way-rename-the-table] suggests deleting the old object and renaming the table in the first part of the migration. Since this is triggered by a misconfiguration of the database or in the netbox-docker case of the redis/valkey service, it might not be worth the effort to fix it. Plain upgrades should just work. @avbor I also hit the redis/valkey issue, although I could not reproduce it without netbox-docker, even after stopping the redis server I was using for the replication of this issue.

adam commented

@avbor commented on GitHub (Sep 10, 2024):

I also hit the redis/valkey issue, although I could not reproduce it without netbox-docker, even after stopping the redis server I was using for the replication of this issue.

Maybe the root of the problem here is replacing redis with valkey.
But I still see some incorrectness here, no matter what kind of problem happened in the process, but even after solving it, it is impossible to continue the update\migration without manual intervention.
And the errors that are generated make the situation even more confusing, at least for me =)

@avbor commented on GitHub (Sep 10, 2024): > I also hit the redis/valkey issue, although I could not reproduce it without netbox-docker, even after stopping the redis server I was using for the replication of this issue. Maybe the root of the problem here is replacing redis with valkey. But I still see some incorrectness here, no matter what kind of problem happened in the process, but even after solving it, it is impossible to continue the update\migration without manual intervention. And the errors that are generated make the situation even more confusing, at least for me =)

adam commented

@FrankPGH commented on GitHub (Sep 10, 2024):

@amhn indicated in another thread that the initial failure was due to missing permissions:

On the first run there was a permission problem on the database, which caused extras.0117_move_objectchange to fail

It's not clear to me why this would be an issue if you're simply upgrading an existing database as suggested in the discussion above, as the necessary permissions should already be in place.

Just want to point out that I experienced that permissions issue with the public schema and never had it before. 4.0.10 was working perfectly for me, the install is bog standard, and no permissions should have changed prior to performing the upgrade.

@FrankPGH commented on GitHub (Sep 10, 2024): > @amhn [indicated in another thread](https://github.com/netbox-community/netbox/discussions/17388#discussioncomment-10582898) that the initial failure was due to missing permissions: > > > On the first run there was a permission problem on the database, which caused extras.0117_move_objectchange to fail > > It's not clear to me why this would be an issue if you're simply upgrading an existing database as suggested in the discussion above, as the necessary permissions should already be in place. Just want to point out that I experienced that [permissions issue ](https://github.com/netbox-community/netbox/discussions/17388#discussion-7142192) with the public schema and never had it before. 4.0.10 was working perfectly for me, the install is bog standard, and no permissions should have changed prior to performing the upgrade.

adam commented

2025-12-29 21:28:13 +01:00

@mikygee commented on GitHub (Sep 10, 2024):

Hello,

I don't understand what you did to solve the problem.

I did

delete from django_migrations WHERE name='0011_move_objectchange';

Flushed the redis cache

manage.py migrate core 0010

Nothing worked for me.

@mikygee commented on GitHub (Sep 10, 2024): Hello, I don't understand what you did to solve the problem. I did `delete from django_migrations WHERE name='0011_move_objectchange';` Flushed the redis cache `manage.py migrate core 0010` Nothing worked for me.

adam commented

@rfdrake commented on GitHub (Sep 11, 2024):

Here is what I did to get this working again:

# stop all processes
docker-compose down
# bring up postgres
docker-compose up postgres
docker volume ls | grep redis
# remove the redis volumes listed above.
docker volume rm beta_netbox-redis-cache-data beta_netbox-redis-data
# connect to psql client
docker-compose exec postgres sh -c 'psql -U $POSTGRES_USER $POSTGRES_DB'
# run the following two commands in the shell
DELETE from django_migrations WHERE name='0011_move_objectchange';
GRANT ALL ON SCHEMA public TO netbox;
# quit the shell
\q
# start all processes in the foreground to watch the migration
docker-compose up

The redis changes are probably only needed if you're using docker. The switch from redis to valkey causes the database to be different. It might be good to check the status of redis connectivity before the migration as a way to defend against this.

Or something can watch for errors like these:

netbox-redis         | 1:M 08 Sep 2024 16:11:22.284 * Reading RDB base file on AOF loading...
netbox-redis         | 1:M 08 Sep 2024 16:11:22.284 # Can't handle RDB format version 12
netbox-redis         | 1:M 08 Sep 2024 16:11:22.284 # Error reading the RDB base file appendonly.aof.65.base.rdb, AOF loading aborted

@rfdrake commented on GitHub (Sep 11, 2024): Here is what I did to get this working again: ``` # stop all processes docker-compose down # bring up postgres docker-compose up postgres docker volume ls | grep redis # remove the redis volumes listed above. docker volume rm beta_netbox-redis-cache-data beta_netbox-redis-data # connect to psql client docker-compose exec postgres sh -c 'psql -U $POSTGRES_USER $POSTGRES_DB' # run the following two commands in the shell DELETE from django_migrations WHERE name='0011_move_objectchange'; GRANT ALL ON SCHEMA public TO netbox; # quit the shell \q # start all processes in the foreground to watch the migration docker-compose up ``` The redis changes are probably only needed if you're using docker. The switch from redis to valkey causes the database to be different. It might be good to check the status of redis connectivity before the migration as a way to defend against this. Or something can watch for errors like these: ``` netbox-redis | 1:M 08 Sep 2024 16:11:22.284 * Reading RDB base file on AOF loading... netbox-redis | 1:M 08 Sep 2024 16:11:22.284 # Can't handle RDB format version 12 netbox-redis | 1:M 08 Sep 2024 16:11:22.284 # Error reading the RDB base file appendonly.aof.65.base.rdb, AOF loading aborted ```

adam commented

2025-12-29 21:28:13 +01:00

@mikygee commented on GitHub (Sep 12, 2024):

Hello Robert,
It didn't work for me. Also I don't user docker.
I made a database restauration and restarted the upgrarde process up to 4.0.11

@mikygee commented on GitHub (Sep 12, 2024): Hello Robert, It didn't work for me. Also I don't user docker. I made a database restauration and restarted the upgrarde process up to 4.0.11

adam commented

2025-12-29 21:28:13 +01:00

@KaleBrink commented on GitHub (Sep 12, 2024):

I have the same problem. Upgrade from 4.0.11 to 4.1.0 using the steps from the Netbox documentation, Below the error from the upgrade.

Running migrations:
  Applying core.0011_move_objectchange... OK
  Applying extras.0117_move_objectchange... OK
  Applying extras.0118_customfield_uniqueness... OK
  Applying extras.0119_notifications... OK
  Applying circuits.0044_circuit_groups... OK
  Applying core.0012_job_object_type_optional... OK
  Applying extras.0120_eventrule_event_types... OK
  Applying extras.0121_customfield_related_object_filter... OK
  Applying dcim.0188_racktype... OK
  Applying dcim.0189_moduletype_rack_airflow... OK
  Applying dcim.0190_nested_modules... OK
  Applying ipam.0070_vlangroup_vlan_id_ranges... OK
  Applying virtualization.0039_virtualmachine_serial_number... OK
  Applying virtualization.0040_convert_disk_size...Traceback (most recent call last):
  File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/db/backends/utils.py", line 105, in _execute
    return self.cursor.execute(sql, params)
  File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/psycopg/cursor.py", line 97, in execute
    raise ex.with_traceback(None)
psycopg.errors.NumericValueOutOfRange: integer out of range

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/opt/netbox-4.1.0/netbox/manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/core/management/__init__.py", line 442, in execute_from_command_line
    utility.execute()
  File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/core/management/__init__.py", line 436, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/core/management/base.py", line 413, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/core/management/base.py", line 459, in execute
    output = self.handle(*args, **options)
  File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/core/management/base.py", line 107, in wrapper
    res = handle_func(*args, **kwargs)
  File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/core/management/commands/migrate.py", line 356, in handle
    post_migrate_state = executor.migrate(
  File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/db/migrations/executor.py", line 135, in migrate
    state = self._migrate_all_forwards(
  File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/db/migrations/executor.py", line 167, in _migrate_all_forwards
    state = self.apply_migration(
  File "/opt/netbox-4.1.0/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-4.1.0/venv/lib/python3.10/site-packages/django/db/migrations/migration.py", line 132, in apply
    operation.database_forwards(
  File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/db/migrations/operations/special.py", line 193, in database_forwards
    self.code(from_state.apps, schema_editor)
  File "/opt/netbox-4.1.0/netbox/virtualization/migrations/0040_convert_disk_size.py", line 7, in convert_disk_size
    VirtualMachine.objects.filter(disk__isnull=False).update(disk=F('disk') * 1000)
  File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/db/models/query.py", line 1253, in update
    rows = query.get_compiler(self.db).execute_sql(CURSOR)
  File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/db/models/sql/compiler.py", line 1990, in execute_sql
    cursor = super().execute_sql(result_type)
  File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/db/models/sql/compiler.py", line 1562, in execute_sql
    cursor.execute(sql, params)
  File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/db/backends/utils.py", line 79, in execute
    return self._execute_with_wrappers(
  File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/db/backends/utils.py", line 92, in _execute_with_wrappers
    return executor(sql, params, many, context)
  File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/db/backends/utils.py", line 100, in _execute
    with self.db.wrap_database_errors:
  File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/db/utils.py", line 91, in __exit__
    raise dj_exc_value.with_traceback(traceback) from exc_value
  File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/db/backends/utils.py", line 105, in _execute
    return self.cursor.execute(sql, params)
  File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/psycopg/cursor.py", line 97, in execute
    raise ex.with_traceback(None)
django.db.utils.DataError: integer out of range

And from the postgres log.

2024-09-12 16:34:03.219 UTC [3939] netbox@netbox ERROR:  integer out of range
2024-09-12 16:34:03.219 UTC [3939] netbox@netbox STATEMENT:  UPDATE "virtualization_virtualmachine" SET "disk" = ("virtualization_virtualmachine"."disk" * 1000) WHERE "virtualization_virtualmachine"."disk" IS NOT NULL

Only difference is the Python version used. I have python 3.10

@KaleBrink commented on GitHub (Sep 12, 2024): I have the same problem. Upgrade from 4.0.11 to 4.1.0 using the steps from the Netbox documentation, Below the error from the upgrade. ```python Running migrations: Applying core.0011_move_objectchange... OK Applying extras.0117_move_objectchange... OK Applying extras.0118_customfield_uniqueness... OK Applying extras.0119_notifications... OK Applying circuits.0044_circuit_groups... OK Applying core.0012_job_object_type_optional... OK Applying extras.0120_eventrule_event_types... OK Applying extras.0121_customfield_related_object_filter... OK Applying dcim.0188_racktype... OK Applying dcim.0189_moduletype_rack_airflow... OK Applying dcim.0190_nested_modules... OK Applying ipam.0070_vlangroup_vlan_id_ranges... OK Applying virtualization.0039_virtualmachine_serial_number... OK Applying virtualization.0040_convert_disk_size...Traceback (most recent call last): File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/db/backends/utils.py", line 105, in _execute return self.cursor.execute(sql, params) File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/psycopg/cursor.py", line 97, in execute raise ex.with_traceback(None) psycopg.errors.NumericValueOutOfRange: integer out of range The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/opt/netbox-4.1.0/netbox/manage.py", line 10, in <module> execute_from_command_line(sys.argv) File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/core/management/__init__.py", line 442, in execute_from_command_line utility.execute() File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/core/management/__init__.py", line 436, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/core/management/base.py", line 413, in run_from_argv self.execute(*args, **cmd_options) File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/core/management/base.py", line 459, in execute output = self.handle(*args, **options) File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/core/management/base.py", line 107, in wrapper res = handle_func(*args, **kwargs) File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/core/management/commands/migrate.py", line 356, in handle post_migrate_state = executor.migrate( File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/db/migrations/executor.py", line 135, in migrate state = self._migrate_all_forwards( File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/db/migrations/executor.py", line 167, in _migrate_all_forwards state = self.apply_migration( File "/opt/netbox-4.1.0/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-4.1.0/venv/lib/python3.10/site-packages/django/db/migrations/migration.py", line 132, in apply operation.database_forwards( File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/db/migrations/operations/special.py", line 193, in database_forwards self.code(from_state.apps, schema_editor) File "/opt/netbox-4.1.0/netbox/virtualization/migrations/0040_convert_disk_size.py", line 7, in convert_disk_size VirtualMachine.objects.filter(disk__isnull=False).update(disk=F('disk') * 1000) File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/db/models/query.py", line 1253, in update rows = query.get_compiler(self.db).execute_sql(CURSOR) File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/db/models/sql/compiler.py", line 1990, in execute_sql cursor = super().execute_sql(result_type) File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/db/models/sql/compiler.py", line 1562, in execute_sql cursor.execute(sql, params) File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/db/backends/utils.py", line 79, in execute return self._execute_with_wrappers( File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/db/backends/utils.py", line 92, in _execute_with_wrappers return executor(sql, params, many, context) File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/db/backends/utils.py", line 100, in _execute with self.db.wrap_database_errors: File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/db/utils.py", line 91, in __exit__ raise dj_exc_value.with_traceback(traceback) from exc_value File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/django/db/backends/utils.py", line 105, in _execute return self.cursor.execute(sql, params) File "/opt/netbox-4.1.0/venv/lib/python3.10/site-packages/psycopg/cursor.py", line 97, in execute raise ex.with_traceback(None) django.db.utils.DataError: integer out of range ``` And from the postgres log. ```python 2024-09-12 16:34:03.219 UTC [3939] netbox@netbox ERROR: integer out of range 2024-09-12 16:34:03.219 UTC [3939] netbox@netbox STATEMENT: UPDATE "virtualization_virtualmachine" SET "disk" = ("virtualization_virtualmachine"."disk" * 1000) WHERE "virtualization_virtualmachine"."disk" IS NOT NULL ``` Only difference is the Python version used. I have python 3.10

adam commented

@mmahacek commented on GitHub (Sep 12, 2024):

@rfdrake Your steps worked perfectly to fix my netbox-docker upgrade from 4.0.11 -> 4.1.0. Thanks!

@mmahacek commented on GitHub (Sep 12, 2024): @rfdrake Your steps worked perfectly to fix my netbox-docker upgrade from 4.0.11 -> 4.1.0. Thanks!

adam commented

@FrankPGH commented on GitHub (Sep 13, 2024):

I was finally able to successfully upgrade from 4.0.11 to 4.1.1 by fixing the broken permissions prior to running upgrade.sh.
https://github.com/netbox-community/netbox/discussions/17388#discussioncomment-10638981

@FrankPGH commented on GitHub (Sep 13, 2024): I was finally able to successfully upgrade from 4.0.11 to 4.1.1 by fixing the broken permissions prior to running upgrade.sh. https://github.com/netbox-community/netbox/discussions/17388#discussioncomment-10638981

adam commented

@kovacs-andras commented on GitHub (Sep 16, 2024):

Here is what I did to get this working again:

# stop all processes
docker-compose down
# bring up postgres
docker-compose up postgres
docker volume ls | grep redis
# remove the redis volumes listed above.
docker volume rm beta_netbox-redis-cache-data beta_netbox-redis-data
# connect to psql client
docker-compose exec postgres sh -c 'psql -U $POSTGRES_USER $POSTGRES_DB'
# run the following two commands in the shell
DELETE from django_migrations WHERE name='0011_move_objectchange';
GRANT ALL ON SCHEMA public TO netbox;
# quit the shell
\q
# start all processes in the foreground to watch the migration
docker-compose up

The redis changes are probably only needed if you're using docker. The switch from redis to valkey causes the database to be different. It might be good to check the status of redis connectivity before the migration as a way to defend against this.

Or something can watch for errors like these:

netbox-redis         | 1:M 08 Sep 2024 16:11:22.284 * Reading RDB base file on AOF loading...
netbox-redis         | 1:M 08 Sep 2024 16:11:22.284 # Can't handle RDB format version 12
netbox-redis         | 1:M 08 Sep 2024 16:11:22.284 # Error reading the RDB base file appendonly.aof.65.base.rdb, AOF loading aborted

It worked! Very many thanks! 🥇

@kovacs-andras commented on GitHub (Sep 16, 2024): > Here is what I did to get this working again: > > ``` > # stop all processes > docker-compose down > # bring up postgres > docker-compose up postgres > docker volume ls | grep redis > # remove the redis volumes listed above. > docker volume rm beta_netbox-redis-cache-data beta_netbox-redis-data > # connect to psql client > docker-compose exec postgres sh -c 'psql -U $POSTGRES_USER $POSTGRES_DB' > # run the following two commands in the shell > DELETE from django_migrations WHERE name='0011_move_objectchange'; > GRANT ALL ON SCHEMA public TO netbox; > # quit the shell > \q > # start all processes in the foreground to watch the migration > docker-compose up > ``` > > The redis changes are probably only needed if you're using docker. The switch from redis to valkey causes the database to be different. It might be good to check the status of redis connectivity before the migration as a way to defend against this. > > Or something can watch for errors like these: > > ``` > netbox-redis | 1:M 08 Sep 2024 16:11:22.284 * Reading RDB base file on AOF loading... > netbox-redis | 1:M 08 Sep 2024 16:11:22.284 # Can't handle RDB format version 12 > netbox-redis | 1:M 08 Sep 2024 16:11:22.284 # Error reading the RDB base file appendonly.aof.65.base.rdb, AOF loading aborted > ``` It worked! Very many thanks! :1st_place_medal:

adam commented

@Cbrad24 commented on GitHub (Sep 18, 2024):

@KaleBrink had the same issue, NumericValueOutOfRange: integer out of range. For me I had to go into my Postgres DB and null out the value of the disk column for one particular Virtual Machine in the table virtualization_virtualmachine that had a very large integer value, and when Netbox was multiplying it by 1,000 the value was overflowing the maximum value.

@Cbrad24 commented on GitHub (Sep 18, 2024): @KaleBrink had the same issue, `NumericValueOutOfRange: integer out of range`. For me I had to go into my Postgres DB and null out the value of the `disk` column for one particular Virtual Machine in the table `virtualization_virtualmachine` that had a very large integer value, and when Netbox was multiplying it by 1,000 the value was overflowing the maximum value.

adam commented