Ubuntu 24.04'ten 26.04'e Yükseltme Rehberi

Ubuntu 24.04 sürümünden 26.04 sürümüne ne zaman yükseltme yapabilirsiniz?

Ubuntu 24.04 sürümünden 26.04 sürümüne yükseltme işlemi, 27 Ağustos 2026 tarihinde yayınlanması planlanan 26.04.1 ara sürümü (point release) çıktıktan sonra bir VPS üzerinde gerçekleştirilebilir. O tarihe kadar, 24.04 çalıştıran bir sunucu, yeni sürümü kasıtlı olarak görmeyecektir. Ubuntu 26.04 LTS (Resolute Raccoon) 23 Nisan 2026 tarihinde yayınlanmış olsa da, Canonical LTS'den LTS'ye yükseltme yolunu yalnızca ilk ara sürüm yayınlandığında açar; çünkü bu sürüm, ilk aylarda tespit edilen kurulum ve yükseltme hatalarını giderir.

Ağustos 2026 başında 24.04 yüklü bir makinede kontrolü çalıştırdığınızda şu çıktıyı alırsınız:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

Bu durum sunucunuzdaki bir hatadan kaynaklanmaz. /etc/update-manager/release-upgrades, Ubuntu Server üzerinde Prompt=lts içerir; bu da aracın yalnızca bir sonraki uzun süreli destek (LTS) sürümünü ve yalnızca onun .1 ara sürümü mevcut olduğunda sunduğu anlamına gelir. Prompt=normal ayarını yapmak, bunun yerine sırasıyla 24.10, 25.04 ve 25.10 sürümleri üzerinden geçiş yapmanıza neden olur; bu ara sürümlerin tümü ömürlerini tamamlamıştır. Ayarı lts olarak bırakın ve bekleyin. Canonical'ın takvimindeki tarihler değişebilir, bu nedenle belirtilen gün sessiz geçerse tekrar kontrol edin.

Aşağıdaki her komut, kendi sunucunuzda ve verilen sırada bizzat çalıştıracağınız komutlardır. Bir sürüm yükseltme işlemi, yükseltme yaptığınız makinede prova edilemez. Bu işlem çekirdeği ve C kütüphanesini değiştirir; tamamlanması için yeniden başlatma gerektirir.

Yükseltme yapmalı mısınız?

Ubuntu 24.04, 2029 yılına kadar standart güvenlik güncellemelerini almaya devam edecektir; bu nedenle çalışan bir üretim sunucusu için herhangi bir son tarih bulunmamaktadır. Yükseltme işlemini, 26.04 sürümünün getirdiği PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 veya 7.0 çekirdeği gibi yeniliklere ihtiyaç duyduğunuzda yapmalısınız. "Sürüm numarası arttı" gerekçesi, müşterilere hizmet veren bir makineye müdahale etmek için yeterli bir neden değildir.

Aşağıdaki durumlardan herhangi biri geçerliyse yerinde yükseltme (in-place upgrade) yapmayın:

• Sağlayıcınızın konsolunu (VNC veya seri bağlantı) hiç açmadıysanız ve üzerinden giriş yapmadıysanız. SSH bağlantısı koptuğunda sunucuya geri dönmenin tek yolu bu konsoldur; konsolun çalışmadığını sistemden kilitlendiğinizde fark etmek için çok geç olacaktır.
• Bir saatlik kesintiyi göze alamıyorsanız ve bir geri dönüş (rollback) planınız yoksa.
• Yazılım yığınınız, henüz resolute için yayın yapmamış üçüncü taraf bir depoya bağımlıysa.
• Sunucu iki yıl boyunca elle yapılandırıldıysa ve üzerinde tam olarak nelerin bulunduğu bilinmiyorsa.

