Ubuntu 24.04 upgraden naar 26.04 op een VPS

Wanneer kunt u Ubuntu 24.04 upgraden naar 26.04?

U kunt Ubuntu 24.04 op een VPS upgraden naar 26.04 zodra de 26.04.1 point release verschijnt, gepland voor 27 augustus 2026. Tot die tijd zal een 24.04-server de nieuwe release bewust niet zien. Ubuntu 26.04 LTS (Resolute Raccoon) werd uitgebracht op 23 april 2026, maar Canonical stelt het upgradepad van LTS naar LTS pas open bij de eerste point release. Deze release bevat namelijk alle installatie- en upgradefouten die in de eerste maanden zijn gevonden. Als de nummering nieuw voor u is: 26.04.1 is geen andere versie van Ubuntu, maar dezelfde 26.04 met vier maanden aan correcties verwerkt in de media. Dit is precies de reden waarom dit de eerste versie is die Canonical aanbiedt aan een bestaande server.

Voer de controle uit op een 24.04-machine begin augustus 2026 en u krijgt dit resultaat:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

Dat is geen fout op uw server. /etc/update-manager/release-upgrades bevat op Ubuntu Server Prompt=lts. Dit betekent dat de tool alleen de volgende long-term-supportrelease aanbiedt, en pas wanneer de .1-pointrelease daarvan beschikbaar is. Als u Prompt=normal instelt, leidt de tool u achtereenvolgens door 24.10, 25.04 en 25.10. Dit zijn interim-releases die allemaal het einde van hun levensduur hebben bereikt. Laat de instelling op lts staan en wacht. Datums in de planning van Canonical kunnen wijzigen. Controleer dit daarom opnieuw als de datum verstrijkt zonder dat er iets gebeurt. Een server waarop nog 22.04 draait, kan deze stap niet rechtstreeks uitvoeren. De upgrader biedt namelijk altijd alleen de volgende LTS aan. Daarom behandelt upgraden van 22.04 naar 26.04 via 24.04 de eerste stap en de snapshot die u vóór de tweede stap moet maken.

Elk onderstaand commando voert u zelf uit op uw eigen server, in de opgegeven volgorde. Een release-upgrade kan niet worden geoefend op de machine die u aan het upgraden bent. Het proces vervangt de kernel en de C-library, en vereist een herstart om te voltooien.

Is upgraden überhaupt nodig?

Ubuntu 24.04 ontvangt standaard beveiligingsupdates tot 2029, dus een werkende productieserver heeft geen harde deadline. Upgrade alleen als u functionaliteit nodig heeft die 26.04 biedt: PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 of de 7.0 kernel. "Het versienummer is hoger" is geen reden om een machine die klanten bedient aan te passen.

Voer geen in-place upgrade uit als een van de volgende punten waar is:

• U heeft nog nooit de console van uw provider (VNC of serieel) geopend en bent er nog nooit via ingelogd. Die console is de enige manier om weer toegang te krijgen tot de server als SSH faalt; ontdekken dat deze niet werkt terwijl u bent buitengesloten, is te laat.
• U kunt geen uur downtime veroorloven en heeft geen mogelijkheid tot rollback.
• Uw stack is afhankelijk van een repository van derden die nog niet is gepubliceerd voor resolute.
• De server is in de loop van twee jaar handmatig opgebouwd en niemand weet precies wat erop staat.

Het alternatief is vaak beter: bouw een nieuwe 26.04 VPS, installeer uw stack, zet de data terug en wijzig de DNS zodra de server correct reageert. U houdt de oude server draaiende totdat de nieuwe zich heeft bewezen; een rollback is dan slechts een DNS-wijziging in plaats van een restore. Als u voor deze methode kiest, begin dan bij de eerste tien minuten op een nieuwe VPS en bouw de nieuwe server op de juiste manier op.

Stap 1: maak een back-up die u kunt herstellen

Gebruik twee lagen, omdat deze op verschillende manieren kunnen falen. Een snapshot van de provider dekt de volledige schijf en herstelt binnen enkele minuten, maar wordt gemaakt terwijl uw databases schrijven. Hierdoor is deze crash-consistent in plaats van applicatie-consistent. Een back-up op bestandsniveau met restic, opgeslagen buiten de server biedt u individuele bestanden en een kopie die behouden blijft als uw account wordt vergrendeld.

