วิธีแก้ปัญหา Ubuntu แจ้ง no new release found

เหตุใด do-release-upgrade จึงแจ้งว่าไม่พบ release ใหม่

do-release-upgrade ซึ่งลงท้ายด้วย No new release found. แทบจะไม่ใช่เครื่องมือที่เสียหาย เส้นทางที่คุณเรียกใช้ถูกปิดอยู่ในขณะนั้น และเครื่องมือรายงานสถานะดังกล่าวด้วยวิธีที่สั้นที่สุดเท่าที่จะทำได้ มี 5 ปัจจัยที่ทำให้เส้นทางนี้ถูกปิด ได้แก่ การตั้งค่า Prompt ใน /etc/update-manager/release-upgrades, เกณฑ์การอัปเกรดแบบ point release บน LTS (long term support), repository ของบุคคลที่สาม, แพ็กเกจที่ถูกระงับ (held) หรือกำหนดค่าไม่สมบูรณ์ และ release ที่สิ้นสุดระยะเวลาการสนับสนุนแล้ว

ให้ตรวจสอบตามลำดับดังกล่าว แต่ละหัวข้อมีคำสั่งที่ใช้ยืนยันว่าปัจจัยนั้นส่งผลต่อเซิร์ฟเวอร์ของคุณหรือไม่ เพื่อให้คุณไม่ต้องคาดเดาว่ากำลังเผชิญกับปัญหาใดใน 5 ปัจจัยนี้

What the check-only flag actually reports

sudo do-release-upgrade -c
echo $?

-c is check only. It reads Canonical's release metadata over HTTPS (hypertext transfer protocol secure) and prints the answer. It downloads no upgrade tool and rewrites no source file. Two outputs matter:

Checking for a new Ubuntu release
No new release found.

Checking for a new Ubuntu release
New release '26.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

The exit code carries the same answer for scripts. It is 0 when a release is available and 1 when none is, which is the reverse of the usual shell convention, so read it carefully before you build a check around it.

If your login banner still shows the old answer, it is cached. That line comes from /etc/update-motd.d/91-release-upgrade, which prints a stored result instead of asking the network. Refresh it with sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd, or just trust -c. The banner only repeats the result of the last check that ran.

The check also needs to reach changelogs.ubuntu.com. On a server behind a strict outbound firewall or a proxy the tool cannot ask, so it cannot find anything.

curl -sI https://changelogs.ubuntu.com/meta-release-lts | head -n 1

A HTTP/2 200 line means the server can see the metadata. A curl: (28) Connection timed out means your egress rules are the real cause, and no amount of editing APT (advanced package tool) files will change the answer.

If the command is missing entirely, it lives in ubuntu-release-upgrader-core. Minimal cloud images sometimes leave that package out.

sudo apt install ubuntu-release-upgrader-core

อ่านไฟล์ /etc/update-manager/release-upgrades ก่อนทำการเปลี่ยนแปลงใดๆ

cat /etc/update-manager/release-upgrades

[DEFAULT]
Prompt=lts

ไฟล์นี้มีเอกสารกำกับไว้ในส่วนของคอมเมนต์ โดยมีค่าที่ใช้งานได้ 3 ค่าดังนี้:

• never: ห้ามตรวจสอบและห้ามอนุญาตให้มีการอัปเกรดเป็นรุ่นใหม่โดยเด็ดขาด
• normal: เสนอการอัปเกรดเป็นรุ่นที่รองรับซึ่งถัดจากรุ่นที่ใช้งานอยู่ในปัจจุบันทันที
• lts: เสนอการอัปเกรดเป็นรุ่น LTS รุ่นแรกที่ถัดจากรุ่นที่ใช้งานอยู่ในปัจจุบัน

Prompt=never เป็นค่าที่วินิจฉัยปัญหาได้ง่ายที่สุดในบรรดาทั้งสามค่า เนื่องจากเครื่องมือจะระบุทั้งชื่อไฟล์และค่าการตั้งค่าไว้ในผลลัพธ์ที่แสดง:

Checking for a new Ubuntu release
In /etc/update-manager/release-upgrades Prompt is set to never so upgrading is not possible.

ผู้ให้บริการโฮสติ้งและเครื่องมือจัดการการตั้งค่ามักกำหนดค่า never ไว้โดยเจตนา เพื่อป้องกันไม่ให้กลุ่มเซิร์ฟเวอร์มีการอัปเกรดข้ามรุ่นไปมาโดยไม่ตั้งใจ หากคุณพบค่านี้ แสดงว่ามีผู้กำหนดไว้ ให้เปลี่ยนเป็น lts สำหรับเซิร์ฟเวอร์ที่คุณต้องการให้อยู่ในเส้นทางการสนับสนุนระยะยาว (LTS) และเปลี่ยนกลับเป็นค่าเดิมหลังจากนั้นหากระบบอัตโนมัติของคุณคาดหวังค่าดังกล่าว