Alternatif yöntem genellikle daha sağlıklıdır: yeni bir 26.04 VPS oluşturun, yazılım yığınınızı kurun, verileri geri yükleyin ve sistem düzgün yanıt verdiğinde DNS yönlendirmesini değiştirin. Yeni sunucu kendini kanıtlayana kadar eski sunucuyu çalışır durumda tutarsınız; böylece geri dönüş işlemi bir veri kurtarma yerine basit bir DNS değişikliği olur. Bu yolu tercih ederseniz, yeni bir VPS üzerindeki ilk on dakika rehberiyle başlayın ve yeni sunucuyu doğru şekilde yapılandırın.

Adım 1: Geri yüklenebilir bir yedek alın

İki katmanlı bir yedekleme stratejisi kullanın; çünkü her katmanın başarısızlık senaryoları farklıdır. Sağlayıcı tabanlı snapshot tüm diski kapsar ve dakikalar içinde geri yüklenir; ancak veritabanlarınız yazma işlemi yaparken alındığı için uygulama tutarlılığından ziyade kilitlenme tutarlılığı (crash consistency) sağlar. restic ile sunucu dışında depolanan dosya düzeyinde bir yedekleme ise tekil dosyaları kurtarmanıza olanak tanır ve hesap erişiminizin kısıtlanması durumunda verilerinizin güvende kalmasını sağlar.

Öncelikle veritabanlarını manuel olarak dump edin. Bir dump, veritabanını durdurmadan güvenebileceğiniz tek yedekleme yöntemidir.

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 yalnızca InnoDB tabloları için tutarlı bir dump sağlar. MyISAM tabloları için veritabanının durdurulması gerekir. Yükseltme sırasında size sorulacak tüm yapılandırma dosyalarını içerdiği için asıl ihtiyaç duyacağınız yedek /etc tarball dosyasıdır.

Daha önce geri yüklemediğiniz bir yedek, sadece bir tahmindir. Baskı altında kalmadan önce, şimdi yedek içerisinden bir dosyayı geri çekerek test edin.

Adım 2: 24.04 sürümünü önce tamamen yamalayın

do-release-upgrade, bozuk paket durumuna sahip bir sistemde çalışmayı reddeder; yarım yamalanmış bir 24.04, sonraki tüm hataların analizini zorlaştırır.

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

dpkg --audit komutunun hiçbir çıktı vermemesi, yarım yapılandırılmış paket olmadığını gösterir. apt-mark showhold komutunun hiçbir çıktı vermemesi, yükseltmeyi engelleyecek bir sürüme sabitlenmiş paket olmadığını gösterir. Listelenen paketleri sudo apt-mark unhold ve paket adı ile serbest bırakın veya bu sabitlemenin bir nedeni olduğunu kabul ederek burada durun.

Çekirdek değiştiyse sistemi yeniden başlatın; böylece yükseltme işlemini, çalıştığını düşündüğü kodu çalıştıran bir makine üzerinden gerçekleştirmiş olursunuz.

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

Ardından disk alanını kontrol edin. Yükseltme aracı, herhangi bir kurulum yapmadan önce yeni paket setinin tamamını indirir; yeterli alan yoksa dosya sistemini belirten bir mesajla işlemi durdurur.

df -h / /boot

/ üzerinde yaklaşık 5 GB'tan az boş alan olması durumunda süreç başarısız olur. 300 MB'tan küçük bir /boot, daha sonra çekirdek kurulumu sırasında No space left on device hatasıyla sonuçlanır. Bunun nedeni genellikle eski çekirdeklerdir ve sudo apt --purge autoremove komutu bunları temizler.

Başlamadan önce dikkat edilmesi gereken bir diğer husus: otomatik güvenlik güncellemeleri işlem sırasında devreye girerse dpkg kilidini tutarlar ve sürüm yükseltme aracı Could not get lock /var/lib/dpkg/lock-frontend hatasıyla durur. Önce sudo systemctl stop unattended-upgrades komutunu çalıştırın ve işlem bittiğinde yükseltmeyi tekrar başlatın.

Adım 3: Üçüncü taraf depoları ve sabitlenmiş paketleri kontrol etme