Dump de databases eerst handmatig. Een dump is de enige back-up van een database die u kunt vertrouwen zonder deze te stoppen.

sudo -u postgres pg_dumpall | sudo tee /var/backups/pg-all.sql > /dev/null
sudo mysqldump --all-databases --single-transaction --routines | sudo tee /var/backups/mysql-all.sql > /dev/null
sudo tar czf /var/backups/etc-before-upgrade.tgz -C / etc
sudo chmod 600 /var/backups/pg-all.sql /var/backups/mysql-all.sql

--single-transaction geeft alleen een consistente dump voor InnoDB-tabellen. Voor MyISAM-tabellen moet de database worden gestopt. De /etc tarball is het bestand dat u daadwerkelijk zult gebruiken, omdat dit alle configuratiebestanden bevat waarover de upgrade u vragen zal stellen.

Een back-up die u nooit heeft hersteld, is een gok. Haal nu een bestand uit de back-up, voordat u dit onder tijdsdruk moet doen.

Stap 2: patch 24.04 eerst volledig

do-release-upgrade weigert te draaien op een systeem met een defecte pakketstatus, en een half-gepatchte 24.04 maakt elke latere foutmelding lastiger te analyseren.

sudo apt update
sudo apt full-upgrade
sudo apt --purge autoremove
sudo dpkg --audit
apt-mark showhold

dpkg --audit als dit niets weergeeft, is er geen pakket half geconfigureerd. apt-mark showhold als dit niets weergeeft, is er geen pakket vastgezet op een versie die de upgrade zou blokkeren. Geef elk pakket dat hier wordt vermeld vrij met sudo apt-mark unhold en de pakketnaam, of accepteer dat de blokkering een reden heeft en stop hier.

Start opnieuw op als de kernel is gewijzigd, zodat u de upgrade uitvoert vanaf een machine die de code draait waarvan hij denkt dat hij die draait.

[ -f /var/run/reboot-required ] && sudo reboot

Controleer vervolgens de schijfruimte. De upgrader downloadt de volledige nieuwe pakketset voordat er iets wordt geïnstalleerd, en breekt af met een melding over het bestandssysteem als er onvoldoende ruimte is.

df -h / /boot

Bij minder dan 5 GB vrije ruimte op / gaat dit mis. Een /boot van minder dan 300 MB faalt later, tijdens de kernelinstallatie, met No space left on device. Oude kernels zijn meestal de oorzaak, en sudo apt --purge autoremove verwijdert deze.

Nog één ding om te stoppen voordat u begint: als automatische beveiligingsupdates halverwege het proces worden uitgevoerd, houden ze de dpkg-lock vast en stopt de release-upgrader met Could not get lock /var/lib/dpkg/lock-frontend. Voer eerst sudo systemctl stop unattended-upgrades uit en start het proces opnieuw wanneer u klaar bent.

Stap 3: controleer externe repositories en vastgezette pakketten

do-release-upgrade schakelt elke apt-bron uit die niet van Ubuntu zelf is, omdat een pakket dat is gebouwd voor noble een resolute-systeem kan beschadigen. Het hulpprogramma schakelt de bronnen die het herkent daarna weer in en laat de rest uitgeschakeld staan. Weet wat u in gebruik heeft voordat het hulpprogramma beslissingen voor u neemt.

ls /etc/apt/sources.list.d/
grep -rhE '^(deb |Types:|URIs:|Suites:)' /etc/apt/sources.list.d/
ubuntu-security-status --thirdparty
ls /etc/apt/preferences.d/

Ubuntu 24.04 gebruikt twee formaten in die map: de oude .list-bestanden met één regel en deb822 .sources-bestanden met Types:- en Suites:-velden. Beide worden door de upgrade uitgeschakeld. ubuntu-security-status --thirdparty toont de geïnstalleerde pakketten die niet door een Ubuntu-archief worden geleverd; dit is het exacte aantal pakketten dat u zelf heeft toegevoegd. Alles in /etc/apt/preferences.d/ is een pin, en een pin die is geschreven voor noble zal op de nieuwe release blijven kiezen voor een verouderd pakket.