มีรายละเอียดหนึ่งในคอมเมนต์เหล่านั้นที่มักทำให้ผู้ใช้งานสับสน เมื่อกำหนดค่า Prompt=lts ไว้และรุ่นที่ใช้งานอยู่ไม่ใช่รุ่น LTS ตัวอัปเกรดจะปฏิบัติต่อการตั้งค่านี้เสมือนเป็น normal บนเครื่องที่ใช้รุ่น 25.10 ค่าทั้งสองจะทำงานเหมือนกันทุกประการ แต่บนเครื่องที่ใช้รุ่น 24.04 จะไม่เป็นเช่นนั้น และความแตกต่างดังกล่าวคือเนื้อหาทั้งหมดของส่วนถัดไป

เหตุผลที่การอัปเกรดจาก LTS ไปยัง LTS ต้องรอจนกว่าจะถึง point release แรก

Prompt เป็นตัวกำหนดว่าโปรแกรมอัปเกรดจะอ่านไฟล์ metadata ใด โดยที่อยู่ของไฟล์เหล่านี้จะอยู่ใน /etc/update-manager/meta-release:

[METARELEASE]
URI = https://changelogs.ubuntu.com/meta-release
URI_LTS = https://changelogs.ubuntu.com/meta-release-lts
URI_UNSTABLE_POSTFIX = -development
URI_PROPOSED_POSTFIX = -proposed

Prompt=lts จะอ่านไฟล์ meta-release-lts ส่วน Prompt=normal จะอ่านไฟล์ meta-release ไฟล์ทั้งสองนี้จะอธิบายรายละเอียดของทุก release ไว้ในรูปแบบบล็อกของคีย์ และโปรแกรมอัปเกรดจะเสนอให้ทำการอัปเกรดก็ต่อเมื่อแฟล็ก Supported: มีค่าเป็น 1 เท่านั้น คุณสามารถตรวจสอบไฟล์เหล่านี้ได้ด้วยตนเองจากเซิร์ฟเวอร์เดียวกัน:

curl -s https://changelogs.ubuntu.com/meta-release-lts | grep -A 4 resolute
curl -s https://changelogs.ubuntu.com/meta-release | grep -A 4 resolute

จากการตรวจสอบเมื่อวันที่ 13 สิงหาคม 2026 พบว่าไฟล์ทั้งสองฉบับให้ข้อมูลเกี่ยวกับ Ubuntu 26.04 ไม่ตรงกัน โดยไฟล์ LTS ระบุว่า:

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 0

ในขณะที่ไฟล์ปกติระบุว่า:

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 1

ค่า Supported: 0 ในไฟล์ LTS คือประตูกั้น เซิร์ฟเวอร์ที่ใช้ 24.04 และตั้งค่า Prompt=lts เป็นค่าเริ่มต้นจะอ่านไฟล์ดังกล่าว เมื่อไม่พบ LTS release ใหม่ที่ระบุว่าพร้อมใช้งาน ระบบจะแสดงข้อความ No new release found. ซึ่งไม่ได้หมายความว่าเครื่องของคุณมีปัญหาแต่อย่างใด แต่เป็นเพราะ Canonical ยังไม่ได้เปิดเส้นทางการอัปเกรดนี้

แฟล็กจะเปลี่ยนเป็น 1 เมื่อมีการปล่อย point release แรกออกมา Ubuntu 26.04.1 มีกำหนดการในวันที่ 27 สิงหาคม 2026 แต่เนื่องจากกำหนดการอาจมีการเปลี่ยนแปลง คุณควรตรวจสอบจาก metadata แทนการดูปฏิทิน ความล่าช้านี้เป็นความตั้งใจของทีมพัฒนา เพื่อให้ผู้ที่อัปเกรดก่อนได้ช่วยกันค้นหาปัญหาที่ขัดขวางการทำงาน (blockers) และแก้ไขให้เรียบร้อยก่อนที่กลุ่มผู้ใช้งานเซิร์ฟเวอร์ LTS จำนวนมากจะดำเนินการตาม

