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?

Bir VPS üzerinde Ubuntu 24.04 sürümünden 26.04 sürümüne yükseltme işlemini, 27 Ağustos 2026 tarihinde yayınlanması planlanan 26.04.1 ara sürümü (point release) çıktığında gerçekleştirebilirsiniz. O tarihe kadar bir 24.04 sunucusu, 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ümle birlikte açar; çünkü bu sürüm, ilk aylarda tespit edilen kurulum ve yükseltme hatalarını bünyesinde barındırır. Eğer sürüm numaralandırma sistemi sizin için yeniyse, 26.04.1 farklı bir Ubuntu sürümü değil, 26.04 sürümünün dört aylık düzeltmelerin medya içeriğine dahil edilmiş halidir; Canonical'ın mevcut bir sunucuya sunacağı ilk sürümün bu olmasının nedeni tam olarak budur.

2026 yılının Ağustos ayı başlarında bir 24.04 sunucusunda 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, sunucunuzdaki bir arızadan kaynaklanmaz. /etc/update-manager/release-upgrades, Ubuntu Server üzerinde Prompt=lts içerir; bu nedenle araç yalnızca bir sonraki uzun süreli destek sürümünü ve yalnızca bu sürümün .1 nokta sürümü yayımlandıktan sonra sunar. Prompt=normal ayarlanırsa sırasıyla 24.10, 25.04 ve 25.10 sürümleri üzerinden yönlendirme yapılır; bu ara sürümlerin tümü kullanım ömrünün sonuna ulaşmıştır. lts olarak bırakın ve bekleyin. Canonical takvimindeki tarihler değişebilir; gün sessizce geçtiyse tarihi yeniden kontrol edin. Hâlâ 22.04 çalıştıran bir sunucu bu geçişi doğrudan yapamaz; çünkü yükseltme aracı her zaman yalnızca bir sonraki LTS sürümünü sunar. Bu nedenle 24.04 üzerinden 22.04'ten 26.04'e yükseltme, ilk geçişi ve ikinci geçişten önce alınması gereken snapshot'ı açıklar.

Aşağıdaki her komutu kendi sunucunuzda, belirtilen sırayla kendiniz çalıştırmalısınız. Bir sürüm yükseltme işlemi, yükseltme yaptığınız makine üzerinde prova edilemez. Bu işlem çekirdeği ve C kütüphanesini değiştirir ve 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 sunucusunun herhangi bir son tarihi 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 özelliklere ihtiyaç duyduğunuzda yapmalısınız. "Sürüm numarası arttı" gerekçesi, müşterilere hizmet veren bir sunucuya müdahale etmek için yeterli bir neden değildir.

Aşağıdaki durumlardan herhangi biri geçerliyse yerinde yükseltme 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çtir.
• 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 iyidir: temiz bir 26.04 VPS oluşturun, yazılım yığınınızı kurun ve verileri geri yükleyin, ardından sunucu doğru yanıt verdiğinde DNS yönlendirmesini değiştirin. Eski sunucuyu, yeni sunucu kendini kanıtlayana kadar çalışır durumda tutun; böylece geri dönüş, bir geri yükleme işlemi 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 düzgün bir ş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ı tarafından alınan snapshot tüm diski kapsar ve dakikalar içinde geri yüklenir; ancak veritabanları yazma işlemi yaparken alındığı için uygulama tutarlı değil, kilitlenme tutarlıdır (crash consistent). restic ile sunucu dışında depolanan dosya seviyesinde bir yedekleme ise tekil dosyaları kurtarmanıza olanak tanır ve hesap erişiminizin kesilmesi durumunda verilerinizi korur.

Ö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. Acil bir durumda ihtiyaç duymadan önce, yedek içerisinden bir dosyayı şimdi geri yükleyerek test edin.

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

do-release-upgrade, bozuk paket durumuna sahip bir sistemde çalışmayı reddeder; yarım yamalanmış bir 24.04 sürümü, daha sonra oluşacak her türlü hatanı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ş (pinned) paket olmadığını gösterir. Listelenen paketleri sudo apt-mark unhold ve paket adı ile serbest bırakın veya sabitleme işleminin 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ırdığı kodun aynısını kullanan bir makine üzerinde 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 hata mesajı ile işlemi durdurur.

df -h / /boot

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