do-release-upgrade, Ubuntu'ya ait olmayan her apt kaynağını devre dışı bırakır; çünkü noble için derlenmiş bir paket resolute sistemini bozabilir. Araç, tanıdığı kaynakları daha sonra yeniden etkinleştirir ve geri kalanını yorum satırı haline getirir. Araç sizin yerinize karar vermeden önce ne taşıdığınızı bilin.

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, bu dizinde iki format kullanır: eski tek satırlık .list dosyaları ve Types: ile Suites: alanlarını içeren deb822 formatındaki .sources dosyaları. Her iki format da yükseltme işlemiyle devre dışı bırakılır. ubuntu-security-status --thirdparty, hiçbir Ubuntu arşivinde bulunmayan yüklü paketleri listeler; bu, sisteme sonradan eklediğiniz paketlerin gerçek sayısıdır. /etc/apt/preferences.d/ içindeki her şey bir sabitlemedir (pin) ve noble için yazılmış bir sabitleme, yeni sürümde eski bir paketi seçmeye devam edecektir.

Her üçüncü taraf deposu için, işleme başlamadan önce sağlayıcının yeni kod adı için yayın yapıp yapmadığını doğrulayın. Docker'ın paket dizinleri https://download.docker.com/linux/ubuntu/dists/ adresinde listelenmiştir; diğer sağlayıcılar da aynı dizin yapısını sunar. Mevcut olmayan bir dizine işaret eden bir kaynak, yükseltme sonrasındaki ilk apt update komutunda şu hatayı verir:

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

Sağlayıcı yayın yapana kadar bu kaynağı devre dışı bırakın. Kod adını sağlayıcının derleme yaptığı bir kod adıyla değiştirmek, yanlış sistem kütüphanelerine bağlı paketleri yüklemenize neden olur.

Adım 4: Yükseltmeyi düz bir SSH kabuğu yerine tmux içinde çalıştırın

Eğer do-release-upgrade düz bir oturum kabuğunda çalışırken bağlantınız koparsa, işlem SIGHUP sinyali alır ve paket açma aşamasında yarıda kesilir. Bu durum dpkg paketinin yarım yapılandırılmış halde kalmasına ve sunucunun yeniden bağlanılabilecek çalışan bir ağ yığınına sahip olmamasına yol açabilir. İşlemi bir terminal çoğullayıcı (terminal multiplexer) içinde çalıştırın; böylece istemciniz bağlantıyı kestiğinde işlem sunucu üzerinde yaşamaya devam eder.

sudo apt install -y tmux
tmux new -s upgrade

Oturumun içinde:

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

Yükseltme aracı, herhangi bir değişiklik yapmadan önce 1022 numaralı port üzerinde ikinci bir SSH daemon başlatır ve bunu şu şekilde bildirir:

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.

Bu port için güvenlik duvarınızı otomatik olarak açmaz; çünkü kullanıcıya sormadan güvenlik duvarında delik açmak beklenmedik sorunlara yol açabilir. Başlamadan önce 1022 numaralı portu kendiniz açın ve sudo ufw delete allow 1022/tcp ile işiniz bittiğinde kapatın. Sağlayıcınızın, sunucunun dışında, kontrol panelinde ikinci bir güvenlik duvarı çalıştırabileceğini unutmayın.

Bağlantı yine de koparsa, tekrar giriş yapın ve tmux attach -t upgrade komutunu çalıştırın. Yükseltme işlemi siz yokken çalışmaya devam etmiştir.

Adım 5: Yapılandırma dosyası istemlerini dikkatle yanıtlayın

dpkg yalnızca sizin veya bir betiğin değiştirdiği dosyalar için istem görüntüler. Dolayısıyla her istem, bilinçli olarak düzenlediğiniz bir dosyayı temsil eder; istemi geçiştirmek için doğrudan enter tuşuna basmak, güvenliği sıkılaştırılmış bir sunucunun sessizce varsayılan ayarlara dönmesine neden olur.

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] ?