ดังนั้นจึงมีทางเลือกที่เหมาะสมสองทาง ทางเลือกแรกคือรอจนกว่าจะถึง point release ซึ่งเป็นสิ่งที่แนะนำสำหรับเซิร์ฟเวอร์ที่คุณไม่ต้องการเฝ้าระวังปัญหาด้วยตนเอง ทางเลือกที่สองคือการตั้งค่า Prompt=normal ให้ชี้ไปยัง meta-release ซึ่งเป็นที่ที่ 26.04 ถูกระบุว่ารองรับการใช้งานแล้ว วิธีที่สองนี้จะอัปเกรดคุณไปยัง 26.04 เวอร์ชันที่ปล่อยออกมาจริง ไม่ใช่เวอร์ชันพัฒนา จึงถือว่ายอมรับได้หากคุณใช้งานบนเครื่องที่สามารถกู้คืนจาก snapshot ได้ อย่าลืมตั้งค่ากลับเป็น lts เมื่อดำเนินการเสร็จสิ้น สำหรับขั้นตอนการปฏิบัติงานโดยละเอียด สามารถดูได้ที่ คู่มือการอัปเกรดเซิร์ฟเวอร์จาก 24.04 ไปยัง 26.04 ฉบับสมบูรณ์

คลังซอฟต์แวร์ภายนอกและ PPA ที่ขัดขวางการอัปเกรด

เครื่องมืออัปเกรดจะเขียนไฟล์แหล่งที่มา APT ของคุณใหม่เพื่อให้ชี้ไปยังรุ่นใหม่ เครื่องมือจะทำเช่นนั้นได้ก็ต่อเมื่อคลังซอฟต์แวร์นั้นมีการเผยแพร่สำหรับรุ่นใหม่เท่านั้น ดังนั้นแหล่งที่มาอื่นทั้งหมดจะถูกใส่เครื่องหมายคอมเมนต์ไว้ เหตุผลจะถูกแสดงบรรทัดละหนึ่งรายการและมีความเฉพาะเจาะจง ได้แก่ was disabled (unknown mirror), was disabled (unknown dist) และ was disabled (no Release file)

PPA (personal package archive) ที่สร้างขึ้นสำหรับ noble จะไม่มีไดเรกทอรีสำหรับ resolute บนเซิร์ฟเวอร์ ดังนั้นเครื่องมืออัปเกรดจึงไม่สามารถดึงไฟล์ Release สำหรับรุ่นใหม่มาได้และจะปิดการใช้งานรายการนั้น โดยปกติแล้วนี่เป็นคำเตือนที่คุณสามารถยอมรับได้ แต่จะกลายเป็นจุดที่ต้องหยุดดำเนินการเมื่อคลังซอฟต์แวร์ภายนอกจัดหาแพ็กเกจที่รุ่นใหม่มีอยู่แล้วเช่นกัน เพราะการคำนวณการอัปเกรดจะมีตัวเลือกสองทางและไม่มีวิธีตอบสนองความต้องการของทั้งสองแหล่งได้

คุณควรตัดสินใจเรื่องนี้ด้วยตนเองก่อนเริ่มดำเนินการ แทนที่จะปล่อยให้เครื่องมือตัดสินใจระหว่างการทำงานที่ไม่มีผู้ดูแลเป็นเวลานาน

ls /etc/apt/sources.list.d/
apt policy nginx
sudo add-apt-repository --remove ppa:example/ppa

apt policy ตามด้วยชื่อแพ็กเกจจะแสดงว่าแพ็กเกจเวอร์ชันที่ติดตั้งอยู่นั้นมาจากคลังซอฟต์แวร์ใด เพื่อให้คุณเห็นชัดเจนว่ามีแพ็กเกจใดบ้างที่ขึ้นอยู่กับแหล่งที่มาที่คุณกำลังจะปิดการใช้งาน การลบแหล่งที่มาออกไม่ได้เป็นการดาวน์เกรดซอฟต์แวร์ ดังนั้นแพ็กเกจที่ติดตั้งจาก PPA จะยังคงเป็นเวอร์ชันเดิมจาก PPA และอาจใหม่กว่าเวอร์ชันที่มีในรุ่นใหม่ ในกรณีที่เรื่องนี้มีความสำคัญ ให้ลบแพ็กเกจนั้นออกด้วย แล้วติดตั้งใหม่จากคลังซอฟต์แวร์หลักหลังจากอัปเกรดเสร็จสิ้น คลังซอฟต์แวร์ที่คุณวางแผนจะนำกลับมาใช้ใหม่ เช่น Tailscale จำเป็นต้องได้รับการอัปเดต codename ให้เป็นรุ่นใหม่ก่อนที่แพ็กเกจจะติดตั้งได้อีกครั้ง ซึ่งเป็นที่มาของ ข้อผิดพลาดส่วนใหญ่ในการติดตั้ง Tailscale บน Ubuntu

