วิธีอัปเกรด Ubuntu 24.04 เป็น 26.04 บน VPS อย่างปลอดภัย

คุณจะอัปเกรด Ubuntu 24.04 เป็น 26.04 ได้เมื่อใด

คุณสามารถอัปเกรด Ubuntu 24.04 เป็น 26.04 บน VPS ได้เมื่อมีการปล่อย point release รุ่น 26.04.1 ซึ่งมีกำหนดการในวันที่ 27 สิงหาคม 2026 จนกว่าจะถึงเวลานั้น เซิร์ฟเวอร์ที่ใช้ 24.04 จะไม่พบรุ่นใหม่ดังกล่าวโดยเจตนา Ubuntu 26.04 LTS (Resolute Raccoon) ได้รับการปล่อยออกมาเมื่อวันที่ 23 เมษายน 2026 แต่ Canonical จะเปิดเส้นทางการอัปเกรดจาก LTS ไปยัง LTS ก็ต่อเมื่อถึง point release แรกเท่านั้น เนื่องจากรุ่นดังกล่าวได้รวมการแก้ไขบั๊กจากการติดตั้งและการอัปเกรดที่พบในช่วงเดือนแรกๆ ไว้แล้ว หากคุณยังไม่คุ้นเคยกับระบบเลขรุ่น 26.04.1 ไม่ใช่ Ubuntu รุ่นอื่น แต่เป็น 26.04 รุ่นเดิมที่รวมการแก้ไขตลอดสี่เดือนไว้ในสื่อติดตั้ง ซึ่งเป็นเหตุผลว่าทำไมจึงเป็นเวอร์ชันแรกที่ Canonical จะส่งให้กับเซิร์ฟเวอร์ที่มีอยู่เดิม

หากคุณเรียกใช้การตรวจสอบบนเครื่อง 24.04 ในช่วงต้นเดือนสิงหาคม 2026 คุณจะได้รับผลลัพธ์ดังนี้:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

นั่นไม่ใช่ข้อผิดพลาดของเซิร์ฟเวอร์ของคุณ /etc/update-manager/release-upgrades มีค่า Prompt=lts บน Ubuntu Server ซึ่งหมายความว่าเครื่องมือนี้จะแสดงเฉพาะรุ่น long term support ถัดไป และจะแสดงเมื่อมี .1 point release ของรุ่นนั้นแล้วเท่านั้น หากตั้งค่าเป็น Prompt=normal เครื่องมือจะนำคุณอัปเกรดผ่าน 24.10, 25.04 และ 25.10 ตามลำดับ ซึ่งเป็นรุ่นระหว่าง LTS ที่สิ้นสุดระยะเวลาการสนับสนุนทั้งหมดแล้ว ให้คงค่าไว้ที่ lts และรอ กำหนดการของ Canonical อาจเปลี่ยนแปลงได้ ดังนั้นให้ตรวจสอบอีกครั้งหากวันดังกล่าวผ่านไปโดยไม่มีการเปลี่ยนแปลง เซิร์ฟเวอร์ที่ยังใช้ 22.04 ไม่สามารถข้ามไปยังรุ่นนี้โดยตรงได้ เพราะเครื่องมืออัปเกรดจะแสดงเฉพาะ LTS ถัดไปเท่านั้น ดังนั้น การอัปเกรด 22.04 เป็น 26.04 ผ่าน 24.04 จึงครอบคลุมการอัปเกรดขั้นแรกและ snapshot ที่ควรสร้างก่อนการอัปเกรดขั้นที่สอง

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

คุณควรทำการอัปเกรดหรือไม่?

Ubuntu 24.04 ได้รับการอัปเดตความปลอดภัยมาตรฐานจนถึงปี 2029 ดังนั้นเซิร์ฟเวอร์ที่ใช้งานจริงและทำงานได้ตามปกติจึงไม่มีกำหนดเวลาที่ต้องรีบเร่ง การอัปเกรดควรทำก็ต่อเมื่อคุณต้องการสิ่งที่มาพร้อมกับเวอร์ชัน 26.04 เช่น PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 หรือ kernel เวอร์ชัน 7.0 การที่ "ตัวเลขเวอร์ชันเพิ่มขึ้น" ไม่ใช่เหตุผลเพียงพอที่จะเข้าไปยุ่งกับเครื่องที่ให้บริการลูกค้าอยู่

ห้ามทำการอัปเกรดแบบ in-place หากเข้าข่ายกรณีใดกรณีหนึ่งต่อไปนี้:

• คุณไม่เคยเปิดคอนโซลของผู้ให้บริการ (VNC หรือ serial) และเข้าสู่ระบบผ่านช่องทางนั้นมาก่อน คอนโซลดังกล่าวเป็นวิธีเดียวที่จะเข้าถึงเครื่องได้หาก SSH มีปัญหา และการพบว่าคอนโซลใช้งานไม่ได้ในขณะที่คุณถูกล็อกเอาต์นั้นถือว่าสายเกินไป
• คุณไม่สามารถยอมรับช่วงเวลาที่ระบบล่ม (downtime) นานหนึ่งชั่วโมงได้ และไม่มีแผนการย้อนกลับ (rollback)
• stack ของคุณขึ้นอยู่กับ repository ของบุคคลที่สามที่ยังไม่ได้เผยแพร่สำหรับ resolute
• เซิร์ฟเวอร์ถูกสร้างขึ้นด้วยมือมานานกว่าสองปีและไม่มีใครทราบว่ามีอะไรติดตั้งอยู่บ้าง

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

ขั้นตอนที่ 1: สำรองข้อมูลที่คุณสามารถกู้คืนได้จริง

ให้ใช้การสำรองข้อมูลสองชั้นเนื่องจากแต่ละวิธีมีจุดอ่อนต่างกัน Snapshot จากผู้ให้บริการครอบคลุมทั้งดิสก์และกู้คืนได้ภายในไม่กี่นาที แต่เนื่องจาก snapshot ถูกสร้างขึ้นในขณะที่ฐานข้อมูลกำลังเขียนข้อมูล จึงเป็นเพียงการสำรองข้อมูลแบบ crash consistent ไม่ใช่ application consistent ส่วนการสำรองข้อมูลระดับไฟล์ด้วย restic ซึ่งจัดเก็บไว้นอกเซิร์ฟเวอร์ จะช่วยให้คุณกู้คืนไฟล์รายไฟล์ได้ และมีสำเนาที่ปลอดภัยแม้บัญชีผู้ใช้ของคุณจะถูกล็อก

ให้ทำการ dump ฐานข้อมูลด้วยตนเองก่อนเสมอ การ dump เป็นวิธีเดียวที่เชื่อถือได้ในการสำรองข้อมูลฐานข้อมูลโดยไม่ต้องหยุดการทำงานของระบบ

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 จะให้ผลลัพธ์การ dump ที่สอดคล้องกันสำหรับตารางแบบ InnoDB เท่านั้น ส่วนตารางแบบ MyISAM จำเป็นต้องหยุดการทำงานของฐานข้อมูลก่อน ไฟล์ tarball /etc คือสิ่งที่คุณจะได้ใช้งานจริงเมื่อเกิดปัญหา เพราะไฟล์นี้เก็บไฟล์ config ทุกไฟล์ที่กระบวนการอัปเกรดอาจสอบถามข้อมูลจากคุณ

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

ขั้นตอนที่ 2: อัปเดตแพตช์ 24.04 ให้สมบูรณ์ก่อน

do-release-upgrade จะปฏิเสธการทำงานบนระบบที่มีสถานะแพ็กเกจเสียหาย และการอัปเดต 24.04 แบบไม่สมบูรณ์จะทำให้การวิเคราะห์ความล้มเหลวในภายหลังทำได้ยากขึ้น

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

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

ให้รีบูตเครื่องหากมีการเปลี่ยนเวอร์ชันของ kernel เพื่อให้มั่นใจว่าคุณกำลังอัปเกรดจากเครื่องที่รันโค้ดเวอร์ชันเดียวกับที่ระบบรับรู้

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

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

df -h / /boot

หากพื้นที่ว่างบน / ต่ำกว่าประมาณ 5 GB มักจะเกิดปัญหาขึ้น และหาก /boot มีพื้นที่ว่างต่ำกว่า 300 MB จะทำให้การติดตั้งล้มเหลวในภายหลังระหว่างการติดตั้ง kernel พร้อมข้อความ No space left on device สาเหตุส่วนใหญ่มักเกิดจาก kernel เวอร์ชันเก่า ซึ่งสามารถลบออกได้ด้วย sudo apt --purge autoremove

อีกหนึ่งสิ่งที่ควรหยุดก่อนเริ่มดำเนินการ: หาก การอัปเดตความปลอดภัยอัตโนมัติ ทำงานระหว่างการอัปเกรด ระบบจะถือครองล็อกของ dpkg ไว้ และตัวอัปเกรดเวอร์ชันจะหยุดทำงานพร้อมข้อความ Could not get lock /var/lib/dpkg/lock-frontend ให้รัน sudo systemctl stop unattended-upgrades ก่อน แล้วจึงเริ่มดำเนินการอีกครั้งเมื่อเสร็จสิ้น

