Jinsi ya kupandisha toleo la Ubuntu 24.04 kwenda 26.04

Ni lini unaweza kupandisha toleo la Ubuntu 24.04 kwenda 26.04?

Unaweza kupandisha toleo la Ubuntu 24.04 kwenda 26.04 kwenye VPS pindi toleo la marekebisho la 26.04.1 litakapotolewa, 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 kupandisha toleo kutoka LTS moja kwenda nyingine kwenye toleo la kwanza la marekebisho pekee, kwa sababu toleo hilo hukusanya marekebisho ya hitilafu za usakinishaji na upandishaji zilizopatikana katika miezi ya kwanza.

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

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 LTS pekee, na pale tu toleo lake la marekebisho la .1 linapokuwepo. 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 wewe mwenyewe, kwenye seva yako, kwa mpangilio uliotolewa. Upandishaji wa toleo hauwezi kufanyiwa mazoezi kwenye mashine unayopandisha. Inachukua nafasi ya kernel na maktaba ya C, na inahitaji kuanzishwa upya (reboot) ili kukamilika.

Je, unapaswa kufanya upgrade hata kidogo?

Ubuntu 24.04 hupokea masasisho ya kawaida ya usalama hadi mwaka 2029, kwa hivyo seva inayofanya kazi vizuri haina shinikizo la muda. Fanya upgrade kwa sababu unahitaji 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 watu wengine ambayo haijachapisha toleo kwa ajili ya resolute bado.
• Seva ilijengwa kwa mikono 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 inapojibu kwa usahihi. Unaiacha seva ya zamani ikiendelea kufanya kazi hadi ile mpya ithibitishe ubora wake, 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 kwa njia tofauti. Snapshot ya mtoa huduma inashughulikia diski nzima na kurejesha ndani ya dakika chache, lakini inachukuliwa wakati database zako zinaandika, kwa hivyo ni "crash consistent" badala ya "application consistent". Backup ya kiwango cha faili kwa kutumia restic, iliyohifadhiwa nje ya seva inakupa faili moja moja na nakala inayoweza kuokoka ikiwa akaunti yako itafungwa.

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

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 thabiti kwa ajili ya meza za InnoDB pekee. Meza za MyISAM zinahitaji database kusimamishwa. Tarball ya /etc ndiyo utakayotumia zaidi, kwa sababu inashikilia kila faili ya usanidi ambayo uboreshaji utakuuliza maswali kuihusu.

Backup ambayo hujawahi kuirejesha ni makisio tu. Vuta faili moja kutoka humo sasa, kabla hujaihitaji wakati wa dharura.

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 hufanya kila hitilafu ya baadaye kuwa ngumu kusomeka.

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

dpkg --audit kutotoa matokeo yoyote inamaanisha hakuna kifurushi kilichosanidiwa nusu. apt-mark showhold kutotoa matokeo yoyote inamaanisha hakuna kifurushi kilichofungiwa (pinned) kwenye toleo ambalo lingezuia 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 ufanye uboreshaji ukiwa kwenye mashine inayoendesha code inayodhani inaendesha.