มีแฟล็กสำหรับทางเลือกที่ตรงกันข้าม หน้าคู่มืออธิบาย --allow-third-party ไว้ว่า "ลองอัปเกรดโดยเปิดใช้งาน mirror และคลังซอฟต์แวร์ภายนอกแทนที่จะใส่เครื่องหมายคอมเมนต์ไว้" ให้ใช้แฟล็กนี้เฉพาะเมื่อคุณยืนยันแล้วว่าคลังซอฟต์แวร์นั้นมีการเผยแพร่สำหรับรุ่นเป้าหมายแล้วเท่านั้น หากยังไม่มี คุณกำลังสั่งให้ APT แก้ไขกราฟ dependency เทียบกับชุดซอฟต์แวร์ที่คลังนั้นไม่เคยสร้างขึ้นมา

บน Ubuntu 24.04 เป็นต้นไป แหล่งที่มาส่วนใหญ่อยู่ใน /etc/apt/sources.list.d/ubuntu.sources ในรูปแบบ deb822 การเขียนคลังซอฟต์แวร์เดียวกันในรูปแบบเก่าและใหม่พร้อมกันถือเป็นข้อผิดพลาดแยกต่างหากที่มีข้อความแจ้งเตือนเฉพาะ ซึ่งครอบคลุมอยู่ใน ข้อผิดพลาดรายการแหล่งที่มาซ้ำในรูปแบบ deb822

แพ็กเกจที่ถูกระงับ (held) และตั้งค่าไม่สมบูรณ์ทำให้การคำนวณหยุดชะงัก

การอัปเกรดรุ่น (release upgrade) จำเป็นต้องย้ายแพ็กเกจเกือบทุกตัวในระบบ หากแพ็กเกจใดแพ็กเกจหนึ่งไม่สามารถย้ายได้ การคำนวณจะล้มเหลว และตัวอัปเกรดจะเลือกหยุดทำงานตั้งแต่เนิ่นๆ แทนที่จะปล่อยให้ระบบของคุณอยู่ในสถานะกึ่งสำเร็จ คุณสามารถใช้คำสั่งสองคำสั่งเพื่อหาสาเหตุได้

apt-mark showhold
sudo dpkg --audit

apt-mark showhold จะแสดงรายการแพ็กเกจที่ถูกระงับโดยแสดงทีละบรรทัด และจะไม่แสดงผลใดๆ หากระบบอยู่ในสถานะปกติ การระงับ (hold) คือคำสั่งที่กำหนดไว้ด้วยตนเองเพื่อไม่ให้มีการเปลี่ยนแปลงแพ็กเกจนั้นๆ อาจมีใครบางคนเคยล็อกเวอร์ชันของ kernel หรือฐานข้อมูลไว้แล้วลืมไป ให้ปลดล็อกแพ็กเกจที่คุณไม่ต้องการระงับอีกต่อไปด้วยคำสั่ง sudo apt-mark unhold ตามด้วยชื่อแพ็กเกจ

dpkg --audit จะแสดงรายการแพ็กเกจที่ถูกแตกไฟล์ออกมาแล้วแต่ยังไม่ได้ตั้งค่า สถานะนี้เกิดจากการติดตั้งที่ถูกขัดจังหวะ ซึ่งส่วนใหญ่มักเกิดจากเซสชันที่หลุดไป ตัวอัปเกรดจะพยายามซ่อมแซมและแสดงข้อความ dpkg interrupted, calling dpkg --configure -a แต่การซ่อมแซมด้วยตนเองก่อนจะช่วยให้คุณอ่านข้อความผิดพลาดได้ชัดเจนแทนที่จะปล่อยให้มันเลื่อนผ่านไป แพ็กเกจที่เครื่องมือไม่สามารถซ่อมแซมได้จะแสดงข้อความ Package in inconsistent state ซึ่งคุณจำเป็นต้องจัดการก่อนที่จะลองใหม่อีกครั้ง

โปรดทำให้รุ่นที่ใช้งานอยู่เป็นปัจจุบันอย่างสมบูรณ์ก่อนที่จะทำการอัปเกรด

sudo apt update
sudo apt full-upgrade -o APT::Get::Always-Include-Phased-Updates=true
sudo apt --fix-broken install
sudo dpkg --configure -a
sudo reboot

