วิธีแก้ปัญหา do-release-upgrade แจ้งว่าไม่พบรุ่นใหม่

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

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

ให้ตรวจสอบตามลำดับดังกล่าว แต่ละหัวข้อจะมีคำสั่งที่ช่วยยืนยันว่าปัจจัยนั้นส่งผลต่อเซิร์ฟเวอร์ของคุณหรือไม่ เพื่อที่คุณจะได้ไม่ต้องคาดเดาว่าปัญหาเกิดจากสาเหตุใดใน 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 เป็นค่าที่วินิจฉัยปัญหาได้ง่ายที่สุดในบรรดาทั้ง 3 ค่า เนื่องจากเครื่องมือจะระบุทั้งชื่อไฟล์และค่าที่ตั้งไว้ในผลลัพธ์ที่แสดงออกมา:

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 ไฟล์ทั้งสองนี้จะอธิบายรายละเอียดของแต่ละรุ่นไว้ในบล็อกของคีย์ข้อมูล และโปรแกรมอัปเกรดจะเสนอการอัปเกรดให้ก็ต่อเมื่อแฟล็ก 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 ใหม่ที่ถูกทำเครื่องหมายว่าพร้อมใช้งาน ระบบจะแสดงข้อความ No new release found. ซึ่งไม่ได้หมายความว่าเครื่องของคุณมีปัญหาแต่อย่างใด แต่เป็นเพราะ Canonical ยังไม่ได้เปิดเส้นทางการอัปเกรดให้ใช้งาน

flag จะเปลี่ยนเป็น 1 เมื่อ point release แรกออก Ubuntu 26.04.1 มีกำหนดออกในวันที่ 27 August 2026 และกำหนดการออกอาจเปลี่ยนแปลงได้ ดังนั้นให้ตรวจสอบ metadata แทนการอ้างอิงจากปฏิทิน point release ไม่ใช่ Ubuntu เวอร์ชันใหม่ แต่เป็น release เดิมที่รวม update ทั้งหมดตั้งแต่เปิดตัวไว้ในสื่อสำหรับติดตั้งชุดใหม่ ดังนั้น สำหรับเซิร์ฟเวอร์ที่กำลังทำงานอยู่ สิ่งสำคัญคือ gate ที่ release นี้เปิดให้ใช้ ไม่ใช่ตัวสื่อเอง ความล่าช้านี้เกิดขึ้นโดยตั้งใจ ผู้ที่อัปเกรดก่อนจะช่วยค้นหา blocker และแก้ไขปัญหาเหล่านั้นก่อนที่เซิร์ฟเวอร์ LTS จำนวนมากจะอัปเกรดตาม หากวันที่ดังกล่าวผ่านไปแล้วเมื่อคุณอ่านข้อความนี้ สิ่งที่มากับ 26.04.1 และความหมายสำหรับเซิร์ฟเวอร์ 24.04 จะอธิบายต่อจากจุดนั้น

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

Third party repositories และ PPA ที่ขัดขวางการอัปเกรด

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

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

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

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

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

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

บน Ubuntu 24.04 เป็นต้นไป แหล่งที่มาส่วนใหญ่อยู่ใน /etc/apt/sources.list.d/ubuntu.sources ในรูปแบบ deb822 การมี repository เดียวกันที่เขียนในรูปแบบเก่าและรูปแบบใหม่ถือเป็นข้อผิดพลาดแยกต่างหากที่มีข้อความแจ้งเตือนเฉพาะตัว ซึ่งครอบคลุมอยู่ใน ข้อผิดพลาดรายการแหล่งที่มาซ้ำในรูปแบบ 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 จะได้รับการสนับสนุนเป็นเวลา 9 เดือน เมื่อสิ้นสุดระยะเวลาสนับสนุนดังกล่าว แฟล็ก 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 จึงไม่ได้ส่งมอบรุ่น 26.04 ที่ปล่อยออกมาแล้วให้กับเซิร์ฟเวอร์ 24.04 แต่เป้าหมายคือ 26.10 ซึ่งเป็นรุ่นที่ยังอยู่ในระหว่างการพัฒนา คำแนะนำเก่าที่ว่า "แค่เพิ่ม -d" นั้นเขียนขึ้นในช่วงเวลาก่อนที่รุ่น LTS จะปล่อยออกมา การนำคำแนะนำนั้นมาใช้ในตอนนี้จะทำให้เซิร์ฟเวอร์ของคุณชี้ไปยังจุดที่คุณไม่ได้ตั้งใจ หากยังคงมี Prompt=lts อยู่ แฟล็กนี้จะหยุดทำงานพร้อมกับแสดงข้อความแจ้งเตือน:

There is no development version of an LTS available.

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

ดำเนินการอัปเกรดโดยไม่ให้เซสชัน SSH ที่หลุดขัดจังหวะการทำงาน

การอัปเกรดรุ่นจะแทนที่ส่วนใหญ่ของระบบ รวมถึง openssh-server และ systemd หากเซสชัน SSH (secure shell) ของคุณขาดการเชื่อมต่อขณะที่ dpkg กำลังทำงาน โปรเซสจะถูกยุติ โดยมีแพ็กเกจที่ถูกแตกไฟล์แล้วแต่ยังไม่ได้กำหนดค่า ซึ่งเป็นสถานะที่ทำให้ความพยายามครั้งถัดไปหยุดทำงานพอดี หากเกิดเหตุการณ์นี้กับคุณแล้ว การกู้คืนการอัปเกรดที่หยุดกลางคัน เป็นงานแยกต่างหาก และต้องทำก่อนเริ่มความพยายามครั้งที่สอง ให้เริ่มการอัปเกรดภายใน 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 สามารถทำงานในลักษณะเดียวกันได้หากคุณต้องการใช้ screen

ตัวอัปเกรดมีกลไกป้องกันสำหรับผู้ที่ไม่ได้ใช้ 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 ส่วนใหญ่จะมีไฟร์วอลล์ชั้นที่สองในแผงควบคุม (control panel) ซึ่งอยู่นอกเหนือระบบปฏิบัติการ คุณต้องเปิดพอร์ต 1022 ในส่วนนั้นด้วย มิฉะนั้นตัวรับสัญญาณสำรอง (fallback listener) จะทำงานอยู่แต่ไม่สามารถเข้าถึงได้ ซึ่งถือเป็นสถานการณ์ที่แย่ที่สุด

ควรตรวจสอบสิ่งต่อไปนี้ให้เรียบร้อยก่อนพิมพ์คำสั่ง:

• ทำ snapshot หรือสำรองข้อมูลทั้งหมด การอัปเกรดรุ่นแบบ in-place ไม่สามารถย้อนกลับได้ และนี่เป็นโอกาสเดียวที่คุณมี
• ยืนยันว่าคุณสามารถเข้าถึงคอนโซลของผู้ให้บริการได้ก่อนที่จะจำเป็นต้องใช้ หากเซิร์ฟเวอร์ไม่กลับมาทำงานหลังจากการรีบูต SSH จะเป็นสิ่งที่คุณไม่สามารถใช้งานได้ ปัญหา kernel บูตไม่ขึ้นเป็นปัญหาแยกต่างหากที่มีขั้นตอนการกู้คืนเฉพาะ ซึ่งครอบคลุมอยู่ใน VPS ที่บูตไม่ขึ้นหลังการอัปเดต kernel
• ตรวจสอบพื้นที่ว่างด้วย df -h / /boot การอัปเกรดจะดาวน์โหลดแพ็กเกจชุดใหม่ทั้งหมด และพาร์ทิชัน /boot ที่เก็บ kernel เก่าไว้หลายเวอร์ชันมักเป็นจุดที่ทำให้การอัปเกรดหยุดชะงัก
• อ่านบันทึกประจำรุ่น (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 ให้เปลี่ยนเฉพาะชื่อ host ใน /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 หรือไม่?

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