Her seferinde önce D tuşuna basın. Nelerin değiştiğini okuyun, ardından N ile kendi sürümünüzü koruyun. Varsayılan seçenek zaten N olarak gelir; bu güvenli cevaptır çünkü dosyanız halihazırda çalışmaktadır ve paketlenmiş sürüm bu makinede hiç çalıştırılmamıştır.

Kendi dosyanızı korumanın bir bedeli vardır: yeni varsayılan ayarları alamazsınız. Sunucu ayağa kalktığında ve zaman baskısı altında olmadığınızda bu ayarları daha sonra gözden geçirin.

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

Listelenen her dosya, sizinkinin yanında kaydedilmiş olan paket yöneticisinin sürümüdür. Bunları tek tek karşılaştırın (diff) ve önemli olan ayarları kopyalayın. İki dosya için ekstra dikkat gereklidir: /etc/ssh/sshd_config, çünkü yanlış cevap oturumunuzu sonlandırır; web sunucusu yapılandırmanız ise yanlış cevap durumunda sitelerin erişilemez olmasına neden olur.

Yükseltme işlemi ayrıca needrestart aracılığıyla hangi servislerin yeniden başlatılacağını sorar. Listenin tamamını kabul edin. Diskten silinmiş bir paylaşımlı kütüphane dosyası üzerinde çalışmaya devam eden bir daemon, daha sonra izlemediğiniz bir anda çökecektir.

Adım 6: sistemi yeniden başlatın ve kontrol edin

sudo reboot

Sistem tekrar açıldığında:

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 komutu Release: 26.04 ve Codename: resolute değerlerini döndürmelidir. uname -r komutu 7.0 çekirdeğini göstermelidir. systemctl --failed komutu sıfır birim listelemelidir; listelenen herhangi bir birim varsa, bir sonraki göreviniz bunları çözümlemektir. Son olarak apt update komutu, sürüm imajları oluşturulduktan sonra yayınlanan güncellemeleri çeker.

PostgreSQL 16'dan 18'e geçiş: sessizce geride kalan küme

Ubuntu 24.04, PostgreSQL 16 ile gelirken 26.04 sürümü PostgreSQL 18 ile gelmektedir. Yükseltme işlemi 18 sürümünü 16'nın yanına kurar ve verilerinizi taşımaz. Debian'ın postgresql-common katmanı, yeni ana sürüm için bir sonraki boş port üzerinde yeni ve boş bir küme oluşturur; bu nedenle 16 numaralı sürüm tüm verilerinizle 5432 numaralı portta kalmaya devam ederken, 18 numaralı sürüm 5433 numaralı portta boş olarak bekler. Uygulamanız 5432 numaralı port ile iletişim kurmaya devam eder ve hiçbir sorun yokmuş gibi görünür; kullanıcıların bu durumu aylar sonra fark etmesinin nedeni budur.

pg_lsclusters

Listelenen iki küme, henüz geçiş yapmadığınız anlamına gelir. Uygulamayı durdurabildiğiniz bir zamanda şu adımları izleyin:

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

Öncelikle boş olan 18 numaralı kümeyi silin, çünkü pg_upgradecluster halihazırda var olan bir hedef kümeye yazma yapmayacaktır. Varsayılan yöntem 16 numaralı kümenin yedeğini alır ve 18 numaralı kümeye geri yükler; bu nedenle veritabanı boyutuna yakın boş disk alanına ihtiyacınız vardır. -m upgrade bunun yerine pg_upgrade kullanır ve büyük veritabanlarında çok daha hızlıdır. İşlem tamamlandığında Port sütununu inceleyin: yeni küme 5432 numaralı portu devralır ve eski küme durdurulmuş halde bırakılır. Analyze işlemini kendiniz çalıştırın, çünkü yeni yüklenen bir küme istatistiklere sahip değildir ve ilk sorgular yavaş çalışacaktır.

Uygulamayı yeni küme üzerinde birkaç gün boyunca test edin. Ancak o zaman eski kümeyi kaldırın:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

