Is There Already a Safe Upgrade Guide from Debian 12 to Debian 13?

Discussion in 'Installation/Configuration' started by Marcio Urakawa, May 8, 2026.

  1. Has anyone already tested a reliable and secure migration process from Debian 12 (Bookworm) to Debian 13 (Trixie)?
     
    Last edited: May 8, 2026
    muelli75 likes this.
  2. After upgrading a server with ISPConfig from Debian 12 (Bookworm) to Debian 13 (Trixie), Apache failed to start with this error:

    Cannot load /usr/lib/apache2/modules/mod_python.so
    The issue was caused by an old mod_python configuration left enabled after the upgrade, even though the module is no longer available/supported.
    No websites or ISPConfig services were using mod_python.
    Fix:

    sudo a2dismod python
    sudo apachectl configtest
    sudo systemctl restart apache2

    After disabling the obsolete module, Apache and ISPConfig worked normally again.
     
    theTJ, ahrasis, Taleman and 1 other person like this.
  3. DavT

    DavT New Member

    We ran into similar issues migrating 9 production sites from a bare LAMP stack to ISPConfig on a fresh Debian 13 VPS (rather than upgrading in-place). The mod_python issue you describe is a good example of why we chose a clean install over an upgrade path.

    We open sourced the scripts we used, including pre-flight checks, ISPConfig API-based site creation with retry logic, PHP version assignment per site, and CSF setup. You can find it by searching GitHub for hydtie/ispconfig-migrate.

    One thing worth adding to your mod_python fix: before restarting Apache, run apache2ctl -M to check for any other deprecated modules that survived the Debian 12-to-13 upgrade. We found a few surprises that way.
     
    ahrasis likes this.
  4. brainsys

    brainsys Active Member

    I did a test upgrade of an ISPConfig server from Bookworm to Trixie. Following advice I did the OS upgrade first , rebooted and did a forced ISPConfig upgrade. To my delight the problematic Roundcube issue looked fine.

    I then proceeded to tidy-up the long list of obsolete PHP versions. Aaaargh! Roundcube failed!

    Restoring the VM (how I love Proxmox) I did the upgrade again. I then deleted the PHP versions one by one to discover 8.2 was the culprit. Re-installing php8.2 didn't bring Roundcube back. Hence my plan for production servers is to leave 7.4 & 8.2 in place. What puzzles me is why, when the Trixie default is 8.4 and the Bookworm default was 7.4 that Roundcube had an 8.2 dependency?

    Any other weird dependencies on a default install/upgrade I should be aware of?
     
  5. pyte

    pyte Well-Known Member HowtoForge Supporter

    Usually upgrades and installations are well tested. In some cases however, certain issues may be overlooked, or your specific system may have packages or configurations that differ from those of other users. That said I've never experienced anything critical breaking.

    In the case of your Roundcube installation, you could simply have checked the logs to identify the issue. From there you could either configure Roundcube to use a different PHP version or reinstall the previous PHP version if necessary.
     
  6. brainsys

    brainsys Active Member

    The beauty of a test VM is that if you spot an issue you can just roll back and avoid it. Much easier, quicker and safer than trying to solve a dependency you don't need to. I really posted in this thread to make other Trixie upgraders aware of this potential Roundcube issue so they can avoid it too by simply leaving php8.2 in place. Not a big deal. Tidying up can have a price.

    The question I leave is for fellow upgraders is to share other potential issues as those above did about python. I may point out the this was a recent auto-install default Bookworm ISPConfig. Nothing special. Hence any issues are probably generic.
     

Share This Page