ขั้นตอนที่ 3: ตรวจสอบ repository ของบุคคลที่สามและแพ็กเกจที่ถูกตรึงเวอร์ชัน (pinned packages)

do-release-upgrade จะปิดการใช้งานแหล่งที่มาของ apt ทั้งหมดที่ไม่ใช่ของ Ubuntu เนื่องจากแพ็กเกจที่สร้างมาเพื่อ noble อาจทำให้ระบบ resolute เสียหายได้ เครื่องมือนี้จะเปิดใช้งานแหล่งที่มาที่รู้จักอีกครั้งหลังจากนั้น และปล่อยให้แหล่งที่มาที่เหลือถูกคอมเมนต์ไว้ คุณควรทราบว่าคุณกำลังใช้งานอะไรอยู่ก่อนที่เครื่องมือจะตัดสินใจแทนคุณ

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 ใช้รูปแบบไฟล์สองแบบในไดเรกทอรีดังกล่าว ได้แก่ ไฟล์ .list แบบบรรทัดเดียวแบบเก่า และไฟล์ .sources รูปแบบ deb822 ที่มีฟิลด์ Types: และ Suites: การอัปเกรดจะปิดการใช้งานทั้งสองรูปแบบ ubuntu-security-status --thirdparty จะแสดงรายการแพ็กเกจที่ติดตั้งไว้ซึ่งไม่มีในคลังซอฟต์แวร์ของ Ubuntu ซึ่งเป็นจำนวนที่แท้จริงของสิ่งที่คุณติดตั้งเพิ่มเข้าไป สิ่งใดก็ตามที่อยู่ใน /etc/apt/preferences.d/ คือการตรึงเวอร์ชัน (pin) และการตรึงเวอร์ชันที่เขียนขึ้นสำหรับ noble จะยังคงเลือกแพ็กเกจเวอร์ชันเก่าบนรุ่นใหม่ต่อไป

สำหรับ repository ของบุคคลที่สามแต่ละแห่ง ให้ยืนยันว่าผู้ให้บริการได้เผยแพร่ซอฟต์แวร์สำหรับ codename ใหม่แล้วก่อนที่คุณจะเริ่มดำเนินการ ชุดซอฟต์แวร์ของ Docker จะแสดงอยู่ที่ https://download.docker.com/linux/ubuntu/dists/ และผู้ให้บริการรายอื่นก็เปิดเผยไดเรกทอรีในลักษณะเดียวกัน แหล่งที่มาที่ชี้ไปยังชุดซอฟต์แวร์ที่ไม่มีอยู่จริงจะแสดงข้อผิดพลาดนี้ในการเรียกใช้ apt update ครั้งแรกหลังจากการอัปเกรด:

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

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

ขั้นตอนที่ 4: รันการอัปเกรดใน tmux แทนการใช้ SSH shell ปกติ

หากการเชื่อมต่อของคุณหลุดขณะที่ do-release-upgrade ทำงานอยู่ใน login shell ปกติ กระบวนการดังกล่าวจะได้รับสัญญาณ SIGHUP และหยุดทำงานระหว่างการแตกไฟล์ ส่งผลให้ dpkg อยู่ในสถานะกำหนดค่าไม่สมบูรณ์ และเซิร์ฟเวอร์อาจสูญเสียการเชื่อมต่อเครือข่ายจนไม่สามารถเข้าถึงได้อีก ให้รันคำสั่งภายใน terminal multiplexer แทน เพื่อให้กระบวนการยังคงทำงานอยู่บนเซิร์ฟเวอร์แม้ไคลเอนต์ของคุณจะตัดการเชื่อมต่อ

sudo apt install -y tmux
tmux new -s upgrade

ภายในเซสชันดังกล่าว:

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

ตัวอัปเกรดจะเริ่ม SSH daemon ตัวที่สองบนพอร์ต 1022 ก่อนที่จะทำการเปลี่ยนแปลงใดๆ และจะแจ้งให้คุณทราบ:

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.

