Jinsi ya kufanya upgrade ya Ubuntu 24.04 kwenda 26.04

Ni lini unaweza kufanya upgrade ya Ubuntu 24.04 kwenda 26.04?

Unaweza kufanya upgrade ya Ubuntu 24.04 kwenda 26.04 kwenye VPS pindi tu toleo la 26.04.1 litakaposhushwa, ambalo limepangwa tarehe 27 Agosti 2026. Hadi wakati huo, seva ya 24.04 haitaona toleo jipya, kwa makusudi. Ubuntu 26.04 LTS (Resolute Raccoon) ilitolewa tarehe 23 Aprili 2026, lakini Canonical hufungua njia ya upgrade kutoka LTS kwenda LTS kwenye toleo la kwanza la point release pekee, kwa sababu toleo hilo hukusanya hitilafu za usakinishaji na upgrade zilizopatikana katika miezi ya kwanza. Ikiwa mfumo wa namba ni mpya kwako, 26.04.1 si Ubuntu tofauti bali ni 26.04 ileile ikiwa na marekebisho ya miezi minne yaliyojumuishwa kwenye media, na ndiyo sababu hasa ni toleo la kwanza ambalo Canonical itatoa kwa seva iliyopo.

Endesha ukaguzi kwenye mashine ya 24.04 mapema Agosti 2026 na utapata hivi:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

Hiyo si hitilafu kwenye seva yako. /etc/update-manager/release-upgrades ina Prompt=lts kwenye Ubuntu Server, jambo linalomaanisha kuwa zana hiyo hutoa toleo lijalo la long term support pekee, na pale tu toleo lake la .1 point release litakapokuwepo. Kuweka Prompt=normal badala yake kutakuongoza kupitia 24.10, 25.04 na 25.10 mfululizo, matoleo ya muda ambayo yote yamefikia mwisho wa maisha yake. Iache kwenye lts na usubiri. Tarehe kwenye ratiba ya Canonical zinaweza kubadilika, kwa hivyo ikague tena ikiwa siku hiyo itapita bila tukio lolote.

Kila amri hapa chini ni ile unayoiendesha mwenyewe, kwenye seva yako, kwa mpangilio uliotolewa. Upgrade ya toleo haiwezi kufanyiwa mazoezi kwenye mashine unayofanyia upgrade. Inachukua nafasi ya kernel na maktaba ya C, na inahitaji reboot ili kukamilika.

Je, unapaswa kufanya upgrade hata kidogo?

Ubuntu 24.04 hupokea masasisho ya kawaida ya usalama hadi 2029, kwa hivyo seva inayofanya kazi vizuri haina muda wa mwisho wa kufanyiwa upgrade. Fanya upgrade kwa sababu unataka kitu ambacho 26.04 inacho: PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 au kernel ya 7.0. "Namba imeongezeka" si sababu ya kugusa mashine inayohudumia wateja.

Usifanye upgrade ya moja kwa moja (in-place) ikiwa mojawapo ya haya ni kweli:

• Hujawahi kufungua console ya mtoa huduma wako (VNC au serial) na kuingia kupitia huko. Console hiyo ndiyo njia pekee ya kurudi kwenye seva ikiwa SSH itafeli, na kugundua kuwa haifanyi kazi wakati umefungiwa nje ni kuchelewa mno.
• Huwezi kumudu saa moja ya downtime na huna njia ya kurudisha hali ya awali (rollback).
• Stack yako inategemea repository ya wahusika wengine ambayo haijachapisha toleo la resolute bado.
• Seva ilijengwa kwa mkono kwa zaidi ya miaka miwili na hakuna anayejua kilichomo ndani yake.

Njia mbadala mara nyingi ni bora zaidi: jenga VPS mpya ya 26.04, sakinisha stack yako na urejeshe data, kisha ubadilishe DNS mara tu itakapojibu kwa usahihi. Unaiacha seva ya zamani ikiendelea kufanya kazi hadi ile mpya itakapojithibitisha, na rollback inakuwa ni mabadiliko ya DNS badala ya urejeshaji wa data. Ikiwa utachagua njia hiyo, anza na dakika kumi za kwanza kwenye VPS mpya na ujenge mashine hiyo mpya kwa usahihi.

Hatua ya 1: tengeneza backup unayoweza kuirejesha