Bevestig voor elke externe repository dat de leverancier een versie voor de nieuwe codenaam heeft gepubliceerd voordat u begint. De suites van Docker staan vermeld op https://download.docker.com/linux/ubuntu/dists/, en andere leveranciers gebruiken dezelfde mapstructuur. Een bron die verwijst naar een suite die niet bestaat, geeft de volgende melding bij de eerste apt update na de upgrade:

E: The repository 'https://download.docker.com/linux/ubuntu resolute Release' does not have a Release file.

Laat die bron uitgeschakeld totdat de leverancier een nieuwe versie publiceert. Het aanpassen van de codenaam naar een versie die de leverancier wel heeft gebouwd, is de manier waarop u pakketten installeert die gekoppeld zijn aan de verkeerde systeembibliotheken.

Stap 4: voer de upgrade uit in tmux, niet in een standaard SSH-shell

Als uw verbinding wegvalt terwijl do-release-upgrade in een standaard login-shell draait, ontvangt het proces een SIGHUP en stopt het halverwege het uitpakken. Hierdoor blijft dpkg half geconfigureerd achter en beschikt de server mogelijk niet meer over een werkende netwerkstack om opnieuw verbinding mee te maken. Voer de upgrade daarom uit in een terminalmultiplexer, zodat het proces op de server actief blijft wanneer uw client de verbinding verbreekt.

sudo apt install -y tmux
tmux new -s upgrade

Binnen die sessie:

sudo ufw allow 1022/tcp
sudo do-release-upgrade

De upgrader start een tweede SSH-daemon op poort 1022 voordat er wijzigingen worden doorgevoerd, en geeft dit aan:

To make recovery in case of failure easier, an additional sshd will be started on port '1022'. If anything goes wrong with the running ssh you can still connect to the additional one.

De firewall wordt niet automatisch geopend voor deze poort, omdat het zonder toestemming aanpassen van firewallregels ongewenste gevolgen kan hebben. Open poort 1022 zelf voordat u begint en sluit deze weer zodra u klaar bent met sudo ufw delete allow 1022/tcp. Houd er rekening mee dat uw provider mogelijk een tweede firewall in het configuratiescherm hanteert, buiten de server om.

Als de verbinding toch wordt verbroken, meldt u zich opnieuw aan en voert u tmux attach -t upgrade uit. De upgrade liep door terwijl u weg was. Als dat niet het geval was en u terugkomt bij een gedeeltelijk geconfigureerde dpkg of apt-sources die deels noble en deels resolute zijn, beschrijft het herstellen van een mislukte release-upgrade hoe u de pakketstatus repareert en bepaalt wanneer u moet stoppen met repareren en in plaats daarvan de snapshot herstelt.

Stap 5: beantwoord de prompts voor configuratiebestanden weloverwogen

dpkg vraagt alleen om actie bij bestanden die u of een script heeft gewijzigd. Elke prompt betreft dus een bestand dat u bewust heeft aangepast; op enter drukken om de melding te laten verdwijnen is de manier waarop een beveiligde server stilletjes terugkeert naar de standaardinstellingen.

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?

Druk elke keer eerst op D. Lees wat er is gewijzigd en behoud vervolgens uw eigen versie met N. De standaardkeuze is al N, wat het veilige antwoord is, omdat uw bestand op dit moment functioneert en het meegeleverde bestand nog nooit op deze machine is uitgevoerd.

Het behouden van uw bestand heeft een nadeel: u krijgt de nieuwe standaardinstellingen niet. Vergelijk de bestanden achteraf, zodra de server weer draait en u niet onder tijdsdruk staat.

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-new'

Elk bestand dat wordt vermeld is de versie van de beheerder, opgeslagen naast die van u. Vergelijk ze één voor één met diff en kopieer de relevante instellingen. Twee bestanden vereisen extra aandacht: /etc/ssh/sshd_config, omdat een onjuist antwoord uw sessie beëindigt, en uw webserverconfiguratie, omdat een onjuist antwoord de websites offline haalt.

De upgrade vraagt ook welke services opnieuw moeten worden opgestart via needrestart. Accepteer de volledige lijst. Een daemon die nog draait met een gedeelde bibliotheek die van de schijf is verwijderd, zal bij een later verzoek crashen op een moment dat u niet meekijkt.

Stap 6: herstarten en de machine controleren

sudo reboot

Wanneer de machine weer online is:

lsb_release -a
uname -r
systemctl --failed
journalctl -p err -b --no-pager | head -50
sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove

lsb_release -a hoort Release: 26.04 en Codename: resolute te rapporteren. uname -r hoort een 7.0 kernel te tonen. systemctl --failed hoort nul units weer te geven; alles wat daar wel verschijnt, is uw volgende taak. Het laatste commando apt update haalt de updates op die zijn gepubliceerd sinds de release-images zijn gebouwd.

PostgreSQL 16 naar 18: het cluster dat stilletjes achterblijft

Ubuntu 24.04 levert PostgreSQL 16 en 26.04 levert PostgreSQL 18. De upgrade installeert versie 18 naast versie 16 en verplaatst uw data niet. De postgresql-common-laag van Debian maakt een nieuw, leeg cluster aan voor de nieuwe hoofdversie op de eerstvolgende vrije poort. Hierdoor behoudt versie 16 poort 5432 met al uw data, terwijl versie 18 leeg op poort 5433 staat. Uw applicatie blijft communiceren met poort 5432 en er lijkt niets aan de hand, wat de reden is dat men dit vaak pas maanden later ontdekt.

pg_lsclusters

Wanneer er twee clusters worden vermeld, betekent dit dat u de migratie nog niet heeft uitgevoerd. Doe dit op een moment dat u de applicatie kunt stoppen:

sudo pg_dropcluster --stop 18 main
sudo pg_upgradecluster 16 main
pg_lsclusters
sudo -u postgres vacuumdb --all --analyze-only

Verwijder eerst het lege cluster van versie 18, omdat pg_upgradecluster niet naar een doelcluster schrijft dat al bestaat. De standaardmethode maakt een dump van versie 16 en laadt deze in versie 18; u heeft hiervoor dus vrije schijfruimte nodig die ongeveer gelijk is aan de grootte van de database. -m upgrade gebruikt in plaats daarvan pg_upgrade en is aanzienlijk sneller bij een grote database. Wanneer het proces is voltooid, leest u de kolom Port: het nieuwe cluster neemt poort 5432 over en het oude cluster blijft gestopt achter. Voer de analyze-stap zelf uit, omdat een vers geladen cluster nog geen statistieken bevat en de eerste queries daardoor traag zullen zijn.

Test de applicatie gedurende enkele dagen met het nieuwe cluster. Verwijder pas daarna het oude cluster:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

De datadirectory van het oude cluster is de snelste manier om een rollback uit te voeren. Verwijder deze niet op de dag van de upgrade.

MySQL 8.0 naar 8.4: de verwijderde optie die de server stopt

26.04 brengt MySQL van 8.0 naar 8.4 LTS, en twee wijzigingen kunnen problemen veroorzaken op servers.

Ten eerste weigert mysqld te starten wanneer de configuratie een optie bevat die in de nieuwe versie is verwijderd. default_authentication_plugin is de meest voorkomende, omdat veel oudere handleidingen adviseren deze in te stellen. De service faalt en journalctl -u mysql -n 50 benoemt de onbekende variabele direct. Verwijder die regel uit het bestand onder /etc/mysql/mysql.conf.d/ en voer daarna sudo systemctl start mysql uit.

Ten tweede is de mysql_native_password-plugin in 8.4 niet langer standaard ingeschakeld, waardoor een account dat deze nog gebruikt helemaal niet kan inloggen. Controleer dit terwijl u nog op 8.0 werkt:

sudo mysql -e "SELECT user, host, plugin FROM mysql.user;"

Migreer elk account dat mysql_native_password toont vóór de upgrade en werk daarna het wachtwoord bij in uw applicatieconfiguratie:

ALTER USER 'appuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'a new password';

Als een clientbibliotheek te verouderd is om caching_sha2_password te ondersteunen, kunt u de oude plugin in 8.4 weer inschakelen door mysql_native_password=ON toe te voegen onder [mysqld]. Beschouw dit als een tijdelijke overbrugging, aangezien de plugin volledig zal verdwijnen.

PHP 8.3 naar 8.5: uw vhosts verwijzen naar een socket die niet meer bestaat