ระบบจะไม่เปิด firewall ให้สำหรับพอร์ตดังกล่าวโดยอัตโนมัติ เนื่องจากการเจาะช่องโหว่ firewall โดยไม่ได้รับอนุญาตอาจก่อให้เกิดปัญหาที่ไม่คาดคิด ให้คุณเปิดพอร์ต 1022 ด้วยตนเองก่อนเริ่มดำเนินการ และปิดพอร์ตดังกล่าวเมื่อเสร็จสิ้นด้วย sudo ufw delete allow 1022/tcp โปรดจำไว้ว่าผู้ให้บริการของคุณอาจมี firewall อีกชั้นหนึ่งในแผงควบคุม ซึ่งอยู่นอกเหนือการจัดการบนตัวเซิร์ฟเวอร์

หากการเชื่อมต่อหลุดอยู่ดี ให้เข้าสู่ระบบอีกครั้งแล้วเรียกใช้ tmux attach -t upgrade การอัปเกรดยังคงทำงานต่อระหว่างที่คุณไม่อยู่ หากไม่เป็นเช่นนั้น และเมื่อกลับมาพบว่า dpkg หรือ apt sources อยู่ในสถานะกำหนดค่าไม่สมบูรณ์ โดยมีทั้งส่วนของ noble และส่วนของ resolute หัวข้อ การกู้คืนจาก release upgrade ที่ล้มเหลว จะอธิบายวิธีซ่อมแซมสถานะแพ็กเกจ รวมถึงวิธีพิจารณาว่าควรหยุดซ่อมแซมเมื่อใดและกู้คืน snapshot แทน

ขั้นตอนที่ 5: ตอบคำถามเกี่ยวกับไฟล์คอนฟิกูเรชันอย่างรอบคอบ

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

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

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

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

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

ไฟล์แต่ละรายการที่แสดงคือเวอร์ชันของผู้ดูแลแพ็กเกจ ซึ่งถูกบันทึกไว้ข้างๆ ไฟล์ของคุณ ให้เปรียบเทียบความแตกต่าง (diff) ทีละไฟล์แล้วคัดลอกเฉพาะการตั้งค่าที่จำเป็นมาใช้ มีไฟล์ 2 ประเภทที่ต้องระมัดระวังเป็นพิเศษ ได้แก่ /etc/ssh/sshd_config เพราะหากตอบผิดจะทำให้เซสชันของคุณหลุดทันที และไฟล์คอนฟิกูเรชันของเว็บเซิร์ฟเวอร์ เพราะหากตอบผิดจะทำให้เว็บไซต์หยุดทำงาน

ในระหว่างการอัปเกรด ระบบจะถามว่าจะให้รีสตาร์ทบริการใดบ้างผ่าน needrestart ให้ยอมรับรายการทั้งหมดที่ระบบเสนอมา เพราะหาก daemon ยังคงทำงานโดยอ้างอิงกับไฟล์ shared library ที่ถูกลบออกจากดิสก์ไปแล้ว บริการนั้นอาจเกิดข้อผิดพลาด (crash) ในภายหลังเมื่อมีการเรียกใช้งาน ในช่วงเวลาที่คุณไม่ได้เฝ้าดูระบบอยู่

ขั้นตอนที่ 6: รีบูตและตรวจสอบเครื่อง

sudo reboot

เมื่อระบบกลับมาทำงาน:

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 ควรรายงานค่าเป็น Release: 26.04 และ Codename: resolute ส่วน uname -r ควรแสดง kernel เวอร์ชัน 7.0 สำหรับ systemctl --failed ควรแสดงรายการ unit เป็นศูนย์ หากมีรายการใดปรากฏขึ้น นั่นคือสิ่งที่คุณต้องดำเนินการต่อไป และคำสั่ง apt update สุดท้ายจะทำการดึงข้อมูลอัปเดตที่เผยแพร่ออกมาหลังจากที่อิมเมจรุ่นดังกล่าวถูกสร้างขึ้น

การอัปเกรด PostgreSQL 16 ไป 18: คลัสเตอร์ที่ยังคงค้างอยู่โดยไม่รู้ตัว

Ubuntu 24.04 มาพร้อมกับ PostgreSQL 16 และ 26.04 มาพร้อมกับ PostgreSQL 18 การอัปเกรดจะติดตั้งเวอร์ชัน 18 เพิ่มเติมโดยไม่ย้ายข้อมูลของคุณ ชั้นการทำงาน postgresql-common ของ Debian จะสร้างคลัสเตอร์เปล่าใหม่สำหรับเวอร์ชันหลักเวอร์ชันถัดไปบนพอร์ตว่างถัดไป ดังนั้นเวอร์ชัน 16 จะยังคงใช้พอร์ต 5432 พร้อมข้อมูลทั้งหมดของคุณ ส่วนเวอร์ชัน 18 จะว่างเปล่าอยู่ที่พอร์ต 5433 แอปพลิเคชันของคุณจะยังคงสื่อสารกับพอร์ต 5432 ต่อไปและดูเหมือนไม่มีอะไรผิดปกติ ซึ่งเป็นเหตุผลว่าทำไมผู้ใช้หลายคนจึงพบปัญหานี้หลังจากผ่านไปหลายเดือน