Tumia tabaka mbili, kwa sababu hushindwa kufanya kazi kwa njia tofauti. Snapshot ya mtoa huduma inashughulikia diski nzima na inarejesheka ndani ya dakika chache, lakini inachukuliwa wakati database zako zinaandika data, hivyo inakuwa na hali ya "crash consistent" badala ya "application consistent". Backup ya kiwango cha faili kwa kutumia restic, inayohifadhiwa nje ya seva inakupa faili moja moja na nakala inayoweza kuokoka hata kama akaunti yako itafungwa.

Fanya dump ya database kwa mikono kwanza. Dump ndiyo backup pekee ya database unayoweza kuiamini bila kuizima.

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 inatoa dump iliyo thabiti kwa meza za InnoDB pekee. Meza za MyISAM zinahitaji database izimwe. Faili la /etc ndilo utakalolitumia zaidi, kwa sababu lina kila faili la usanidi ambalo litakuuliza maswali wakati wa upgrade.

Backup ambayo hujawahi kuirejesha ni kubahatisha tu. Toa faili moja kutoka humo sasa hivi, kabla hujahitaji kufanya hivyo ukiwa chini ya shinikizo.

Hatua ya 2: fanya patch kamili ya 24.04 kwanza

do-release-upgrade inakataa kufanya kazi kwenye mfumo wenye vifurushi vilivyoharibika, na 24.04 iliyofanyiwa patch nusu inafanya kila hitilafu itakayotokea baadaye kuwa ngumu kusomeka.

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

dpkg --audit kutochapisha chochote inamaanisha hakuna kifurushi kilichosanidiwa nusu. apt-mark showhold kutochapisha chochote inamaanisha hakuna kifurushi kilichofungiwa (pinned) kwenye toleo ambalo linaweza kuzuia uboreshaji. Achia kifurushi chochote kinachoorodheshwa kwa kutumia sudo apt-mark unhold na jina la kifurushi hicho, au kubali kuwa kizuizi hicho kipo kwa sababu maalum na usitishe mchakato hapa.

Washa upya seva (reboot) ikiwa kernel imebadilika, ili uweze kufanya uboreshaji ukiwa kwenye mashine inayoendesha code inayotambua kuwa ndiyo inayoiendesha.

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

Kisha kagua nafasi ya diski. Kifaa cha kuboresha (upgrader) hupakua seti nzima ya vifurushi vipya kabla ya kusakinisha chochote, na husitisha mchakato kwa ujumbe unaotaja mfumo wa faili (filesystem) ikiwa hakuna nafasi ya kutosha.

df -h / /boot

Chini ya 5 GB ya nafasi iliyo wazi kwenye / ndipo mambo yanapoharibika. /boot iliyo chini ya 300 MB inashindwa baadaye, wakati wa usakinishaji wa kernel, na kuleta No space left on device. Kernel za zamani mara nyingi ndizo chanzo, na sudo apt --purge autoremove huziondoa.

Jambo moja zaidi la kusitisha kabla ya kuanza: ikiwa sasisho za usalama za kiotomatiki zikianza katikati ya mchakato, zitashikilia lock ya dpkg, na kifaa cha kuboresha toleo kitasimama na kuleta Could not get lock /var/lib/dpkg/lock-frontend. Endesha sudo systemctl stop unattended-upgrades kwanza na uanze tena mchakato utakapomaliza.

Hatua ya 3: kagua hazina za wahusika wengine na vifurushi vilivyofungiwa (pinned packages)

do-release-upgrade huzima kila chanzo cha apt ambacho si cha Ubuntu, kwa sababu kifurushi kilichoundwa kwa ajili ya noble kinaweza kuharibu mfumo wa resolute. Hurejesha vile inavyovitambua baadaye na kuacha vingine vikiwa na alama ya maoni (commented out). Fahamu unachobeba kabla chombo hiki hakijakufanyia maamuzi.

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 hutumia miundo miwili katika saraka hiyo: faili za zamani za mstari mmoja za .list, na faili za deb822 za .sources zenye sehemu za Types: na Suites:. Zote huzimwa na uboreshaji huu. ubuntu-security-status --thirdparty huorodhesha vifurushi vilivyosakinishwa ambavyo hakuna hazina ya Ubuntu inayovitoa, ambayo ndiyo idadi sahihi ya kile ulichoongeza. Kitu chochote kilicho katika /etc/apt/preferences.d/ ni pini (pin), na pini iliyoandikwa kwa ajili ya noble itaendelea kuchagua kifurushi cha zamani kwenye toleo jipya.