[ -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 ikiwa hakuna nafasi ya kutosha.

df -h / /boot

Kuwa na nafasi chini ya 5 GB kwenye / ndipo mambo yanapoharibika. /boot iliyo chini ya 300 MB hushindwa baadaye, wakati wa usakinishaji wa kernel, kwa ujumbe wa 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 masasisho ya usalama ya kiotomatiki yataanza katikati ya mchakato, yatashikilia lock ya dpkg, na kifaa cha kuboresha toleo kitasimama kwa Could not get lock /var/lib/dpkg/lock-frontend. Endesha sudo systemctl stop unattended-upgrades kwanza na uanze tena mchakato ukimaliza.

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 kilichojengwa kwa ajili ya noble kinaweza kuharibu mfumo wa resolute. Hurejesha vile inavyovitambua baadaye na kuacha vingine vikiwa na alama ya maoni (commented out). Jua unachobeba kabla ya zana hii haijakuamulia.

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: muundo wa zamani wa mstari mmoja wa faili za .list, na faili za deb822 .sources zenye sehemu za Types: na Suites:. Zote huzimwa wakati wa uboreshaji. ubuntu-security-status --thirdparty huorodhesha vifurushi vilivyosakinishwa ambavyo hazina ya Ubuntu haitoi, 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 hufichua saraka hiyo hiyo. Chanzo kilichoelekezwa 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 amejenga ndiyo njia unayosakinisha vifurushi vilivyounganishwa na maktaba (libraries) za mfumo zisizo sahihi.

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

Ikiwa muunganisho wako utakatika wakati do-release-upgrade inafanya kazi kwenye login shell ya kawaida, mchakato huo hupokea SIGHUP na kufa katikati ya hatua ya kufungua faili (unpacking). Hii inaiacha dpkg ikiwa imesanidiwa nusu, na seva inaweza kukosa mtandao wa kufanya kazi ili uweze kuunganisha tena. Endesha mchakato huu ndani ya terminal multiplexer badala yake, 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 kuuliza itakuwa ni mshangao mbaya. 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 anaendesha 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 (script). Kila ombi ni faili uliyohariri kwa makusudi, na kubonyeza enter ili kuliondoa ni njia inayofanya seva iliyoimarishwa kurejea kwenye hali ya kawaida (default) bila kujijua.

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 hifadhi 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 vigezo vipya vya 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 (maintainer), lililohifadhiwa kando ya faili yako. Linganisha (diff) moja baada ya nyingine na unakili mipangilio muhimu. Mbili kati ya hizo zinahitaji uangalifu wa ziada: /etc/ssh/sshd_config, kwa sababu jibu lisilo sahihi litakata kikao chako (session), na usanidi wa seva yako ya wavuti, kwa sababu jibu lisilo sahihi litazima tovuti zako.

Uboreshaji (upgrade) pia huuliza ni huduma zipi zianzishwe upya, kupitia needrestart. Kubali orodha nzima. Daemon inayoendelea kufanya kazi dhidi ya faili ya maktaba (shared library) iliyofutwa kwenye diski itaanguka (crash) wakati wa ombi la baadaye, wakati ambapo huangalii.

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 7.0. systemctl --failed inapaswa kuorodhesha unit sifuri, na chochote itakachoonyesha ni kazi yako inayofuata. apt update ya mwisho inavuta masasisho yaliyochapishwa tangu picha za toleo (release images) 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 husakinisha toleo la 18 kando ya 16 na haihamishi data zako. Safu ya postgresql-common ya Debian hutengeneza cluster mpya tupu kwa ajili ya toleo jipya kwenye port inayofuata iliyo wazi, kwa hivyo 16 inabaki na port 5432 ikiwa na data zako zote na 18 inakaa 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 zilizoorodheshwa 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 tupu ya 18 kwanza, kwa sababu pg_upgradecluster haitaandika kwenye cluster lengwa ambayo tayari ipo. Njia ya kawaida hufanya dump ya 16 na kuipakia upya kwenye 18, kwa hivyo unahitaji nafasi ya diski inayokaribia 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 inachukua port 5432 na ile ya zamani inaachwa ikiwa imesimamishwa. Endesha hatua ya analyze wewe 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 kurudisha hali ya awali (rollback) uliyonayo. 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 yanatatiza 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 haijawezeshwa 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 kuboresha, 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 lenye tarehe ya mwisho, kwa sababu plugin hiyo inaondolewa kabisa.

PHP 8.3 hadi 8.5: vhosts zako zinaelekeza kwenye socket ambayo haipo

Toleo la 24.04 linakuja na PHP 8.3 na 26.04 linakuja na PHP 8.5. Vifurushi hivi husakinishwa kwenye njia zenye namba za toleo na hakuna kinachobadilisha usanidi wa seva yako ya wavuti. Nginx vhost inayoshikilia fastcgi_pass unix:/run/php/php8.3-fpm.sock; sasa inaelekeza kwenye socket ambayo hakuna mchakato unaoiunda, kwa hivyo kila ombi la PHP linarudisha 502 na logi ya makosa ya nginx inasema:

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

Elekeza 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 inaripoti kuwa haiwezi kupakia libphp8.3.so kwa sababu faili hiyo haipo. 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 kutoka LAMP stack kwenye Ubuntu 24.04, njia zote mbili zinastahili kukaguliwa, kwa sababu mwongozo huo unakuacha 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 kinaishi 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 nzima ya zamani juu ya ile mpya 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, kisasishaji kimezima chanzo hicho na kiendelezi hicho hakipo kabisa.

Vyeti (certificates) vinastahili ukaguzi wa pekee. Endesha sudo certbot renew --dry-run baada ya kisasisho. Hii inajaribu njia nzima ya kufanya upya (renewal), ikijumuisha hook ya kupakia upya seva ya wavuti, bila kugusa cheti kinachotumika sasa. Hook inayopiga 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 hook hizo zinavyopaswa kuonekana.

SSH: hitilafu inayokatisha session unayotumia

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 uliyopo ndiyo ya mwisho uliyonayo.

Izuie 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 inayosoma 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 kitu katika /etc/ssh/sshd_config kilicho chako, prompt hiyo haitaleta shida tena: jibu lolote litahifadhi mipangilio yako, kwa sababu ipo kwenye faili tofauti.

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

systemctl is-enabled ssh.socket

Ikiwa hiyo itachapisha enabled, systemd ndiyo inayomiliki port inayotumika kusikiliza na mstari wa Port katika sshd_config hupuuzwa. Ubuntu imekuwa ikitumia socket activation kwa sshd tangu 22.10, na hii ndiyo sababu uhariri wa Port 2222 unaonekana kutofanya kazi. Iweke kwenye socket unit badala yake, kwa kutumia sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

Sehemu tupu ya ListenStream= 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 uliyopo:

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 na hiyo ya pili. 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 hapo, rekebisha usanidi, endesha sudo sshd -t, anzisha upya huduma. Console hiyo ndiyo sababu hasa unapaswa kupima ufikiaji wa console 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 chochote. Acha mpangilio huo badala ya kubadilisha kwenda Prompt=normal, ambayo ingekuelekeza kwenye matoleo ya mpito badala yake.

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

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

Je, nifanye upgrade kwenye mfumo uliopo au nijenge seva mpya ya 26.04?

Jenga seva mpya inapowezekana. VPS mpya inakuwezesha kusakinisha stack, kurejesha data, na kupima kila kitu wakati seva ya zamani bado inahudumia traffic, hivyo rollback inakuwa ni mabadiliko ya DNS badala ya kurejesha kutoka kwenye backup. Fanya upgrade kwenye mfumo uliopo 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 ile inayoendelea.

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

Katika shell ya kawaida ya login, mchakato hupokea SIGHUP na kufa katikati, jambo linaloacha dpkg ikiwa imesanidiwa nusu. Anzisha mchakato ndani ya tmux au screen na mchakato utaendelea kuwepo, hivyo utaunganisha tena na kuendesha tmux attach -t upgrade ili kuendelea. Upgrader pia huanzisha SSH daemon ya ziada kwenye port 1022 kama njia ya pili ya kuingia, lakini haifungui firewall kwa ajili ya 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 inaendesha PHP 8.3 na 26.04 inaendesha PHP 8.5, kwa hivyo /run/php/php8.3-fpm.sock haipo tena wakati nginx vhost yako bado inaitumia. 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 uwashe upya nginx. Kwenye Apache na mod_php, marekebisho yanayolingana ni sudo a2dismod php8.3 ikifuatiwa na sudo a2enmod php8.5 na restart.