24.04 levert PHP 8.3 en 26.04 levert PHP 8.5. De pakketten worden geïnstalleerd in paden met versienummers en niets past automatisch uw webserverconfiguratie aan. Een nginx vhost die fastcgi_pass unix:/run/php/php8.3-fpm.sock; bevat, verwijst nu naar een socket die door geen enkel proces wordt aangemaakt. Hierdoor geeft elk PHP-verzoek een 502-foutmelding en toont het nginx-foutlogboek:

connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)

Verwijs naar de nieuwe socket, test de configuratie en herlaad:

sudo sed -i 's/php8.3-fpm.sock/php8.5-fpm.sock/' /etc/nginx/sites-available/example.com
sudo nginx -t
sudo systemctl reload nginx

Bij Apache met mod_php is het symptoom anders: Apache start helemaal niet op en sudo apache2ctl -t meldt dat het libphp8.3.so niet kan laden omdat het bestand niet bestaat. De ingeschakelde module is een symbolische koppeling naar een pakket dat is verwijderd.

sudo a2dismod php8.3
sudo a2enmod php8.5
sudo systemctl restart apache2

Als u de server heeft opgezet op basis van een LAMP-stack op Ubuntu 24.04, zijn beide paden het controleren waard, aangezien de handleiding u achterlaat met een modulenaam en een socket die aan een specifieke versie zijn gekoppeld.

Uw php.ini-instellingen worden eveneens niet automatisch overgenomen. memory_limit, upload_max_filesize en alle andere instellingen bevinden zich in /etc/php/8.3/, en de nieuwe structuur begint met standaardwaarden. Vergelijk de twee bestanden met diff en kopieer de waarden handmatig. Het simpelweg overschrijven van het nieuwe bestand met het oude bestand brengt 8.3-standaardwaarden naar een 8.5-installatie. Voer daarna php -m uit en vergelijk: een extensie die is geïnstalleerd als php8.3-redis heeft het bijbehorende php8.5--pakket nodig. Als deze afkomstig was uit een PPA, heeft de upgrade-procedure die bron uitgeschakeld en ontbreekt de extensie simpelweg.

Certificaten vereisen een eigen controle. Voer sudo certbot renew --dry-run uit na de upgrade. Dit test het volledige vernieuwingsproces, inclusief de herlaad-hook van de webserver, zonder het actieve certificaat aan te passen. Een hook die een servicenaam of een binair bestand aanroept dat is gewijzigd, faalt hier direct voor uw ogen, in plaats van geruisloos over 60 dagen. Certbot met Let's Encrypt op nginx beschrijft hoe deze hooks eruit moeten zien.

SSH: de fout die de sessie waarin u werkt beëindigt

De sshd_config-prompt is de plek waar gebruikers zichzelf buitensluiten. Het beantwoorden met Y installeert het bestand van de beheerder, waardoor uw PermitRootLogin, PasswordAuthentication, AllowUsers, Port en elke andere regel die u heeft toegevoegd, worden verwijderd. Als uw firewall alleen een aangepaste poort toestaat en de meegeleverde configuratie luistert op 22, wordt de volgende verbinding geweigerd en is de sessie waarin u zich bevindt de laatste die u heeft.