Kwa kila hazina ya mhusika mwingine, thibitisha kuwa muuzaji amechapisha kwa ajili ya codename mpya kabla ya kuanza. Suite za Docker zimeorodheshwa katika https://download.docker.com/linux/ubuntu/dists/, na wauzaji wengine hutoa saraka hiyo hiyo. Chanzo kinachoelekeza kwenye suite isiyokuwepo hutoa ujumbe huu kwenye apt update ya kwanza baada ya uboreshaji:

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

Acha chanzo hicho kikiwa kimezimwa hadi muuzaji atakapochapisha. Kuhariri codename ili iwe ile ambayo muuzaji ameiunda ndiyo njia unayosakinisha vifurushi vilivyounganishwa na maktaba (libraries) za mfumo zisizo sahihi.

Hatua ya 4: endesha uboreshaji ndani ya tmux, siyo kwenye shell ya kawaida ya SSH

Ikiwa muunganisho wako utakatika wakati do-release-upgrade inafanya kazi kwenye shell ya kawaida ya login, mchakato huo hupokea SIGHUP na kufa katikati ya hatua ya unpacking. Hii inaiacha dpkg ikiwa imesanidiwa nusu, na seva inaweza kupoteza uwezo wa mtandao wa kukuwezesha kuunganisha tena. Endesha mchakato huu ndani ya terminal multiplexer ili mchakato uendelee kuwa hai kwenye seva hata kama mteja wako atatoka.

sudo apt install -y tmux
tmux new -s upgrade

Ndani ya session hiyo:

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

Kiboreshaji huanzisha daemon ya pili ya SSH kwenye port 1022 kabla ya kubadilisha chochote, na hutoa taarifa hiyo:

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.

Haifungui firewall yako kwa ajili ya port hiyo, kwa sababu kutoboa shimo kwenye firewall bila idhini ni jambo lisilofaa. Fungua port 1022 mwenyewe kabla ya kuanza, na uifunge utakapomaliza kwa kutumia sudo ufw delete allow 1022/tcp. Kumbuka kuwa mtoa huduma wako anaweza kuwa na firewall ya pili kwenye control panel yake, nje ya seva.

Ikiwa muunganisho utakatika hata hivyo, ingia tena na uendeshe tmux attach -t upgrade. Uboreshaji uliendelea kufanya kazi wakati haupo.

Hatua ya 5: jibu maombi ya faili ya usanidi kwa umakini

dpkg huomba maoni tu kwa faili ulizozibadilisha wewe au hati fulani. Kwa hivyo, kila ombi ni faili uliyoiandika kwa makusudi, na kubonyeza enter ili kuliondoa ni njia inayofanya seva iliyoimarishwa kurejea kwenye hali ya kawaida kimyakimya.

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

Bonyeza D kwanza, kila wakati. Soma kilichobadilika, kisha weka toleo lako kwa kutumia N. Chaguo-msingi tayari ni N, ambalo ndilo jibu salama, kwa sababu faili yako inafanya kazi leo na ile inayokuja na kifurushi haijawahi kuendeshwa kwenye mashine hii.

Kuhifadhi faili yako kuna gharama: hupati mipangilio mipya ya chaguo-msingi. Fanya upatanisho baadaye, seva ikiwa imewaka na huna shinikizo la muda.

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

Kila faili inayoorodheshwa ni toleo la mtunza kifurushi, lililohifadhiwa kando ya faili yako. Linganisha faili hizo moja baada ya nyingine na unakili mipangilio muhimu. Mbili kati ya hizo zinahitaji uangalizi wa ziada: /etc/ssh/sshd_config, kwa sababu jibu lisilo sahihi litakatisha kikao chako, na usanidi wa seva yako ya wavuti, kwa sababu jibu lisilo sahihi litazima tovuti zako.

Uboreshaji pia huuliza ni huduma zipi zianzishwe upya, kupitia needrestart. Kubali orodha nzima. Daemon inayoendelea kufanya kazi huku ikitumia faili ya maktaba iliyofutwa kwenye diski itaanguka wakati wa ombi la baadaye, wakati ambao huwezi kuwa unaifuatilia.

Hatua ya 6: anzisha upya seva, kisha kagua mashine

sudo reboot