pg_lsclusters

หากมีรายการคลัสเตอร์แสดงขึ้นมาสองรายการ หมายความว่าคุณยังไม่ได้ย้ายข้อมูล ให้ดำเนินการเมื่อคุณสามารถหยุดการทำงานของแอปพลิเคชันได้:

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

ให้ลบคลาสเตอร์เวอร์ชัน 18 ที่ว่างเปล่าออกก่อน เนื่องจาก pg_upgradecluster จะไม่เขียนข้อมูลลงในคลัสเตอร์เป้าหมายที่มีอยู่แล้ว วิธีการเริ่มต้นคือการ dump ข้อมูลจากเวอร์ชัน 16 แล้วโหลดเข้าไปในเวอร์ชัน 18 ดังนั้นคุณต้องมีพื้นที่ว่างบนดิสก์ประมาณขนาดของฐานข้อมูล -m upgrade จะใช้ pg_upgrade แทน ซึ่งเร็วกว่ามากสำหรับฐานข้อมูลขนาดใหญ่ เมื่อดำเนินการเสร็จสิ้น ให้ตรวจสอบคอลัมน์ Port: คลัสเตอร์ใหม่จะเข้าใช้งานพอร์ต 5432 แทน และคลัสเตอร์เก่าจะถูกหยุดการทำงานไว้ ให้รันขั้นตอน analyze ด้วยตนเอง เนื่องจากคลัสเตอร์ที่เพิ่งโหลดข้อมูลใหม่จะยังไม่มีสถิติ และการคิวรีครั้งแรกจะทำงานช้า

ทดสอบแอปพลิเคชันกับคลัสเตอร์ใหม่เป็นเวลาสองสามวัน หลังจากนั้นจึงค่อยลบคลัสเตอร์เก่าออก:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

ไดเรกทอรีข้อมูลของคลัสเตอร์เก่าคือวิธี rollback ที่เร็วที่สุดที่คุณมี อย่าลบข้อมูลดังกล่าวในวันที่ทำการอัปเกรด

MySQL 8.0 ถึง 8.4: ตัวเลือกที่ถูกถอดออกซึ่งทำให้เซิร์ฟเวอร์หยุดทำงาน

26.04 มีการเปลี่ยน MySQL จาก 8.0 เป็น 8.4 LTS ซึ่งมีการเปลี่ยนแปลงสองประการที่ส่งผลกระทบต่อเซิร์ฟเวอร์

ประการแรก mysqld จะปฏิเสธการเริ่มทำงานหากไฟล์คอนฟิกูเรชันมีตัวเลือกที่เวอร์ชันใหม่ถอดออกไปแล้ว default_authentication_plugin เป็นตัวเลือกที่พบบ่อย เนื่องจากคู่มือเก่าจำนวนมากแนะนำให้ตั้งค่านี้ บริการจะล้มเหลวและ journalctl -u mysql -n 50 จะระบุชื่อตัวแปรที่ไม่รู้จักให้เห็นโดยตรง ให้ลบบรรทัดนั้นออกจากไฟล์ภายใต้ /etc/mysql/mysql.conf.d/ จากนั้นจึง sudo systemctl start mysql

ประการที่สอง ปลั๊กอิน mysql_native_password ไม่ได้ถูกเปิดใช้งานโดยค่าเริ่มต้นใน 8.4 อีกต่อไป ส่งผลให้บัญชีที่ยังคงใช้งานปลั๊กอินนี้อยู่ไม่สามารถเข้าสู่ระบบได้เลย ให้ตรวจสอบในขณะที่คุณยังคงใช้งาน 8.0 อยู่:

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

ให้ย้ายทุกบัญชีที่แสดง mysql_native_password ก่อนทำการอัปเกรด จากนั้นจึงอัปเดตรหัสผ่านในไฟล์คอนฟิกูเรชันของแอปพลิเคชันของคุณ:

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

หากไลบรารีของไคลเอนต์เก่าเกินกว่าจะรองรับ caching_sha2_password คุณสามารถเปิดใช้งานปลั๊กอินเดิมกลับมาใน 8.4 ได้โดยการเพิ่ม mysql_native_password=ON ไว้ภายใต้ [mysqld] ให้ถือว่าวิธีนี้เป็นเพียงสะพานเชื่อมชั่วคราวที่มีกำหนดเวลาสิ้นสุด เนื่องจากปลั๊กอินดังกล่าวจะถูกถอดออกอย่างถาวรในอนาคต