Eski kümenin veri dizini, elinizdeki en hızlı geri dönüş (rollback) yöntemidir. Yükseltme gününde bu dizini silmeyin.

MySQL 8.0'dan 8.4'e geçiş: sunucunun başlamasını engelleyen kaldırılmış seçenek

26.04 sürümü, MySQL'i 8.0'dan 8.4 LTS sürümüne taşır ve bu süreçte iki değişiklik sunucuları etkiler.

İlk olarak, mysqld, yapılandırma dosyasında yeni sürümde kaldırılmış bir seçenek bulunduğunda başlamayı reddeder. Eski kılavuzların birçoğu bu seçeneğin ayarlanmasını önerdiği için default_authentication_plugin yaygın bir sorundur. Servis başarısız olur ve journalctl -u mysql -n 50 doğrudan bilinmeyen değişkenin adını belirtir. /etc/mysql/mysql.conf.d/ altındaki dosyadan ilgili satırı silin ve ardından sudo systemctl start mysql işlemini gerçekleştirin.

İkinci olarak, mysql_native_password eklentisi 8.4 sürümünde varsayılan olarak etkin değildir; bu nedenle bu eklentiyi kullanan bir hesap sisteme giriş yapamaz. 8.0 sürümündeyken kontrol edin:

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

Yükseltme öncesinde mysql_native_password gösteren tüm hesapları taşıyın ve ardından uygulama yapılandırmanızdaki parolayı güncelleyin:

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

Eğer bir istemci kütüphanesi caching_sha2_password protokolünü destekleyemeyecek kadar eskiyse, [mysqld] altına mysql_native_password=ON ekleyerek eski eklentiyi 8.4 sürümünde tekrar etkinleştirebilirsiniz. Bu eklenti tamamen kullanımdan kaldırılacağı için bu yöntemi geçici bir çözüm olarak değerlendirin.

PHP 8.3'ten 8.5'e geçiş: vhost'larınız artık mevcut olmayan bir soketi işaret ediyor

24.04 sürümü PHP 8.3 ile, 26.04 sürümü ise PHP 8.5 ile gelir. Paketler sürümlü dizinlere kurulur ve web sunucusu yapılandırmanız otomatik olarak güncellenmez. fastcgi_pass unix:/run/php/php8.3-fpm.sock; içeren bir nginx vhost'u artık hiçbir sürecin oluşturmadığı bir soketi işaret etmektedir; bu nedenle her PHP isteği 502 hatası döndürür ve nginx hata günlüğünde şu ifade yer alır:

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

Yapılandırmayı yeni sokete yönlendirin, test edin ve yeniden yükleyin:

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

Apache üzerinde mod_php kullanıldığında belirtiler farklıdır: Apache hiç başlamaz ve sudo apache2ctl -t, dosya mevcut olmadığı için libphp8.3.so modülünün yüklenemediğini bildirir. Etkinleştirilmiş modül, artık var olmayan bir pakete işaret eden bir sembolik bağdır.

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

Sunucuyu Ubuntu 24.04 üzerinde LAMP kurulumu rehberine göre oluşturduysanız, her iki yolun da kontrol edilmesi gerekir; çünkü rehber sizi sürümlü bir modül adı ve sürümlü bir soket ile bırakır.

php.ini ayarlarınız da taşınmaz. memory_limit, upload_max_filesize ve ayarladığınız diğer tüm değerler /etc/php/8.3/ içinde yer alır ve yeni sürüm varsayılan ayarlarla başlar. İki dosyayı karşılaştırın ve değerleri manuel olarak aktarın. Eski dosyayı doğrudan yenisinin üzerine kopyalamak, 8.3 varsayılanlarını 8.5 kurulumuna taşır. Ardından php -m komutunu çalıştırın ve karşılaştırın: php8.3-redis olarak kurulan bir eklenti, php8.5- paketine ihtiyaç duyar; eğer bu eklenti bir PPA kaynağından geldiyse, yükseltme işlemi bu kaynağı devre dışı bırakmıştır ve eklenti eksik kalacaktır.