ตัวเลือกการอัปเดตแบบแบ่งระยะ (phased updates) มีความสำคัญมากกว่าที่เห็น Ubuntu จะทยอยปล่อยอัปเดตบางรายการไปยังเครื่องของผู้ใช้ทีละเปอร์เซ็นต์ ดังนั้นคำสั่ง apt upgrade แบบปกติอาจทำให้แพ็กเกจบางตัวยังคงเป็นเวอร์ชันเก่า และเซิร์ฟเวอร์ของคุณจะไม่อัปเดตเท่าที่คุณเข้าใจ ตัวเลือกดังกล่าวจะดึงอัปเดตทั้งหมดมาให้ หากมีการอัปเดต kernel ให้รีบูตเครื่องหลังจากนั้น เพื่อให้คุณทำการอัปเกรดจาก kernel ที่กำลังใช้งานอยู่จริง เครื่องที่ตั้งค่าให้แพตช์ตัวเองผ่าน การอัปเดตความปลอดภัยอัตโนมัติ จะมีงานที่ต้องทำในขั้นตอนนี้ลดลง แม้ว่ากลไกดังกล่าวจะถูกออกแบบมาไม่ให้ข้ามขอบเขตของรุ่น (release boundary) ก็ตาม

เมื่อรุ่นของซอฟต์แวร์สิ้นสุดระยะเวลาสนับสนุนมาตรฐาน

Ubuntu รุ่น interim จะได้รับการสนับสนุนเป็นเวลาเก้าเดือน เมื่อสิ้นสุดระยะเวลาดังกล่าว ค่าสถานะ Supported: จะเปลี่ยนเป็น 0 และช่องทางปกติจะไม่เสนอการอัปเกรดจากรุ่นนั้นอีกต่อไป จากการตรวจสอบเมื่อวันที่ 13 สิงหาคม 2026 meta-release ได้ระบุเกี่ยวกับ 25.10 ไว้ดังนี้:

Dist: questing
Name: Questing Quokka
Version: 25.10
Date: Thu, 09 October 2025 00:25:10 UTC
Supported: 0

ในเวลาเดียวกัน คลังเก็บซอฟต์แวร์ (archive) จะย้ายตำแหน่ง แพ็กเกจสำหรับรุ่นที่สิ้นสุดอายุการใช้งาน (end of life) จะถูกนำออกจาก archive.ubuntu.com และย้ายไปเก็บไว้ที่ old-releases.ubuntu.com ส่งผลให้ apt update เริ่มส่งค่ากลับเป็น 404 Not Found ระบบจะไม่สามารถอัปเดตให้เป็นปัจจุบันได้อีกต่อไป และเนื่องจากตัวอัปเกรดกำหนดให้ระบบต้องเป็นเวอร์ชันปัจจุบันเท่านั้น กระบวนการจึงไม่สามารถดำเนินการต่อได้ คุณต้องแก้ไขแหล่งที่มา (sources) ก่อน

lsb_release -cs
grep -rn ubuntu.com /etc/apt/sources.list /etc/apt/sources.list.d/

เปลี่ยนเส้นทางทั้ง archive.ubuntu.com และ security.ubuntu.com ไปยัง old-releases.ubuntu.com โดยคงชื่อรหัส (codename) เดิมของคุณไว้ เปลี่ยนเฉพาะชื่อโฮสต์เท่านั้น

sudo sed -i.bak -e 's/archive.ubuntu.com/old-releases.ubuntu.com/g' \
                -e 's/security.ubuntu.com/old-releases.ubuntu.com/g' \
                /etc/apt/sources.list.d/ubuntu.sources
sudo apt update

ให้รันคำสั่งเดียวกันกับ /etc/apt/sources.list แทน หากเซิร์ฟเวอร์ของคุณยังคงเก็บแหล่งที่มาไว้ในไฟล์เดียว ตัวเลือก -i.bak จะสร้างไฟล์สำรองไว้ข้างไฟล์ต้นฉบับ เพื่อให้คุณสามารถกู้คืนได้หากการแก้ไขนั้นทำกับไฟล์ผิด การรัน apt update หลังจากนั้นจะทำให้คลังเก็บซอฟต์แวร์กลับมาเข้าถึงได้อีกครั้ง และ do-release-upgrade จะสามารถติดต่อสื่อสารกับคุณได้

โปรดพิจารณาความเป็นจริงว่าวิธีนี้จะช่วยคุณได้มากน้อยเพียงใด Ubuntu รองรับการอัปเกรดทีละหนึ่งรุ่นเท่านั้น ดังนั้นเซิร์ฟเวอร์ที่ล้าหลังไปสองหรือสามรุ่นจำเป็นต้องทำตามขั้นตอนทีละขั้น และแต่ละขั้นตอนอาจล้มเหลวได้จาก repository ของบุคคลที่สามหรือแพ็กเกจที่ถูกล็อกไว้ (held package) บน VPS การสร้างเซิร์ฟเวอร์ใหม่บนรุ่น LTS ปัจจุบันแล้วย้ายบริการไปไว้ที่นั่น และเก็บเซิร์ฟเวอร์เก่าไว้จนกว่าจะมั่นใจ มักจะเป็นวิธีที่เร็วกว่า วิธีนี้ยังช่วยให้คุณมีจุดย้อนกลับ (rollback) ซึ่งการอัปเกรดแบบ in-place ไม่มีให้ หากคุณกำลังตัดสินใจว่าจะเลือกใช้รุ่นใดในอนาคต ความแตกต่างระหว่าง LTS และรุ่น interim บนเซิร์ฟเวอร์ เป็นสิ่งที่ควรอ่านก่อนตัดสินใจ