Baada ya seva kuwaka tena:

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 inapaswa kuripoti Release: 26.04 na Codename: resolute. uname -r inapaswa kuonyesha kernel ya toleo la 7.0. systemctl --failed inapaswa kuorodhesha unit sifuri, na chochote kitakachoonekana hapo ndicho kazi yako inayofuata. Amri ya mwisho ya apt update inapakua masasisho yaliyochapishwa tangu picha za toleo hilo zilipoundwa.

PostgreSQL 16 hadi 18: cluster inayobaki nyuma kimya kimya

Ubuntu 24.04 inakuja na PostgreSQL 16 na 26.04 inakuja na PostgreSQL 18. Uboreshaji huu huweka toleo la 18 kando ya 16 na hauhishi data yako. Safu ya postgresql-common ya Debian hutengeneza cluster mpya tupu kwa ajili ya toleo jipya kwenye port inayofuata iliyo wazi, hivyo 16 huendelea kutumia port 5432 ikiwa na data yako yote, na 18 hukaa ikiwa tupu kwenye 5433. Programu yako inaendelea kuwasiliana na 5432 na hakuna kinachoonekana kuwa kibaya, ndiyo maana watu hugundua hili miezi kadhaa baadaye.

pg_lsclusters

Kuwa na cluster mbili kwenye orodha inamaanisha hujafanya uhamiaji. Fanya hivyo wakati unaweza kusimamisha programu:

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

Futa cluster ya 18 iliyo tupu kwanza, kwa sababu pg_upgradecluster haitaandika kwenye cluster lengwa ambayo tayari ipo. Njia ya kawaida hutoa dump ya 16 na kuipakia kwenye 18, kwa hivyo unahitaji nafasi ya diski inayolingana na ukubwa wa database. -m upgrade hutumia pg_upgrade badala yake na ni ya haraka zaidi kwenye database kubwa. Ikimaliza, soma safu ya Port: cluster mpya huchukua port 5432 na ile ya zamani huachwa ikiwa imesimamishwa. Fanya hatua ya analyze mwenyewe, kwa sababu cluster iliyopakiwa upya haina takwimu na queries za kwanza zitakuwa polepole.

Jaribu programu dhidi ya cluster mpya kwa siku chache. Baada ya hapo ndipo uiondoe ile ya zamani:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

Saraka ya data ya cluster ya zamani ndiyo njia ya haraka zaidi ya kurudi kwenye hali ya awali (rollback) uliyo nayo. Usiifute siku ya uboreshaji.

MySQL 8.0 hadi 8.4: chaguo lililoondolewa linalosimamisha seva

26.04 inahamisha MySQL kutoka 8.0 hadi 8.4 LTS, na mabadiliko mawili huathiri seva.

Kwanza, mysqld inakataa kuanza wakati usanidi wake una chaguo ambalo toleo jipya limeondoa. default_authentication_plugin ndilo chaguo la kawaida, kwa sababu miongozo mingi ya zamani inakuelekeza kuliweka. Huduma inafeli, na journalctl -u mysql -n 50 inataja kigezo kisichotambulika moja kwa moja. Futa mstari huo kutoka kwenye faili iliyo chini ya /etc/mysql/mysql.conf.d/, kisha sudo systemctl start mysql.

Pili, plugin ya mysql_native_password haiwezeshwi tena kwa chaguo-msingi katika 8.4, kwa hivyo akaunti inayotumia plugin hiyo haiwezi kuingia kabisa. Hakikisha hili ukiwa bado kwenye 8.0:

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

Hamisha kila akaunti inayoonyesha mysql_native_password kabla ya kufanya upgrade, kisha sasisha nenosiri katika usanidi wa programu yako:

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

Ikiwa maktaba ya mteja (client library) ni ya zamani sana kiasi cha kutoweza kutumia caching_sha2_password, unaweza kuwasha tena plugin ya zamani katika 8.4 kwa kuongeza mysql_native_password=ON chini ya [mysqld]. Ichukulie hii kama daraja la muda mfupi, kwa sababu plugin hiyo inaondolewa kabisa.

PHP 8.3 hadi 8.5: vhost zako zinaelekeza kwenye socket iliyopotea

24.04 inakuja na PHP 8.3 na 26.04 inakuja na PHP 8.5. Vifurushi hivi husakinishwa kwenye njia zenye matoleo maalum na hakuna kinachobadilisha usanidi wa seva yako ya wavuti. Vhost ya nginx inayoshikilia fastcgi_pass unix:/run/php/php8.3-fpm.sock; sasa inaelekeza kwenye socket ambayo hakuna mchakato unaoiunda, kwa hivyo kila ombi la PHP hurejesha 502 na logi ya makosa ya nginx inasema:

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