Başlamadan önce dikkat edilmesi gereken bir diğer nokta: Eğer 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şiniz 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ığı depoları işlem sonrasında tekrar etkinleştirir, geri kalanları ise yorum satırı haline getirir. Araç sizin yerinize karar vermeden önce neleri taşıdığınızı bilmeniz gerekir.

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şlemi sırasında devre dışı bırakılır. ubuntu-security-status --thirdparty, Ubuntu arşivlerinde bulunmayan ve sisteminize eklediğiniz paketlerin listesini verir; bu, dışarıdan eklediğiniz yazılımların gerçek sayısıdır. /etc/apt/preferences.d/ içindeki her ifade bir sabitlemedir (pin); noble için yazılmış bir sabitleme, yeni sürümde de eski 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 benzer dizinler sunar. Mevcut olmayan bir dizine işaret eden 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 ilgili kaynağı devre dışı bırakın. Kod adını sağlayıcının derleme yaptığı bir sürümle değiştirmek, yanlış sistem kütüphanelerine bağlı paketlerin yüklenmesine 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 kesilirse, 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ış 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ı 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 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.

Güvenlik duvarınızda bu port için otomatik olarak bir delik açmaz; çünkü izinsiz bir şekilde güvenlik duvarını delmek 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 kesilirse yeniden oturum açın ve tmux attach -t upgrade komutunu çalıştırın. Siz yokken yükseltme işlemi çalışmaya devam etmiştir. İşlem devam etmediyse ve kısmen yapılandırılmış bir dpkg ya da bir kısmı noble, diğer kısmı resolute olan apt kaynaklarıyla karşılaşırsanız başarısız bir sürüm yükseltmesinden kurtarma, paket durumunun onarılmasını ve onarmayı bırakıp bunun yerine snapshot'ı geri yükleme zamanının nasıl belirleneceğini açıklar.

Adım 5: Yapılandırma dosyası istemlerini dikkatli 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, paketle gelen sürüm ise 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, ayarları daha sonra karşılaştırarak eşitleyin.

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

Listelenen her dosya, sizinkinin yanına kaydedilmiş olan paket sorumlusunun sürümüdür. Bunları tek tek karşılaştırın (diff) ve önemli olan ayarları kendi dosyanıza aktarın. İki dosya için ekstra dikkat gösterilmelidir: /etc/ssh/sshd_config, çünkü yanlış cevap oturumunuzu sonlandırır; web sunucusu yapılandırmanız ise yanlış cevap sitelerin erişilemez olmasına yol açar.

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 sonraki bir istek sırasında, siz izlemiyorken çö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 sürüm bir kernel göstermelidir. systemctl --failed komutu sıfır birim listelemelidir; listelenen herhangi bir birim varsa, bir sonraki göreviniz bu birimleri incelemektir. Son olarak apt update komutu, sürüm imajları oluşturulduktan sonra yayınlanan güncellemeleri çeker.

PostgreSQL 16'dan 18'e: sessizce geride kalan küme

Ubuntu 24.04, PostgreSQL 16 sürümüyle gelir; 26.04 ise PostgreSQL 18 sürümünü sunar. Yükseltme işlemi, 18 sürümünü 16'nın yanına kurar ve verilerinizi taşımaz. Debian'ın postgresql-common katmanı, bir sonraki boş port üzerinde yeni ana sürüm için boş bir küme oluşturur. Bu nedenle 16, tüm verilerinizle birlikte 5432 numaralı portta kalmaya devam ederken, 18 sürümü 5433 numaralı portta boş olarak bekler. Uygulamanız 5432 numaralı portla 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 kümesini silin, çünkü pg_upgradecluster halihazırda var olan bir hedef kümeye yazma yapmaz. Varsayılan yöntem, 16 kümesinin yedeğini alır ve 18 kümesine 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 bittiğinde Port sütununu okuyun: 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üklenmiş bir küme istatistiklere sahip değildir ve ilk sorgular yavaş çalışacaktır.

Uygulamayı birkaç gün boyunca yeni küme üzerinde test edin. Yalnızca bu sürenin sonunda eski kümeyi kaldırın:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

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

MySQL 8.0'dan 8.4'e: sunucuyu durduran 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şlatmayı reddeder. default_authentication_plugin, eski kılavuzların çoğunda ayarlanması önerildiği için en sık karşılaşılan seçenektir. 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 artık varsayılan olarak etkin değildir; bu nedenle bu eklentiyi kullanan bir hesap sisteme giriş yapamaz. 8.0 sürümündeyken şu kontrolü yapın:

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 yalnızca geçici bir çözüm olarak değerlendirin.