สิ่งที่แฟล็ก development release ทำงานจริง

-d หรือ --devel-release จะทำให้ตัวอัปเกรดอ่านค่าจาก meta-release-development แทนไฟล์ที่ Prompt เลือกไว้ หน้าคู่มืออธิบายไว้ว่า "หากใช้รุ่นที่รองรับล่าสุดอยู่ ให้ทำการอัปเกรดไปยังรุ่นพัฒนา (development release)"

จากการตรวจสอบเมื่อวันที่ 13 สิงหาคม 2026 รายการล่าสุดในไฟล์นั้นไม่ใช่ 26.04:

Dist: stonking
Name: Stonking Stingray
Version: 26.10
Date: Thu, 15 October 2026 00:26:10 UTC
Supported: 0

ดังนั้น -d จึงไม่ได้นำเซิร์ฟเวอร์ 24.04 ไปสู่รุ่น 26.04 ที่ปล่อยออกมาแล้ว แต่เป้าหมายคือ 26.10 ซึ่งเป็นรุ่นที่ยังอยู่ในระหว่างการพัฒนา คำแนะนำเก่าที่บอกว่า "แค่เพิ่ม -d" นั้นเขียนขึ้นในช่วงเวลาก่อนที่รุ่น LTS จะปล่อยออกมา การนำมาใช้ซ้ำในตอนนี้จะทำให้เซิร์ฟเวอร์ของคุณชี้ไปยังจุดที่คุณไม่ได้ตั้งใจ หากยังคงมี Prompt=lts อยู่ แฟล็กนี้จะหยุดทำงานพร้อมแสดงข้อความของตัวเอง:

There is no development version of an LTS available.

เอกสารประกอบของ Ubuntu server ระบุถึงแฟล็กนี้ไว้อย่างชัดเจนว่า "การใช้รุ่นพัฒนา (หรือแฟล็ก -d) ไม่แนะนำสำหรับสภาพแวดล้อมการใช้งานจริง (production)" รุ่นพัฒนามีการเปลี่ยนแปลงทุกวันและไม่มีการรับประกันด้านความปลอดภัย ดังนั้นแพ็กเกจที่ใช้งานได้ในช่วงเช้าอาจทำให้บริการหยุดชะงักในช่วงบ่ายได้ ให้ใช้แฟล็กนี้เฉพาะกับ virtual machine สำหรับทดสอบที่คุณสร้างขึ้นเพื่อตรวจสอบการตั้งค่าของคุณเท่านั้น ห้ามใช้กับเซิร์ฟเวอร์ที่มีผู้ใช้งานจริง หากคุณต้องการรุ่น 26.04 ที่ปล่อยออกมาแล้วก่อนที่ประตู LTS จะเปิด Prompt=normal คือแนวทางที่ถูกต้อง

ดำเนินการอัปเกรดโดยไม่ให้การเชื่อมต่อ SSH ที่หลุดส่งผลกระทบ

การอัปเกรดรุ่นของระบบปฏิบัติการจะแทนที่ส่วนประกอบส่วนใหญ่ของระบบ รวมถึง openssh-server และ systemd หากเซสชัน SSH (secure shell) ของคุณหลุดในขณะที่ openssh-server กำลังทำงาน กระบวนการจะถูกยุติลงในสถานะที่แพ็กเกจถูกแตกไฟล์แต่ยังไม่ได้ตั้งค่า ซึ่งเป็นสถานะที่ทำให้การพยายามอัปเกรดครั้งถัดไปล้มเหลว ดังนั้นควรเริ่มการอัปเกรดภายใน terminal multiplexer ทุกครั้ง

sudo apt install -y tmux
tmux new -s upgrade
sudo do-release-upgrade

หากการเชื่อมต่อหลุด ให้ล็อกอินกลับเข้ามาใหม่แล้วรัน tmux attach -t upgrade การอัปเกรดจะยังคงทำงานต่อไปเนื่องจากเป็นกระบวนการลูกของเซิร์ฟเวอร์ tmux ไม่ใช่ของเซสชัน SSH ของคุณ ทั้ง screen -S upgrade และ screen -r upgrade สามารถทำหน้าที่นี้ได้เช่นกันหากคุณต้องการใช้งาน