Ielekeze kwenye socket mpya, jaribu usanidi, kisha uupakie upya:

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

Kwenye Apache inayotumia mod_php dalili ni tofauti: Apache haitaanza kabisa, na sudo apache2ctl -t itaripoti kuwa haiwezi kupakia libphp8.3.so kwa sababu faili hilo halipo. Moduli iliyowezeshwa ni symlink inayoelekeza kwenye kifurushi ambacho hakipo tena.

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

Ikiwa uliunda seva hiyo kufuatia LAMP stack kwenye Ubuntu 24.04, njia zote mbili zinastahili kukaguliwa, kwa sababu mwongozo huo hukuacha na jina la moduli lenye toleo na socket yenye toleo.

Usanidi wako wa php.ini hauhami pia. memory_limit, upload_max_filesize na chochote kingine ulichoweka kipo ndani ya /etc/php/8.3/, na mti mpya wa faili huanza na mipangilio ya awali (defaults). Linganisha faili hizo mbili na unakili thamani hizo kwa mkono. Kunakili faili zima la zamani juu ya jipya kutaleta mipangilio ya 8.3 kwenye usakinishaji wa 8.5. Kisha endesha php -m na ulinganishe: kiendelezi (extension) kilichosakinishwa kama php8.3-redis kinahitaji kifurushi chake cha php8.5-, na ikiwa kilitoka kwenye PPA, kiondoa-kikwazo cha mfumo kimezima chanzo hicho na kiendelezi hicho hakipo kabisa.

Vyeti (certificates) vinastahili ukaguzi wa pekee. Endesha sudo certbot renew --dry-run baada ya kuboresha mfumo. Hii hujaribu njia nzima ya ufanyaji upya (renewal), ikijumuisha hatua ya kupakia upya seva ya wavuti, bila kugusa cheti kinachotumika. Hatua inayoiita jina la huduma au binary iliyobadilika itafeli hapa, mbele yako, badala ya kufeli kimya kimya baada ya siku 60. Certbot na Let's Encrypt kwenye nginx inaelezea jinsi hatua hizo zinavyopaswa kuonekana.

SSH: hitilafu inayokatisha session unayofanyia kazi

Prompt ya sshd_config ndipo watu hujifungia nje. Kujibu Y husakinisha faili ya maintainer, jambo linalofuta PermitRootLogin, PasswordAuthentication, AllowUsers, Port yako na kila mstari mwingine uliouongeza. Ikiwa firewall yako inaruhusu port maalum pekee na usanidi wa kifurushi unasikiliza kwenye 22, muunganisho unaofuata utakataliwa, na session uliyokaa ndiyo ya mwisho uliyonayo.

