Update loop during update to 29

Nextcloud version (eg, 29.0.5): 29.0.1.1 (docker fpm-alpine)
Operating system and version (eg, Ubuntu 29.04): Debian bullseye
PHP version (eg, 8.3): <pre>8.2.20</pre>

The issue you are facing:
After updating the docker container from 28 to 29 I am stuck in an update loop. Normally I update using the web frontend. When accessing it it looks like this:

after refresh it looks lke this and then alternates between those two screens after every refresh:

When updating using occ upgrade this is the verbose log. However there are no errors. And the update seems to have been successfull. The frontend looks the same though.

Is this the first time you’ve seen this error? (Y/N):Y

Steps to replicate it:
no clue

The output of your Nextcloud log in Admin > Logging:

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php
$CONFIG = array (
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'apps_paths' => 
  array (
    0 => 
    array (
      'path' => '/var/www/html/apps',
      'url' => '/apps',
      'writable' => false,
    ),
    1 => 
    array (
      'path' => '/var/www/html/custom_apps',
      'url' => '/custom_apps',
      'writable' => true,
    ),
  ),
  'instanceid' => 'xxx',
  'passwordsalt' => 'xxx',
  'secret' => 'xxx',
  'trusted_domains' => 
  array (
    0 => '10.13.5.1',
  ),
  'datadirectory' => '/var/www/html/data',
  'dbtype' => 'mysql',
  'version' => '29.0.1.1',
  'overwrite.cli.url' => 'http://10.13.5.1',
  'dbname' => 'nextcloud',
  'dbhost' => 'db',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'nextcloud',
  'dbpassword' => 'xxx',
  'installed' => true,
  'maintenance' => false,
  'loglevel' => 0,
  'theme' => '',
  'app_install_overwrite' => 
  array (
    0 => 'richdocumentscode',
  ),
  'maintenance_window_start' => 0,
  'upgrade.disable-web' => true,
);

Can you elaborate on how, precisely, you triggered the update from 28->29?

I’m confused because your config suggests you’re likely using the micro-services Docker image, but the normal Updater is never used with that.

Please post your Docker Compose file.

To update, I edit the tag for nextcloud in my docker-compose file. I did it like that for 2 years now. Here’s my compose file:

version: '3'

services:
  db:
    image: mariadb:10.6
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
    restart: always
    volumes:
      - db:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=redacted
      - MARIADB_AUTO_UPGRADE=1
      - MARIADB_DISABLE_UPGRADE_BACKUP=1
    env_file:
      - db.env


  app:
    image: nextcloud:29-fpm-alpine
    restart: always
    volumes:
      - nextcloud:/var/www/html
    environment:
      - MYSQL_HOST=db
    env_file:
      - db.env
    depends_on:
      - db

  web:
    build: ./web
    restart: always
    ports:
      - 80:80
      - 443:443
    volumes:
      - nextcloud:/var/www/html:ro
    depends_on:
      - app


  cron:
    image: nextcloud:fpm-alpine
    restart: always
    volumes:
      - nextcloud:/var/www/html
    entrypoint: /cron.sh
    depends_on:
      - db

volumes:
  db:
  nextcloud:

networks:
  default:
    name: external-nextcloud
    external: true

One problem you have is different images/image upgrade cycles here. These two containers must be exactly the same. Their tags should be in sync.

It happens that at the moment this would point to the same image, but until you bumped your app container to 29, technically your cron container would have been upgraded to 29 sooner. Though when using cron.php as the entry point, the upgrader is bypassed… So I’d have to think a bit to even consider what state your cron container would find itself in under these circumstances. :thinking:

Anyhow, the upgrade of the app container is handled through the image’s entry point. The logs that would be most of interest would be the app container Docker log.

Your config shows you’re updated. So maybe something got confused given the above.

And then do a docker compose pull and docker compose up -d, correct?

After editing the compose file I do a pull followed by down and up -d yes. Can share more logs tomorrow.