ตัวอัปเกรดมีกลไกป้องกันสำหรับผู้ที่ไม่ได้ใช้ multiplexer เมื่อระบบตรวจพบว่ากำลังทำงานผ่าน SSH ระบบจะเสนอให้เริ่ม sshd ตัวที่สองบนพอร์ต 1022 เพื่อให้คุณยังมีช่องทางเข้าถึงระบบได้หากเซสชันหลักหลุด ระบบจะตัดสินใจโดยการตรวจสอบกระบวนการแม่ (parent process) ว่ามีกระบวนการที่ชื่อ sshd หรือไม่ หากคุณใช้งานภายใน tmux หรือ screen ระบบจะพบเซิร์ฟเวอร์ของ multiplexer แทน ข้อเสนอดังกล่าวจึงไม่ปรากฏขึ้น และไฟล์ pid /var/run/release-upgrader-sshd.pid จะถูกเขียนขึ้นก็ต่อเมื่อมีการเริ่ม daemon สำรองจริงเท่านั้น การที่คุณไม่เห็นข้อความแจ้งเตือนไม่ได้หมายความว่ามีข้อผิดพลาดเกิดขึ้น แต่หมายความว่าคุณมีกลไกป้องกันที่ดีกว่าอยู่แล้ว

หากคุณยอมรับข้อเสนอดังกล่าว ระบบจะไม่เปิดพอร์ตให้คุณโดยอัตโนมัติ เครื่องมือจะแจ้งให้คุณทราบอย่างชัดเจน เนื่องจากการเปิดพอร์ตเป็นการตัดสินใจด้านความปลอดภัยที่เครื่องมือไม่มีสิทธิ์ดำเนินการแทนคุณ ให้คุณเปิดพอร์ตไว้เฉพาะช่วงเวลาที่อัปเกรดเท่านั้น แล้วปิดพอร์ตหลังจากเสร็จสิ้น

sudo ufw allow 1022/tcp
sudo ufw delete allow 1022/tcp

ผู้ให้บริการ VPS ส่วนใหญ่จะมีไฟร์วอลล์ชั้นที่สองในแผงควบคุม ซึ่งอยู่นอกเหนือการควบคุมของระบบปฏิบัติการ คุณต้องเปิดพอร์ต 1022 ในส่วนนั้นด้วย มิฉะนั้นตัวรับฟังสำรองจะทำงานแต่ไม่สามารถเข้าถึงได้ ซึ่งถือเป็นสถานการณ์ที่แย่ที่สุด

ควรเตรียมความพร้อม 4 ประการก่อนพิมพ์คำสั่งอัปเกรด:

• ทำ snapshot หรือสำรองข้อมูลทั้งหมด การอัปเกรดรุ่นของระบบแบบ in-place ไม่สามารถย้อนกลับได้ และนี่คือโอกาสเดียวที่คุณมี
• ตรวจสอบให้แน่ใจว่าคุณสามารถเข้าถึงคอนโซลของผู้ให้บริการได้ก่อนที่จะจำเป็นต้องใช้ หากเซิร์ฟเวอร์ไม่กลับมาทำงานหลังจากการรีบูต SSH จะเป็นสิ่งแรกที่คุณไม่สามารถใช้งานได้ ส่วนกรณีที่เคอร์เนลไม่สามารถบูตได้นั้นเป็นปัญหาแยกต่างหากซึ่งมีขั้นตอนการกู้คืนเฉพาะ โดยครอบคลุมอยู่ใน VPS ที่ไม่สามารถบูตได้หลังการอัปเดตเคอร์เนล
• ตรวจสอบพื้นที่ว่างด้วย df -h / /boot การอัปเกรดต้องดาวน์โหลดแพ็กเกจจำนวนมาก และพาร์ทิชัน /boot ที่มีเคอร์เนลเก่าสะสมอยู่หลายเวอร์ชันมักเป็นสาเหตุที่ทำให้การอัปเกรดหยุดชะงัก
• อ่านบันทึกประจำรุ่น (release notes) ของบริการที่คุณใช้งานอยู่ การอัปเกรดรุ่นใหญ่ของ PostgreSQL หรือ PHP จะมาพร้อมกับการอัปเกรดระบบปฏิบัติการเสมอ ไม่ว่าคุณจะวางแผนไว้หรือไม่ก็ตาม

FAQ

ทำไม do-release-upgrade ถึงแจ้งว่าไม่พบ release ใหม่บน Ubuntu 24.04?