Zuia hili kabla ya kufanya upgrade. /etc/ssh/sshd_config kwenye 24.04 huanza na Include /etc/ssh/sshd_config.d/*.conf, na OpenSSH huhifadhi thamani ya kwanza inayoisoma kwa kila mpangilio, kwa hivyo drop-in iliyowekwa juu hushinda chochote kilicho chini. Hamisha mipangilio yako kwenye faili ambayo dpkg haimiliki:

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

Pindi hakuna chochote katika /etc/ssh/sshd_config kilicho chako, prompt hiyo huacha kuwa na umuhimu: jibu lolote litahifadhi mipangilio yako, kwa sababu inaishi kwenye faili tofauti.

Port maalum inahitaji ukaguzi mmoja zaidi, kwa sababu inaweza isiwe mahali unapofikiri:

systemctl is-enabled ssh.socket

Ikiwa hiyo itachapisha enabled, systemd inamiliki port inayosikiliza na mstari wa Port katika sshd_config hupuuzwa. Ubuntu imetumia socket activation kwa sshd tangu 22.10, na hii ndiyo sababu edit ya Port 2222 inaonekana kutofanya chochote. Iweke kwenye socket unit badala yake, kwa kutumia sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

ListenStream= tupu inahitajika. Inafuta thamani iliyorithiwa, na bila hiyo socket itasikiliza kwenye 22 pamoja na 2222. Itekeleze kwa sudo systemctl daemon-reload && sudo systemctl restart ssh.socket.

Baada ya upgrade, kabla ya kufunga session uliyomo:

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

Kisha fungua terminal ya pili kwenye mashine yako na uingie tena. Shell inayofanya kazi katika terminal hiyo ya pili ndiyo uthibitisho pekee unaohesabika. Weka session ya kwanza ikiwa wazi hadi uwe nayo. Kuimarisha usalama wa SSH kwenye VPS inapitia mipangilio inayostahili kuhifadhiwa kwenye drop-in hiyo.

Ikiwa tayari ni kuchelewa, web console ya mtoa huduma wako inakupa login isiyotumia SSH kabisa. Ingia huko, rekebisha config, endesha sudo sshd -t, anzisha upya huduma. Console hiyo ndiyo sababu hasa unapaswa kupima console access kabla ya upgrade badala ya wakati wa upgrade.

FAQ

Kwa nini do-release-upgrade inasema "No new release found" kwenye Ubuntu 24.04?

Kwa sababu /etc/update-manager/release-upgrades ina Prompt=lts kwenye Ubuntu Server, na mpangilio huo hutoa toleo linalofuata la long term support baada ya point release yake ya kwanza kuwepo. Ubuntu 26.04 LTS ilitolewa tarehe 23 Aprili 2026, na 26.04.1 imepangwa kutolewa tarehe 27 Agosti 2026. Hadi siku hiyo, seva ya 24.04 haitaona toleo jipya. Acha mpangilio huo badala ya kubadilisha kwenda Prompt=normal, ambayo ingekuelekeza kupitia matoleo ya mpito.

Je, ni lazima niwakishe seva upya (reboot) ili kukamilisha upgrade?

Ndiyo. Upgrade husakinisha kernel mpya, maktaba mpya ya C, na mfumo mpya wa init, na mfumo unaoendelea kufanya kazi utaendelea kutumia zile za zamani hadi uanzishwe upya. do-release-upgrade huomba reboot mwishoni, na mashine iliyoachwa ikiendelea kufanya kazi hadi "baadaye" ni mashine inayotumia mchanganyiko wa matoleo mawili. Baada ya kuwaka upya, angalia uname -r kwa kernel mpya na systemctl --failed kwa huduma ambazo hazikurejea vizuri.

Je, nifanye upgrade ya moja kwa moja au nijenge seva mpya ya 26.04?

Jenga seva mpya inapowezekana. VPS mpya hukuruhusu kusakinisha stack, kurejesha data, na kupima kila kitu wakati seva ya zamani bado inahudumia traffic, hivyo rollback ni mabadiliko ya DNS badala ya kurejesha kutoka kwenye backup. Fanya upgrade ya moja kwa moja wakati seva ina hali (state) ambayo ni ngumu kuhamisha, wakati mtoa huduma anatoza kwa kila mashine, au wakati una snapshot na uwezo wa kufikia console. Njia ya upgrade ya moja kwa moja inafahamika vyema, lakini ni njia isiyoweza kutenduliwa kwa saa nzima inayochukua.

Nini kitatokea kama muunganisho wangu wa SSH utakatika wakati wa upgrade?

Katika login shell ya kawaida, mchakato hupokea SIGHUP na kufa katikati, jambo linaloacha dpkg ikiwa imesanidiwa nusu. Ianzishe ndani ya tmux au screen na mchakato utaendelea, hivyo utaunganisha tena na kuendesha tmux attach -t upgrade ili kuendeleza. Upgrader pia huanzisha SSH daemon ya ziada kwenye port 1022 kama njia ya pili ya kuingia, lakini haifungui firewall kwa port hiyo, kwa hivyo ruhusu 1022 wewe mwenyewe kwanza na uifunge baadaye.

Tovuti yangu ya PHP inarejesha 502 baada ya upgrade. Nini kimeharibika?

Njia ya socket ya PHP FPM ilibadilika kulingana na toleo. Ubuntu 24.04 hutumia PHP 8.3 na 26.04 hutumia PHP 8.5, kwa hivyo /run/php/php8.3-fpm.sock haipo tena wakati nginx vhost yako bado inaitaja. Log ya makosa ya nginx inaonyesha connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory). Sasisha fastcgi_pass kwenda kwenye socket ya 8.5, endesha sudo nginx -t, kisha uanzishe upya nginx. Kwenye Apache na mod_php, marekebisho yanayolingana ni sudo a2dismod php8.3 ikifuatiwa na sudo a2enmod php8.5 na kuanzisha upya huduma.