Sertifikalar ayrı bir kontrolü hak eder. Yükseltme işleminden sonra sudo certbot renew --dry-run komutunu çalıştırın. Bu komut, canlı sertifikaya dokunmadan web sunucusu yeniden yükleme kancası dahil tüm yenileme sürecini test eder. Bir servis adını veya değişen bir ikili dosyayı çağıran bir kanca, 60 gün sonra sessizce başarısız olmak yerine, burada gözünüzün önünde hata verecektir. Nginx üzerinde Let's Encrypt ile Certbot rehberi, bu kancaların nasıl olması gerektiğini açıklar.

SSH: oturumunuzu sonlandıran hata

sshd_config istemi, kullanıcıların kendilerini sistem dışı bıraktığı yerdir. Y yanıtını vermek, paket sorumlusunun dosyasını yükler; bu da PermitRootLogin, PasswordAuthentication, AllowUsers, Port ve eklediğiniz diğer tüm satırları siler. Güvenlik duvarınız yalnızca özel bir porta izin veriyorsa ve paketlenmiş yapılandırma 22 numaralı portu dinliyorsa, bir sonraki bağlantı reddedilir ve içinde bulunduğunuz oturum sahip olduğunuz son oturum olur.

Yükseltme yapmadan önce bunu önleyin. 24.04 üzerindeki /etc/ssh/sshd_config, Include /etc/ssh/sshd_config.d/*.conf ile başlar ve OpenSSH her ayar için okuduğu ilk değeri korur; bu nedenle en üste eklenen bir drop-in dosyası, altındaki her şeyin önüne geçer. Ayarlarınızı dpkg tarafından yönetilmeyen bir dosyaya taşıyın:

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

/etc/ssh/sshd_config içinde size ait hiçbir şey kalmadığında, o istemin bir önemi kalmaz: hangi yanıtı seçerseniz seçin ayarlarınız korunur, çünkü bunlar farklı bir dosyada yer alır.

Özel bir port, düşündüğünüz yerde olmayabileceği için bir kontrol daha gerektirir:

systemctl is-enabled ssh.socket

Eğer bu komut enabled çıktısını verirse, dinleme portu systemd tarafından yönetiliyordur ve sshd_config içindeki Port satırı göz ardı edilir. Ubuntu, 22.10 sürümünden beri sshd için socket activation kullanmaktadır ve Port 2222 üzerinde yapılan bir düzenlemenin hiçbir işe yaramamasının nedeni budur. Ayarı bunun yerine sudo systemctl edit ssh.socket ile socket birimi üzerinde yapın:

[Socket]
ListenStream=
ListenStream=2222

Boş ListenStream= gereklidir. Bu, devralınan değeri temizler; aksi takdirde socket hem 22 hem de 2222 numaralı portları dinler. Ayarı sudo systemctl daemon-reload && sudo systemctl restart ssh.socket ile uygulayın.

Yükseltmeden sonra, mevcut oturumunuzu kapatmadan önce:

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

Ardından kendi makinenizde ikinci bir terminal açın ve tekrar giriş yapın. İkinci terminalde çalışan bir kabuk, geçerli olan tek kanıttır. Bunu elde edene kadar ilk oturumu açık tutun. VPS üzerinde SSH güvenliğini sıkılaştırma rehberi, drop-in dosyasında tutmaya değer ayarları incelemektedir.

Eğer iş işten geçtiyse, sağlayıcınızın web konsolu SSH kullanmayan bir giriş yöntemi sunar. Oradan giriş yapın, yapılandırmayı düzeltin, sudo sshd -t komutunu çalıştırın ve servisi yeniden başlatın. O konsol, yükseltme sırasında değil, yükseltmeden önce konsol erişimini test etmenizin tam olarak nedenidir.

FAQ

Ubuntu 24.04 üzerinde do-release-upgrade neden "No new release found" hatası veriyor?

Çünkü /etc/update-manager/release-upgrades, Ubuntu Server üzerinde Prompt=lts değerini içerir ve bu ayar, bir sonraki uzun süreli destek (LTS) sürümünü yalnızca ilk ara sürümü (point release) yayınlandıktan sonra sunar. Ubuntu 26.04 LTS, 23 Nisan 2026 tarihinde yayınlanmıştır ve 26.04.1 sürümünün 27 Ağustos 2026 tarihinde çıkması planlanmaktadır. O tarihe kadar, 24.04 yüklü bir sunucu yeni bir sürüm görmeyecektir. Sizi ara sürümler üzerinden yönlendirecek olan Prompt=normal değerine geçmek yerine ayarı olduğu gibi bırakın.

Yükseltmeyi tamamlamak için sunucuyu yeniden başlatmam gerekiyor mu?

Evet. Yükseltme işlemi yeni bir çekirdek, yeni bir C kütüphanesi ve yeni bir init sistemi kurar; çalışan sistem, yeniden başlatılana kadar eskilerini kullanmaya devam eder. do-release-upgrade işlemi sonunda yeniden başlatma ister; "daha sonra" yeniden başlatılmak üzere açık bırakılan bir makine, iki farklı sürümün karışımıyla çalışıyor demektir. Makine geri geldiğinde, yeni çekirdek için uname -r komutunu, çalışmayan servisler için ise systemctl --failed komutunu kontrol edin.

Yerinde yükseltme mi yapmalıyım yoksa temiz bir 26.04 sunucusu mu kurmalıyım?

Mümkünse temiz kurulum yapın. Yeni bir VPS, eski sunucu trafiği karşılamaya devam ederken yığını kurmanıza, verileri geri yüklemenize ve her şeyi test etmenize olanak tanır; böylece geri dönüş, yedekten dönmek yerine basit bir DNS değişikliği olur. Yerinde yükseltmeyi, sunucu taşınması zor veriler içerdiğinde, sağlayıcı makine başına ücretlendirme yaptığında veya elinizde bir snapshot ve kanıtlanmış bir konsol erişimi olduğunda tercih edin. Yerinde yükseltme yolu iyi bilinen bir yoldur ancak işlem süresince tek yönlü bir kapıdır.

Yükseltme sırasında SSH bağlantım koparsa ne olur?

Normal bir oturum kabuğunda işlem SIGHUP sinyali alır ve yarıda kesilir; bu da dpkg paketinin yarım yapılandırılmış halde kalmasına neden olur. İşlemi tmux veya screen içerisinde başlatırsanız, bağlantı kopsa bile işlem hayatta kalır; böylece tekrar bağlanıp tmux attach -t upgrade komutuyla kaldığınız yerden devam edebilirsiniz. Yükseltme aracı ayrıca ikinci bir giriş yolu olarak 1022 numaralı portta yedek bir SSH daemon başlatır, ancak bu port için güvenlik duvarını otomatik açmaz; bu yüzden 1022 numaralı porta önce kendiniz izin verin ve işlem bitince kapatın.

Yükseltmeden sonra PHP sitem 502 hatası veriyor. Ne bozuldu?

PHP FPM soket yolu sürümle birlikte değişti. Ubuntu 24.04, PHP 8.3 çalıştırırken 26.04, PHP 8.5 çalıştırır; bu nedenle nginx vhost dosyanızda tanımlı olan /run/php/php8.3-fpm.sock artık mevcut değildir. Nginx hata günlüğü connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory) mesajını gösterir. fastcgi_pass dosyasını 8.5 soketine göre güncelleyin, sudo nginx -t komutunu çalıştırın ve ardından nginx servisini yeniden yükleyin. Apache üzerinde mod_php kullanıyorsanız, eşdeğer çözüm sudo a2dismod php8.3 komutunu çalıştırmak, ardından sudo a2enmod php8.5 ile devam edip servisi yeniden başlatmaktır.