ค่า Prompt=lts เริ่มต้นใน /etc/update-manager/release-upgrades ทำให้เครื่องมืออ่านค่าจาก https://changelogs.ubuntu.com/meta-release-lts และ Ubuntu 26.04 ยังคงระบุค่า Supported: 0 ไว้ในไฟล์นั้นจนกว่าจะถึงการปล่อย point release ครั้งแรก ตัวอัปเกรดจึงไม่พบ LTS release ใหม่ที่ถูกทำเครื่องหมายว่าพร้อมใช้งานและหยุดทำงาน คุณสามารถตรวจสอบไฟล์นี้ได้ด้วยตนเองโดยใช้ curl -s https://changelogs.ubuntu.com/meta-release-lts และอ่านบล็อกสุดท้าย จากการตรวจสอบเมื่อวันที่ 13 สิงหาคม 2026 พบว่า flag ยังคงเป็น 0 โดย Ubuntu 26.04.1 มีกำหนดการปล่อยในวันที่ 27 สิงหาคม 2026

การตั้งค่า Prompt=normal แทนการรอ point release ปลอดภัยหรือไม่?

การตั้งค่านี้จะอัปเกรดคุณไปยัง 26.04 เวอร์ชันที่ปล่อยออกมาจริง ไม่ใช่รุ่นพัฒนา เพราะ Prompt=normal จะอ่านค่าจาก meta-release ซึ่งในนั้น 26.04 มีค่าเป็น Supported: 1 อยู่แล้ว ความเสี่ยงอยู่ที่ช่วงเวลา คุณกำลังอัปเกรดก่อนที่ปัญหาที่พบโดยผู้ใช้งานกลุ่มแรกจะได้รับการแก้ไข ควรทำบนเซิร์ฟเวอร์ที่คุณสามารถกู้คืนจาก snapshot ได้ และสามารถเข้าถึง console ของผู้ให้บริการได้หากการ reboot ล้มเหลว หลังจากนั้นให้ตั้งค่ากลับเป็น lts

การใช้ flag -d จะอัปเกรดเป็น 26.04 หรือไม่?

ไม่ การใช้ -d จะอ่านค่าจาก meta-release-development ซึ่งรายการล่าสุด ณ วันที่ 13 สิงหาคม 2026 คือ Ubuntu 26.10 ซึ่งยังอยู่ในระหว่างการพัฒนา บนเครื่อง LTS ที่ตั้งค่า Prompt=lts ไว้ flag นี้จะแสดงผล There is no development version of an LTS available. แล้วหยุดทำงาน เอกสารของเซิร์ฟเวอร์ Ubuntu ระบุว่าไม่แนะนำให้ใช้รุ่นพัฒนาในสภาพแวดล้อม production ดังนั้นให้ใช้ Prompt=normal หากคุณต้องการอัปเกรดเป็น 26.04 เวอร์ชันสมบูรณ์ก่อนกำหนด

apt update แจ้งข้อผิดพลาด 404 บน release เก่า จะอัปเกรดได้อย่างไร?

release นั้นสิ้นสุดอายุการใช้งานแล้ว แพ็กเกจจึงถูกย้ายจาก archive.ubuntu.com ไปยัง old-releases.ubuntu.com ให้แก้ไขเฉพาะชื่อโฮสต์ใน /etc/apt/sources.list.d/ubuntu.sources หรือใน /etc/apt/sources.list สำหรับโครงสร้างไฟล์แบบเก่า โดยคงชื่อ codename เดิมไว้ จากนั้นรัน sudo apt update และ sudo apt full-upgrade เมื่อระบบเป็นปัจจุบันแล้ว คุณสามารถใช้ do-release-upgrade เพื่อขยับเวอร์ชันขึ้นไปทีละขั้นได้

จำเป็นต้องลบ PPA ออกก่อนรัน do-release-upgrade หรือไม่?

ไม่จำเป็น เพราะตัวอัปเกรดจะใส่เครื่องหมาย comment หน้า source ใดก็ตามที่ไม่มีการเผยแพร่สำหรับ release ใหม่ และจะแสดงบรรทัดข้อความเช่น was disabled (no Release file) สำหรับแต่ละรายการ การลบออกด้วยตนเองก่อนนั้นดีกว่า เพราะคุณสามารถเลือกลำดับและเห็นผลลัพธ์ได้ชัดเจน ให้รัน apt policy บนแพ็กเกจที่คุณต้องการเพื่อตรวจสอบว่าแพ็กเกจใดมาจาก PPA ใดบ้าง จากนั้นให้ติดตั้งแพ็กเกจเหล่านั้นใหม่จาก archive หากเวอร์ชันใน PPA ใหม่กว่าเวอร์ชันที่มีใน release ใหม่