PHP 8.3 ไปยัง 8.5: vhost ของคุณชี้ไปยัง socket ที่ไม่มีอยู่จริง

Ubuntu 24.04 มาพร้อมกับ PHP 8.3 และ 26.04 มาพร้อมกับ PHP 8.5 แพ็กเกจจะถูกติดตั้งลงใน path ที่ระบุเวอร์ชันไว้ และไม่มีกระบวนการใดแก้ไขค่าคอนฟิกของเว็บเซิร์ฟเวอร์ให้คุณโดยอัตโนมัติ nginx vhost ที่ระบุค่า fastcgi_pass unix:/run/php/php8.3-fpm.sock; ไว้ในขณะนี้จึงชี้ไปยัง socket ที่ไม่มี process ใดสร้างขึ้น ส่งผลให้ทุกคำขอ PHP ตอบกลับเป็น 502 และ log ของ nginx จะแสดงข้อผิดพลาดดังนี้:

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

ให้แก้ไขค่าให้ชี้ไปยัง socket ใหม่ ทดสอบคอนฟิก และ reload บริการ:

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

สำหรับ Apache ที่ใช้ mod_php อาการจะต่างออกไป คือ Apache จะไม่สามารถเริ่มทำงานได้เลย และ sudo apache2ctl -t จะรายงานว่าไม่สามารถโหลด libphp8.3.so ได้เนื่องจากไฟล์ไม่มีอยู่จริง โมดูลที่เปิดใช้งานอยู่เป็นเพียง symlink ไปยังแพ็กเกจที่ถูกลบไปแล้ว

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

หากคุณสร้างเซิร์ฟเวอร์ตามคำแนะนำ a LAMP stack on Ubuntu 24.04 ควรตรวจสอบทั้งสอง path นี้ เนื่องจากคำแนะนำดังกล่าวใช้ชื่อโมดูลและ socket ที่ระบุเวอร์ชันไว้

การปรับแต่งค่าใน php.ini ของคุณจะไม่ถูกย้ายตามไปด้วย ค่า memory_limit, upload_max_filesize และค่าอื่นๆ ที่คุณตั้งไว้จะอยู่ใน /etc/php/8.3/ ซึ่งโครงสร้างใหม่จะเริ่มต้นด้วยค่าเริ่มต้นทั้งหมด ให้ใช้คำสั่ง diff เปรียบเทียบไฟล์ทั้งสองแล้วคัดลอกค่าที่ต้องการด้วยตนเอง การคัดลอกไฟล์เก่าทับไฟล์ใหม่ทั้งหมดจะนำค่าเริ่มต้นของ 8.3 ไปใช้กับเวอร์ชัน 8.5 จากนั้นให้รัน php -m เพื่อเปรียบเทียบ: extension ที่ติดตั้งในชื่อ php8.3-redis จำเป็นต้องมีแพ็กเกจ php8.5- และหากติดตั้งมาจาก PPA ตัวอัปเกรดจะปิดการใช้งานแหล่งที่มานั้นไปแล้ว ทำให้ extension ดังกล่าวหายไป

ใบรับรอง SSL ควรได้รับการตรวจสอบเป็นพิเศษ ให้รัน sudo certbot renew --dry-run หลังจากอัปเกรดเสร็จสิ้น คำสั่งนี้จะจำลองกระบวนการต่ออายุทั้งหมด รวมถึงการสั่ง reload เว็บเซิร์ฟเวอร์ โดยไม่กระทบต่อใบรับรองที่ใช้งานจริง หาก hook ที่เรียกใช้ชื่อบริการหรือ binary มีการเปลี่ยนแปลง มันจะแสดงข้อผิดพลาดให้คุณเห็นทันที แทนที่จะล้มเหลวโดยไม่แจ้งเตือนในอีก 60 วันข้างหน้า Certbot with Let's Encrypt on nginx อธิบายรายละเอียดว่า hook เหล่านี้ควรมีรูปแบบอย่างไร

SSH: ความล้มเหลวที่ทำให้เซสชันที่คุณใช้งานอยู่สิ้นสุดลง