Voorkom dit voordat u een upgrade uitvoert. /etc/ssh/sshd_config op 24.04 begint met Include /etc/ssh/sshd_config.d/*.conf, en OpenSSH behoudt de eerste waarde die het leest voor elke instelling. Een drop-in bestand dat bovenaan wordt ingevoegd, krijgt daarom voorrang op alles wat eronder staat. Verplaats uw instellingen naar een bestand dat niet door dpkg wordt beheerd:

sudo tee /etc/ssh/sshd_config.d/99-local.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy
EOF
sudo chmod 644 /etc/ssh/sshd_config.d/99-local.conf
sudo sshd -t && sudo systemctl restart ssh

Zodra er niets van u in /etc/ssh/sshd_config staat, is die prompt niet langer relevant: beide antwoorden behouden uw instellingen, omdat deze in een ander bestand staan.

Een aangepaste poort vereist een extra controle, omdat deze mogelijk niet is waar u denkt dat deze is:

systemctl is-enabled ssh.socket

Als dit enabled weergeeft, beheert systemd de luisterpoort en wordt de Port-regel in sshd_config genegeerd. Ubuntu gebruikt sinds 22.10 socket-activatie voor sshd, en dit is de reden waarom een bewerking van Port 2222 geen effect lijkt te hebben. Stel dit in plaats daarvan in op de socket-unit, met sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

De lege ListenStream= is vereist. Dit wist de overgeërfde waarde; zonder dit luistert de socket zowel op 22 als op 2222. Pas dit toe met sudo systemctl daemon-reload && sudo systemctl restart ssh.socket.

Na de upgrade, voordat u de sessie waarin u zich bevindt sluit:

sudo sshd -t
sudo systemctl status ssh.socket --no-pager
sudo ss -lntp | grep -E ':(22|2222)'

Open vervolgens een tweede terminal op uw eigen machine en log opnieuw in. Een werkende shell in die tweede terminal is het enige bewijs dat telt. Houd de eerste sessie open totdat u die heeft. SSH beveiligen op een VPS behandelt de instellingen die het waard zijn om in die drop-in te behouden.

Als het al te laat is, biedt de webconsole van uw provider u een login die helemaal geen gebruikmaakt van SSH. Log daar in, herstel de configuratie, voer sudo sshd -t uit en herstart de service. Die console is precies de reden waarom u consoletoegang test vóór een upgrade in plaats van tijdens een upgrade.

FAQ

Waarom geeft do-release-upgrade de melding "No new release found" op Ubuntu 24.04?

Omdat /etc/update-manager/release-upgrades op Ubuntu Server de waarde Prompt=lts bevat, en die instelling biedt de volgende Long Term Support-release pas aan nadat de eerste point-release beschikbaar is. Ubuntu 26.04 LTS is uitgebracht op 23 april 2026, en 26.04.1 staat gepland voor 27 augustus 2026. Tot die datum ziet een 24.04-server geen nieuwe release. Wijzig deze instelling niet naar Prompt=normal, omdat u dan via de tussenliggende releases wordt geleid.

Moet ik de server herstarten om de upgrade te voltooien?

Ja. De upgrade installeert een nieuwe kernel, een nieuwe C-library en een nieuw init-systeem; het draaiende systeem blijft de oude versies gebruiken totdat het opnieuw opstart. do-release-upgrade vraagt aan het einde om een herstart, en een machine die "later" pas wordt herstart, draait op een mix van twee releases. Controleer na de herstart uname -r voor de nieuwe kernel en systemctl --failed voor services die niet correct zijn opgestart.

Moet ik een in-place upgrade uitvoeren of een nieuwe 26.04-server inrichten?

Bouw bij voorkeur een nieuwe server. Op een nieuwe VPS kunt u de stack installeren, de data terugzetten en alles testen terwijl de oude server nog verkeer afhandelt. Een rollback is dan slechts een DNS-wijziging in plaats van een herstel vanaf een backup. Kies voor een in-place upgrade wanneer de server data bevat die lastig te verplaatsen is, wanneer de provider per machine factureert, of wanneer u over een snapshot en betrouwbare consoletoegang beschikt. De in-place procedure is beproefd, maar het is een eenrichtingsweg gedurende de tijd dat deze draait.

Wat gebeurt er als mijn SSH-verbinding wegvalt tijdens de upgrade?

In een standaard login-shell ontvangt het proces een SIGHUP en stopt het halverwege, waardoor dpkg half geconfigureerd achterblijft. Start de upgrade binnen tmux of screen zodat het proces blijft draaien; u kunt dan opnieuw verbinden en tmux attach -t upgrade uitvoeren om de upgrade te hervatten. De upgrader start ook een extra SSH-daemon op poort 1022 als tweede toegangsweg, maar opent de firewall niet voor deze poort. Sta poort 1022 daarom zelf toe en sluit deze na afloop weer.

Mijn PHP-site geeft een 502-fout na de upgrade. Wat is er mis?

Het pad naar de PHP FPM-socket is gewijzigd met de nieuwe versie. Ubuntu 24.04 draait PHP 8.3 en 26.04 draait PHP 8.5, waardoor /run/php/php8.3-fpm.sock niet langer bestaat terwijl uw nginx vhost hier nog wel naar verwijst. Het nginx-foutenlogboek toont connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory). Werk fastcgi_pass bij naar de 8.5-socket, voer sudo nginx -t uit en herlaad vervolgens nginx. Bij Apache met mod_php is de equivalente oplossing sudo a2dismod php8.3, gevolgd door sudo a2enmod php8.5 en een herstart.