v3 migration and switching repos

[lnlyssg]

I carried out the v2 migration last year and I've just followed the steps at v2 to v3 migration and I'm now running with the latest Pixelfed version in Docker OK. However I'd also like to switch to this repo given it's slimmed down and also contains useful scripts for future updates. How can I cleanly move from https://github.com/pixelfed/ to this repo without breaking anything?

In addition I spotted that many of the v2 steps at https://jippi.github.io/docker-pixelfed/migrate/v2.0/ are broken now as the repos have changed.

[jippi]

I think the only files you would need is your .env file and your docker-compose-state directory

I would recommend cloning this repo into a new path, copy the files over, and test it out without affecting your existing installation

If this work, we can add it to the documentation for future reference :)

[lnlyssg]

Partial success.... I had permissions issues trying to start it up the first time so added DOCKER_APP_ENSURE_OWNERSHIP_PATHS="./storage ./bootstrap" to my .env. The permissions script has run OK:

[entrypoint / entrypoint.sh] - ============================================================
[entrypoint / entrypoint.sh] - Executing [/docker/entrypoint.d/01-permissions.sh]
[entrypoint / entrypoint.sh] - ============================================================
[entrypoint / 01-permissions.sh] - 👷 Running [chown --verbose 33:33 ./.env] as [root]
[entrypoint / 01-permissions.sh] - (stdout) ownership of './.env' retained as www-data:www-data
[entrypoint / 01-permissions.sh] - ✅ OK!
[entrypoint / 01-permissions.sh] - 👷 Running [chown --verbose 33:33 ./bootstrap/cache] as [root]
[entrypoint / 01-permissions.sh] - (stdout) ownership of './bootstrap/cache' retained as www-data:www-data
[entrypoint / 01-permissions.sh] - ✅ OK!
[entrypoint / 01-permissions.sh] - 👷 Running [chown --verbose 33:33 ./storage] as [root]
[entrypoint / 01-permissions.sh] - (stdout) ownership of './storage' retained as www-data:www-data
[entrypoint / 01-permissions.sh] - ✅ OK!
[entrypoint / 01-permissions.sh] - 👷 Running [chown --verbose --recursive 33:33 ./storage/docker] as [root]
[entrypoint / 01-permissions.sh] - (stdout) ownership of './storage/docker/once/initial:migrate' retained as www-data:www-data
[entrypoint / 01-permissions.sh] - (stdout) ownership of './storage/docker/once/key:generate' retained as www-data:www-data
[entrypoint / 01-permissions.sh] - (stdout) ownership of './storage/docker/once/instance:actor' retained as www-data:www-data
[entrypoint / 01-permissions.sh] - (stdout) ownership of './storage/docker/once/storage:link' retained as www-data:www-data
[entrypoint / 01-permissions.sh] - (stdout) ownership of './storage/docker/once/import:cities' retained as www-data:www-data
[entrypoint / 01-permissions.sh] - (stdout) ownership of './storage/docker/once' retained as www-data:www-data
[entrypoint / 01-permissions.sh] - No paths has been configured for ownership fixes via [$DOCKER_APP_ENSURE_OWNERSHIP_PATHS].
[entrypoint / 01-permissions.sh] - (stdout) ownership of './storage/docker/lock/entrypoint.sh' retained as www-data:www-data
[entrypoint / 01-permissions.sh] - (stdout) ownership of './storage/docker/lock' retained as www-data:www-data
[entrypoint / 01-permissions.sh] - (stdout) ownership of './storage/docker' retained as www-data:www-data
[entrypoint / 01-permissions.sh] - ✅ OK!

but I'm still getting permissions errors:

[entrypoint / entrypoint.sh] - ============================================================
[entrypoint / entrypoint.sh] - Executing [/docker/entrypoint.d/10-storage.sh]
[entrypoint / entrypoint.sh] - ============================================================
[entrypoint / 10-storage.sh] - 👷 Running [cp --force --recursive storage.skel/. ./storage/] as [www-data]
[entrypoint / 10-storage.sh] - (stderr) cp: cannot remove './storage/./app/.gitignore': Permission denied
[entrypoint / 10-storage.sh] - (stderr) cp: cannot remove './storage/./app/cities.json': Permission denied
[entrypoint / 10-storage.sh] - (stderr) cp: cannot remove './storage/./app/backups/.gitignore': Permission denied
[entrypoint / 10-storage.sh] - (stderr) cp: cannot remove './storage/./app/bouncer/.gitignore': Permission denied
[entrypoint / 10-storage.sh] - (stderr) cp: cannot remove './storage/./app/bouncer/all.json': Permission denied
[entrypoint / 10-storage.sh] - (stderr) cp: cannot remove './storage/./app/nlp/.gitignore': Permission denied
[entrypoint / 10-storage.sh] - (stderr) cp: cannot remove './storage/./app/public/.gitignore': Permission denied
[entrypoint / 10-storage.sh] - (stderr) cp: cannot remove './storage/./app/public/no-preview.png': Permission denied