พรอมต์ sshd_config คือจุดที่ผู้ใช้มักล็อกตัวเองออกจากระบบ การตอบ Y จะเป็นการติดตั้งไฟล์ของผู้ดูแลแพ็กเกจ ซึ่งจะลบ PermitRootLogin, PasswordAuthentication, AllowUsers, Port และบรรทัดอื่นๆ ทั้งหมดที่คุณเพิ่มไว้ทิ้ง หากไฟร์วอลล์ของคุณอนุญาตเฉพาะพอร์ตที่กำหนดเอง แต่การตั้งค่าที่มากับแพ็กเกจกำหนดให้ฟังที่พอร์ต 22 การเชื่อมต่อครั้งถัดไปจะถูกปฏิเสธ และเซสชันที่คุณใช้งานอยู่จะเป็นเซสชันสุดท้ายที่คุณมี

ป้องกันปัญหานี้ก่อนที่คุณจะอัปเกรด /etc/ssh/sshd_config บน 24.04 จะเริ่มต้นด้วย Include /etc/ssh/sshd_config.d/*.conf และ OpenSSH จะยึดค่าแรกที่อ่านได้สำหรับแต่ละการตั้งค่า ดังนั้นไฟล์ drop-in ที่รวมไว้ที่ด้านบนสุดจะมีผลเหนือกว่าการตั้งค่าใดๆ ที่อยู่ด้านล่าง ให้ย้ายการตั้งค่าของคุณไปไว้ในไฟล์ที่ dpkg ไม่ได้เป็นเจ้าของ:

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

พอร์ตที่กำหนดเองต้องการการตรวจสอบเพิ่มเติมอีกหนึ่งจุด เพราะมันอาจไม่ได้อยู่ในที่ที่คุณคิด:

systemctl is-enabled ssh.socket

หากคำสั่งดังกล่าวแสดงผล enabled แสดงว่า systemd เป็นผู้ควบคุมพอร์ตที่เปิดฟังอยู่ และบรรทัด Port ใน sshd_config จะถูกละเว้น Ubuntu ใช้ socket activation สำหรับ sshd มาตั้งแต่เวอร์ชัน 22.10 และนี่คือเหตุผลที่การแก้ไข Port 2222 ดูเหมือนจะไม่มีผลใดๆ ให้ตั้งค่าที่ socket unit แทนด้วย sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

การเว้น ListenStream= ให้ว่างเป็นสิ่งจำเป็น เพื่อล้างค่าที่สืบทอดมา หากไม่มีบรรทัดนี้ socket จะฟังทั้งพอร์ต 22 และ 2222 ให้ใช้การตั้งค่าด้วย sudo systemctl daemon-reload && sudo systemctl restart ssh.socket

หลังจากการอัปเกรด ก่อนที่คุณจะปิดเซสชันที่ใช้งานอยู่:

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

จากนั้นเปิดเทอร์มินัลที่สองบนเครื่องของคุณเองแล้วล็อกอินใหม่อีกครั้ง การมีเชลล์ที่ใช้งานได้ในเทอร์มินัลที่สองคือหลักฐานเดียวที่เชื่อถือได้ ให้เปิดเซสชันแรกทิ้งไว้จนกว่าคุณจะทำสำเร็จ การเพิ่มความปลอดภัยให้ SSH บน VPS จะอธิบายถึงการตั้งค่าที่ควรเก็บไว้ในไฟล์ drop-in นั้น

หากสายเกินไปแล้ว คอนโซลบนเว็บของผู้ให้บริการจะช่วยให้คุณล็อกอินได้โดยไม่ต้องผ่าน SSH ให้ล็อกอินผ่านช่องทางนั้น แก้ไขการตั้งค่า รัน sudo sshd -t แล้วรีสตาร์ทบริการ คอนโซลนั้นคือเหตุผลที่คุณควรทดสอบการเข้าถึงผ่านคอนโซลก่อนการอัปเกรด ไม่ใช่ในระหว่างการอัปเกรด

FAQ

ทำไม do-release-upgrade ถึงแจ้งว่า "No new release found" บน Ubuntu 24.04?

เพราะ /etc/update-manager/release-upgrades มีค่าเป็น Prompt=lts บน Ubuntu Server ซึ่งการตั้งค่านี้จะเสนอการอัปเกรดเป็นรุ่น LTS ถัดไปก็ต่อเมื่อมีการปล่อย point release แรกออกมาแล้วเท่านั้น Ubuntu 26.04 LTS ได้ปล่อยออกมาเมื่อวันที่ 23 เมษายน 2026 และ 26.04.1 มีกำหนดการในวันที่ 27 สิงหาคม 2026 จนกว่าจะถึงวันนั้น เซิร์ฟเวอร์ 24.04 จะไม่พบรุ่นใหม่ ให้คงการตั้งค่านี้ไว้แทนที่จะเปลี่ยนเป็น Prompt=normal ซึ่งจะนำคุณไปสู่รุ่น interim แทน

จำเป็นต้องรีบูตเซิร์ฟเวอร์เพื่อให้อัปเกรดเสร็จสมบูรณ์หรือไม่?

จำเป็น การอัปเกรดจะติดตั้ง kernel ใหม่, C library ใหม่ และ init system ใหม่ ซึ่งระบบที่กำลังทำงานอยู่จะยังคงใช้ของเดิมจนกว่าจะรีสตาร์ท do-release-upgrade จะแจ้งให้รีบูตเมื่อเสร็จสิ้น และเครื่องที่เปิดทิ้งไว้จนกว่าจะ "ค่อยรีบูตทีหลัง" คือเครื่องที่กำลังรันซอฟต์แวร์ผสมกันระหว่างสองรุ่น หลังจากเครื่องกลับมาทำงาน ให้ตรวจสอบ uname -r เพื่อดู kernel ใหม่ และ systemctl --failed เพื่อดูว่ามีบริการใดที่ไม่สามารถทำงานต่อได้

ควรเลือกอัปเกรดแบบ in-place หรือสร้างเซิร์ฟเวอร์ 26.04 ใหม่?

หากทำได้ควรสร้างเซิร์ฟเวอร์ใหม่ VPS ใหม่ช่วยให้คุณติดตั้ง stack, กู้คืนข้อมูล และทดสอบทุกอย่างได้ในขณะที่เซิร์ฟเวอร์เดิมยังคงให้บริการอยู่ ทำให้การย้อนกลับทำได้เพียงแค่เปลี่ยน DNS แทนการกู้คืนจาก backup ให้เลือกอัปเกรดแบบ in-place เมื่อเซิร์ฟเวอร์มีสถานะที่ย้ายได้ยาก, เมื่อผู้ให้บริการคิดค่าใช้จ่ายรายเครื่อง หรือเมื่อคุณมี snapshot และสามารถเข้าถึง console ได้จริง เส้นทางการอัปเกรดแบบ in-place นั้นเป็นวิธีมาตรฐาน แต่ก็เป็นทางที่ย้อนกลับไม่ได้ในระหว่างที่กระบวนการกำลังทำงาน

จะเกิดอะไรขึ้นหากการเชื่อมต่อ SSH หลุดระหว่างอัปเกรด?

ใน shell ปกติ กระบวนการจะได้รับสัญญาณ SIGHUP และหยุดทำงานกลางคัน ส่งผลให้ dpkg อยู่ในสถานะกำหนดค่าไม่สมบูรณ์ ให้เริ่มกระบวนการภายใน tmux หรือ screen เพื่อให้กระบวนการยังคงทำงานอยู่แม้การเชื่อมต่อหลุด คุณจึงสามารถเชื่อมต่อกลับเข้ามาและรัน tmux attach -t upgrade เพื่อดำเนินการต่อได้ นอกจากนี้ตัวอัปเกรดจะเริ่ม SSH daemon สำรองที่พอร์ต 1022 ไว้เป็นทางเข้าที่สอง แต่ระบบไม่ได้เปิด firewall สำหรับพอร์ตดังกล่าวให้โดยอัตโนมัติ คุณจึงควรอนุญาตพอร์ต 1022 ด้วยตนเองก่อนเริ่ม และปิดพอร์ตนี้หลังจากเสร็จสิ้น

เว็บไซต์ PHP ของฉันแสดงข้อผิดพลาด 502 หลังอัปเกรด เกิดอะไรขึ้น?

path ของ PHP FPM socket เปลี่ยนไปตามเวอร์ชัน Ubuntu 24.04 ใช้ PHP 8.3 ส่วน 26.04 ใช้ PHP 8.5 ดังนั้น /run/php/php8.3-fpm.sock จึงไม่มีอยู่แล้วในขณะที่ nginx vhost ของคุณยังคงอ้างอิงชื่อเดิมอยู่ log ของ nginx จะแสดงข้อผิดพลาด connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory) ให้แก้ไข fastcgi_pass ให้ชี้ไปยัง socket ของ 8.5, รัน sudo nginx -t แล้ว reload nginx สำหรับ Apache ที่ใช้ mod_php วิธีแก้ไขที่เทียบเท่ากันคือ sudo a2dismod php8.3 ตามด้วย sudo a2enmod php8.5 และรีสตาร์ทบริการ