PHP 8.3'ten 8.5'e geçiş: vhost'larınız artık var 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ü yollara kurulur ve hiçbir işlem web sunucusu yapılandırmanızı otomatik olarak güncellemez. 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

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

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

Sunucuyu Ubuntu 24.04 üzerinde bir LAMP yığını rehberini kullanarak kurduysanı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 otomatik olarak taşınmaz. memory_limit, upload_max_filesize ve yapılandırdığı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 (diff) ve değerleri manuel olarak kopyalayı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 yüklenen bir eklenti, kendi php8.5- paketine ihtiyaç duyar; eğer bu eklenti bir PPA'dan geldiyse, yükseltme işlemi bu kaynağı devre dışı bırakmış olabilir ve eklenti basitçe eksik kalır.

Sertifikalar ayrıca kontrol edilmelidir. 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ı (hook) 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, bu aşamada 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 paket yapılandırması 22 numaralı portu dinliyorsa, bir sonraki bağlantı reddedilir ve o an 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 esas alır; bu nedenle en üstte yer alan bir drop-in dosyası, altındaki her şeyden önceliklidir. 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ı verirseniz verin ayarlarınız korunur, çünkü bunlar farklı bir dosyada tutulmaktadır.

Özel bir port kullanıyorsanız bir kontrol daha yapmanız gerekir, çünkü port beklediğiniz yerde olmayabilir:

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; Port 2222 üzerinde yapılan bir değişikliğin etkisiz görünmesinin nedeni budur. Ayarı bunun yerine socket birimi üzerinde, sudo systemctl edit ssh.socket ile yapın:

[Socket]
ListenStream=
ListenStream=2222

Boş ListenStream= değeri gereklidir. Bu değer, devralınan ayarı 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ükseltme işleminden 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. İkinci oturumu başarıyla açana 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 artık çok geçse, 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. Konsol erişimini yükseltme sırasında değil, öncesinde test etmenizin nedeni tam olarak bu konsolun varlığıdır.

FAQ

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

Çünkü /etc/update-manager/release-upgrades dosyası, Ubuntu Server üzerinde Prompt=lts ayarını 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. Bu tarihe kadar 24.04 sunucusu yeni bir sürüm görmeyecektir. Sizi ara sürümlere yönlendirecek olan Prompt=normal ayarına geçmek yerine, mevcut ayarı değiştirmeden bırakmanız önerilir.

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" yapılmak üzere açık bırakılan bir makine, iki farklı sürümün karışımıyla çalışıyor demektir. Makine açıldıktan sonra yeni çekirdeği doğrulamak için uname -r komutunu, çalışmayan servisleri kontrol etmek için ise systemctl --failed komutunu kullanın.

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 üzerinde yığını kurabilir, verileri geri yükleyebilir ve eski sunucu trafiği karşılamaya devam ederken her şeyi test edebilirsiniz; böylece geri dönüş, yedekten dönmek yerine basit bir DNS değişikliği olur. Yerinde yükseltmeyi ise taşınması zor veriler barındıran sunucularda, sağlayıcının makine başına ücretlendirme yaptığı durumlarda veya elinizde bir snapshot ve kanıtlanmış konsol erişimi olduğunda tercih edin. Yerinde yükseltme yolu iyi test edilmiş bir yöntemdir ancak işlem süresince geri dönüşü olmayan bir yoldur.

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 arka planda çalışmaya devam eder; böylece tekrar bağlanıp tmux attach -t upgrade komutuyla kaldığınız yerden devam edebilirsiniz. Yükseltme aracı ayrıca 1022 numaralı port üzerinde yedek bir SSH daemon başlatır, ancak bu port için güvenlik duvarını otomatik açmaz; bu nedenle 1022 numaralı porta önceden izin vermeli ve işlem sonunda kapatmalısınız.

Yükseltme sonrası PHP sitem 502 hatası veriyor. Ne bozuldu?

PHP FPM soket yolu sürümle birlikte değişti. Ubuntu 24.04 PHP 8.3 kullanırken, 26.04 PHP 8.5 kullanı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. mod_php kullanan Apache sunucularında ise eşdeğer çözüm sudo a2dismod php8.3 komutunu çalıştırmak, ardından sudo a2enmod php8.5 ile servisi yeniden başlatmaktır.