Looks like the permissions script has only changed the top level permissions?

[lnlyssg]

I fixed the permissions manually but the DB container has problems now:

2025-01-15 15:49:01+00:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:11.2.6+maria~ubu2204 started.
2025-01-15 15:49:01+00:00 [Warn] [Entrypoint]: /sys/fs/cgroup///memory.pressure not writable, functionality unavailable to MariaDB
2025-01-15 15:49:01+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
2025-01-15 15:49:01+00:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:11.2.6+maria~ubu2204 started.
2025-01-15 15:49:01+00:00 [Note] [Entrypoint]: MariaDB upgrade information missing, assuming required
2025-01-15 15:49:01+00:00 [Note] [Entrypoint]: MariaDB upgrade (mariadb-upgrade or creating healthcheck users) required, but skipped due to $MARIADB_AUTO_UPGRADE setting
2025-01-15 15:49:02 0 [Note] Starting MariaDB 11.2.6-MariaDB-ubu2204 source revision 67c0fd2a41034eae1ea04b81cace6a154783aedd server_uid Brg8aPVcQzkIFFlAiqFGmzlRSgU= as process 1
2025-01-15 15:49:02 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2025-01-15 15:49:02 0 [Note] InnoDB: Number of transaction pools: 1
2025-01-15 15:49:02 0 [Note] InnoDB: Using ARMv8 crc32 + pmull instructions
2025-01-15 15:49:02 0 [Note] mariadbd: O_TMPFILE is not supported on /tmp (disabling future attempts)
2025-01-15 15:49:02 0 [Warning] mariadbd: io_uring_queue_init() failed with errno 1
2025-01-15 15:49:02 0 [Warning] InnoDB: liburing disabled: falling back to innodb_use_native_aio=OFF
2025-01-15 15:49:02 0 [Note] InnoDB: Initializing buffer pool, total size = 128.000MiB, chunk size = 2.000MiB
2025-01-15 15:49:02 0 [Note] InnoDB: Completed initialization of buffer pool
2025-01-15 15:49:02 0 [Note] InnoDB: File system buffers for log disabled (block size=4096 bytes)
2025-01-15 15:49:02 0 [Note] InnoDB: Resetting space id's in the doublewrite buffer
2025-01-15 15:49:02 0 [Note] InnoDB: End of log at LSN=136808384
2025-01-15 15:49:02 0 [Note] InnoDB: Opened 3 undo tablespaces
2025-01-15 15:49:02 0 [Note] InnoDB: 128 rollback segments in 3 undo tablespaces are active.
2025-01-15 15:49:02 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ...
2025-01-15 15:49:02 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB.
2025-01-15 15:49:02 0 [Note] InnoDB: log sequence number 136808384; transaction id 29138
2025-01-15 15:49:02 0 [Note] Plugin 'FEEDBACK' is disabled.
2025-01-15 15:49:02 0 [Note] Plugin 'wsrep-provider' is disabled.
2025-01-15 15:49:02 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
2025-01-15 15:49:02 0 [Warning] 'default-authentication-plugin' is MySQL 5.6 / 5.7 compatible option. To be implemented in later versions.
2025-01-15 15:49:02 0 [Note] Recovering after a crash using tc.log
2025-01-15 15:49:02 0 [ERROR] Bad magic header in tc log
2025-01-15 15:49:02 0 [ERROR] Crash recovery failed. Either correct the problem (if it's, for example, out of memory error) and restart, or delete tc log and start server with --tc-heuristic-recover={commit|rollback}
2025-01-15 15:49:02 0 [ERROR] Can't init tc log
2025-01-15 15:49:02 0 [ERROR] Aborting

[lnlyssg]

I deleted docker-compose-state/data/db/tc.log and that seems to have fixed it, all up and running now. Not sure if that was caused by my copy of docker-compose-state or one of the earlier failed starts with permissions issues though.

[jippi]

Did you shut off the other containers before copying? might have been a lock file from the DB :)

[lnlyssg]

I think I did but hard to say for certain. In any case I think the only real issue I had was the permissions - could the 01-permissions.sh script be made recursive?

[jippi]

The reason why it's not recursive is that, depending on the configuration, you can have millions of files (uploads, emojis, etc.) in the storage folder, which could take minutes to check/change permissions on, which would significantly trash startup time and disk caches.

You did find the escape-hatch correctly that allow you to opt-in to a recursive model though :)

[lnlyssg]

Fair point. Maybe a step can be added to the instructions that mentions this possibility and action required?