วิธีแก้ไข VPS บูตไม่ขึ้นหลังอัปเดต Kernel

สิ่งที่ควรทำเป็นอันดับแรกเมื่อ VPS ไม่สามารถบูตได้หลังการอัปเดตเคอร์เนล

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

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

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

ฉันจะเข้าถึงคอนโซลได้อย่างไรเมื่อ SSH ใช้งานไม่ได้

ให้เปิดแผงควบคุมของผู้ให้บริการของคุณแล้วมองหาเมนูคอนโซล ชื่อที่พบบ่อยคือ VNC console, web console, noVNC และ serial console หากมีให้เลือกทั้งสองแบบ ให้เลือกใช้ serial console เพราะจะแสดงผลเป็นข้อความที่คุณสามารถเลื่อนดูและคัดลอกได้ ในขณะที่ VNC จะแสดงผลเป็นเพียงภาพหน้าจอเท่านั้น ให้ค้นหาเมนูนี้ตั้งแต่ตอนนี้ในขณะที่เครื่องยังทำงานปกติ และตรวจสอบว่าสามารถเปิดใช้งานได้จริง การมาไล่หาเมนูนี้ในช่วงที่ระบบล่มจะทำให้คุณเสียความใจเย็นที่จำเป็นต้องใช้ในการแก้ไขปัญหา การตรวจสอบนี้ควรทำใน สิบนาทีแรกบน VPS ใหม่ ควบคู่ไปกับการตั้งค่า firewall และ SSH keys

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

โดยปกติคุณจะต้องทำการ hard reset จากแผงควบคุมเพื่อเข้าสู่เมนูบูต เนื่องจากคุณไม่สามารถรันคำสั่ง sudo reboot บนเครื่องที่คุณเข้าสู่ระบบไม่ได้ การทำ hard reset เทียบเท่ากับการตัดกระแสไฟฟ้า ซึ่งจะทำให้ระบบไฟล์ปิดตัวลงอย่างไม่สมบูรณ์ ดังนั้นให้เตรียมใจไว้ว่าระบบอาจต้องตรวจสอบ filesystem ในการบูตครั้งถัดไป

ฉันจะเลือก kernel เวอร์ชันเก่าในเมนู GRUB ได้อย่างไร

ให้เฝ้าดูหน้าจอคอนโซลทันทีที่กดรีเซ็ต กด Esc ซ้ำๆ ในช่วงไม่กี่วินาทีแรก หรือกด Shift ค้างไว้หากเครื่องบูตในโหมด legacy BIOS ช่วงเวลาดังกล่าวสั้นมากและโปรแกรมดูคอนโซลมักใช้เวลาเชื่อมต่อสักครู่ ดังนั้นให้เริ่มกดตั้งแต่เนิ่นๆ และกดต่อไปเรื่อยๆ

เมื่อเมนูแสดงขึ้นมา ให้เลือก "Advanced options for Ubuntu" เมนูย่อยนั้นจะแสดงรายการ kernel ที่ติดตั้งไว้ทั้งหมดโดยเรียงจากเวอร์ชันล่าสุด พร้อมรายการโหมดกู้คืน (recovery mode) สำหรับแต่ละเวอร์ชัน ให้เลือกรายการปกติรายการที่สอง ซึ่งเป็น kernel ที่เก่ากว่าเวอร์ชันล่าสุดหนึ่งลำดับ แล้วกด Enter ส่วนโหมดกู้คืนนั้นเป็นคนละเรื่องกัน โดยจะบูตเข้าสู่ระบบ single user แบบจำกัด ซึ่งมีไว้สำหรับงานซ่อมแซม ไม่ใช่สำหรับการทำให้บริการของคุณกลับมาออนไลน์

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

uname -r
dpkg -l 'linux-image-*' | grep '^ii'

ผลลัพธ์จาก dpkg คือรายการ kernel ที่ติดตั้งไว้ทั้งหมดของคุณ หากมีเพียงบรรทัดเดียวแสดงว่าคุณไม่มี kernel สำรองเลย และนั่นคือสิ่งแรกที่ต้องแก้ไข

เมนู GRUB ไม่ปรากฏขึ้น ต้องทำอย่างไร

Cloud image มักมาพร้อมกับการตั้งค่าที่ซ่อนเมนูไว้ โดยทั่วไป Ubuntu image จะตั้งค่า timeout เป็น 0 ไว้ในไฟล์ที่อยู่ใน /etc/default/grub.d/ ทำให้ kernel ล่าสุดเริ่มทำงานทันทีและไม่มีจังหวะให้กดปุ่มใดๆ

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

แก้ไขทั้งสองกรณีในขณะที่เครื่องยังทำงานปกติ โดยแก้ไขไฟล์ /etc/default/grub:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10
GRUB_RECORDFAIL_TIMEOUT=10
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200"
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0,115200"

จากนั้นนำการตั้งค่าไปใช้และตรวจสอบว่าการแก้ไขของคุณยังคงอยู่ เนื่องจากไฟล์ใน /etc/default/grub.d/ จะถูกอ่านหลังจาก /etc/default/grub และอาจเขียนทับการตั้งค่าของคุณได้

sudo update-grub
grep -rE 'TIMEOUT|TERMINAL' /etc/default/grub /etc/default/grub.d/

GRUB_TERMINAL="console serial" จะส่งเมนูไปยัง graphical console และ serial port เพื่อให้แสดงผลในโปรแกรมดูคอนโซลที่คุณใช้งานผ่านแผงควบคุม ส่วนอาร์กิวเมนต์ console= ของ kernel จะทำหน้าที่เดียวกันกับข้อความการบูตที่ตามมา การหน่วงเวลา 10 วินาทีต่อการบูตเป็นราคาที่คุ้มค่าสำหรับเมนูที่คุณสามารถเข้าถึงได้จริงในช่วงเวลาตี 2

ฉันกำลังเผชิญกับความล้มเหลวประเภทใด?

ให้อ่านข้อความ 20 บรรทัดสุดท้ายก่อนที่คอนโซลจะหยุดนิ่ง โดยทั่วไปแล้วจะมีรูปแบบความล้มเหลว 4 รูปแบบที่มักเกิดขึ้นหลังจากการอัปเดตเคอร์เนล

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

เคอร์เนลเริ่มทำงานแต่ไม่สามารถ mount root ได้ ข้อความจากเคอร์เนลจะเลื่อนผ่านไป จากนั้นคุณจะเข้าสู่ busybox shell ที่มีพรอมต์เป็น (initramfs) หรือการบูตจะจบลงด้วย panic ว่าไม่สามารถ mount root filesystem ได้ ในกรณีนี้เคอร์เนลโหลดสำเร็จแล้ว แต่ initramfs ซึ่งเป็น root ชั่วคราวขนาดเล็กที่ทำหน้าที่ค้นหาและ mount root filesystem จริงของคุณ ไม่สามารถหาดิสก์พบ โดยปกติบน Ubuntu จะมีข้อความแจ้งเตือนก่อนเข้าสู่ shell นี้ว่าระบบยอมแพ้ในการรอ root device พร้อมระบุ UUID ที่ต้องการ ให้คัดลอก UUID นั้นไว้เพื่อนำไปเปรียบเทียบกับผลลัพธ์ของ blkid ในภายหลัง

Logical volume ไม่ปรากฏขึ้น นี่คือความล้มเหลวประเภทเดียวกับข้างต้นแต่มีสาเหตุเฉพาะเจาะจง ที่พรอมต์ (initramfs) ให้รันคำสั่ง ls /dev/mapper หากรายการเดียวที่ปรากฏคือ control แสดงว่าไม่มี LVM (logical volume manager) volume ใดถูกเปิดใช้งาน ทำให้ root device ยังไม่มีตัวตน ให้เปิดใช้งาน volume group ด้วยตนเองดังนี้:

lvm vgchange -ay
ls /dev/mapper
exit

exit จะส่งการควบคุมกลับไปยังสคริปต์ initramfs เพื่อให้ลอง mount ใหม่อีกครั้ง หากระบบบูตได้หลังจากนั้น แสดงว่า initramfs ตัวใหม่ขาดส่วนประกอบของ LVM วิธีแก้ไขคือการสร้างอิมเมจนั้นขึ้นใหม่แทนที่จะไปยุ่งกับเคอร์เนล

ไม่มีข้อความจาก Linux ปรากฏเลย คอนโซลแสดงเพียงข้อความจากเฟิร์มแวร์, UEFI (unified extensible firmware interface) shell, หน้าจอว่างเปล่าโดยไม่มีข้อความจากเคอร์เนล หรือเกิดการรีเซ็ตวนซ้ำ ความล้มเหลวนี้เกิดขึ้นก่อนที่ Linux จะเริ่มทำงาน ให้ตรวจสอบว่าเซิร์ฟเวอร์ของคุณใช้โหมดใดเมื่อกลับมาใช้งานได้ปกติ เนื่องจาก VPS หลายแห่งบูตในโหมด legacy BIOS และไม่ได้ใช้งาน EFI path เลย:

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
mountpoint /boot/efi
sudo efibootmgr -v

การที่ /boot/efi ไม่ได้ถูก mount ระหว่างการอัปเกรดเป็นสาเหตุที่พบบ่อยในเครื่อง UEFI เนื่องจากแพ็กเกจที่ดูแล EFI system partition ได้เขียนข้อมูลลงในไดเรกทอรีว่างธรรมดาแทน เฟิร์มแวร์จึงยังคงพยายามเริ่มทำงานจาก boot entry เดิมจนกว่า entry นั้นจะไม่ตรงกับสิ่งที่อยู่บนดิสก์อีกต่อไป

ยังมีอีกหนึ่งรูปแบบที่ไม่ใช่ความล้มเหลวในการบูต หากคุณเข้าสู่ root shell ที่แจ้งว่าระบบอยู่ใน emergency mode แสดงว่าเคอร์เนลบูตสำเร็จแล้วแต่ userspace หยุดทำงาน ซึ่งมักหมายถึงมีบรรทัดที่ผิดพลาดใน /etc/fstab หรือ filesystem ตรวจสอบไม่ผ่าน ให้รัน journalctl -xb ใน shell นั้นเพื่ออ่านชื่อของ unit ที่ล้มเหลว

แพ็กเกจเคอร์เนลเสียหายหรือ initramfs กันแน่?

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

ls -l /boot/vmlinuz-* /boot/initrd.img-*
df -h /boot

คุณควรมีไฟล์ vmlinuz- หนึ่งไฟล์และ initrd.img- ที่ตรงกันสำหรับทุกเวอร์ชันที่ติดตั้งไว้ โดยแต่ละไฟล์ควรมีขนาดที่สมเหตุสมผล หากไฟล์ initrd หายไป หรือมีขนาดเล็กกว่าไฟล์อื่นอย่างเห็นได้ชัด แสดงว่าการสร้าง initramfs ล้มเหลว สาเหตุทั่วไปคือพื้นที่ใน /boot เต็ม ซึ่งหลักฐานจะปรากฏอยู่ใน log ของแพ็กเกจ:

sudo grep -iE 'no space|update-initramfs' /var/log/apt/term.log
sudo tail -n 40 /var/log/apt/history.log

history.log ยังแสดงรายการแพ็กเกจที่ติดตั้งในการทำงานครั้งล่าสุดและเวลาที่ติดตั้งไว้อย่างละเอียด ซึ่งช่วยยุติข้อสงสัยว่ามีการเปลี่ยนแปลงอะไรไปบ้าง

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

KVER=6.8.0-XX-generic
sudo update-initramfs -c -k "$KVER"
sudo update-grub
ls -l /boot/initrd.img-$KVER

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

sudo apt install --reinstall linux-image-$KVER
sudo dpkg --configure -a

การซ่อมแซมจากโหมดกู้คืนเมื่อไม่สามารถบูต kernel ได้

หากทุกรายการในเมนูบูตล้มเหลว ให้บูตเข้าสู่ rescue image ของผู้ให้บริการและซ่อมแซมดิสก์จากภายนอก ดิสก์ของคุณจะปรากฏเป็นอุปกรณ์ที่ไม่ได้ถูก mount ดังนั้นจะไม่มีกระบวนการใดบนดิสก์ทำงานอยู่และไม่มีสิ่งใดขัดขวางการแก้ไขของคุณได้

sudo lsblk -f
sudo vgchange -ay
sudo mount /dev/ubuntu-vg/ubuntu-lv /mnt
sudo mount /dev/vda2 /mnt/boot
sudo mount /dev/vda1 /mnt/boot/efi

for d in dev proc sys run; do sudo mount --rbind /$d /mnt/$d; done
sudo chroot /mnt /bin/bash

df -h /boot
update-initramfs -u -k all
update-grub
grub-install /dev/vda
exit

ทดสอบ kernel ใหม่โดยไม่เสี่ยงต่อการบูตครั้งถัดไป

GRUB สามารถเริ่มการทำงานของรายการบูตหนึ่งรายการเพียงครั้งเดียว แล้วกลับไปใช้ค่าเริ่มต้นที่คุณเลือกไว้ได้ ให้ตั้งค่าเริ่มต้นเป็น kernel ที่คุณเชื่อถือ จากนั้นจึงสั่งเริ่ม kernel ใหม่สำหรับการบูตเพียงครั้งเดียว หากเกิดความล้มเหลว การทำ hard reset จากแผงควบคุมจะนำคุณกลับไปยัง kernel ที่ใช้งานได้ปกติโดยไม่ต้องกังวลเรื่องการจับเวลาที่หน้าจอ console

ตั้งค่า GRUB_DEFAULT=saved ใน /etc/default/grub, รันคำสั่ง sudo update-grub จากนั้นแสดงรายการชื่อรายการบูตเพื่อให้คุณระบุชื่อได้อย่างถูกต้อง:

grep -E "(menuentry|submenu) " /boot/grub/grub.cfg | cut -d"'" -f2
sudo grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-XX-generic"
sudo grub-editenv list
sudo grub-reboot 0
sudo reboot

grub-editenv list ควรแสดงชื่อที่คุณเลือกออกมาเป็น saved_entry ผลลัพธ์นี้เป็นเครื่องยืนยันว่ากลไกดังกล่าวทำงานได้จริง เนื่องจากการบันทึกค่าจำเป็นต้องใช้ /boot/grub/grubenv ที่เขียนข้อมูลได้ ซึ่งในบางโครงสร้างไฟล์ระบบอาจไม่สามารถเขียนได้โดยไม่มีการแจ้งเตือน รายการที่ 0 คือรายการบนสุดของเมนูซึ่งเป็น kernel ใหม่ล่าสุด การใช้ชื่อรายการมีความปลอดภัยกว่าการใช้ตัวเลขในกรณีนี้ เนื่องจากลำดับตัวเลขจะเปลี่ยนไปทุกครั้งที่มีการติดตั้งหรือลบ kernel ออก

เหตุใดการใช้ autoremove บนเซิร์ฟเวอร์แบบ headless จึงมีความเสี่ยง

APT จะเก็บรายการแพ็กเกจ kernel ที่ห้ามลบโดยอัตโนมัติไว้ คุณสามารถตรวจสอบรายการของคุณได้ดังนี้:

cat /etc/apt/apt.conf.d/01autoremove-kernels
dpkg -l 'linux-image-*' | grep -c '^ii'

ไฟล์ดังกล่าวจะถูกสร้างขึ้นใหม่ทุกครั้งที่มีการเปลี่ยนแปลงแพ็กเกจ kernel เพื่อป้องกันไม่ให้ kernel ที่กำลังใช้งานอยู่และเวอร์ชันล่าสุดถูกลบออก ปัญหาที่สำคัญคือเรื่องของจังหวะเวลา หากคุณรันคำสั่ง sudo apt autoremove --purge ทันทีหลังจากรีบูตเข้าสู่ kernel ใหม่ รายการที่ได้รับการป้องกันจะถูกอัปเดตไปแล้ว ทำให้ kernel เวอร์ชันเก่าที่คุณอาจต้องการใช้งานไม่ได้รับการป้องกันอีกต่อไป สำหรับเครื่องที่มีคีย์บอร์ดต่ออยู่ นี่อาจเป็นเพียงความไม่สะดวก แต่สำหรับเซิร์ฟเวอร์แบบ headless นี่คือความแตกต่างระหว่างการเลือกเมนูบูตกับการต้องเมานต์ดิสก์จาก rescue image เพื่อกู้คืนระบบ

ควรคง kernel ไว้ 2 เวอร์ชันเป็นอย่างน้อย และ 3 เวอร์ชันหาก /boot มีพื้นที่เพียงพอ ให้ลบ kernel เวอร์ชันเก่าออกโดยระบุชื่อหลังจากตรวจสอบด้วย uname -r เพื่อให้มั่นใจว่าคุณจะไม่ลบ kernel ที่กำลังใช้งานอยู่:

uname -r
sudo apt purge linux-image-6.8.0-XX-generic
dpkg -l 'linux-image-*' | grep '^ii'

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

สร้าง snapshot ก่อนเริ่มการอัปเกรด

การสร้าง snapshot ก่อนดำเนินการ apt upgrade เป็นช่องทางการกู้คืนเพียงวิธีเดียวที่ไม่จำเป็นต้องบูตระบบใหม่ การกู้คืน snapshot จะทำให้ดิสก์กลับไปอยู่ในสถานะที่ kernel เวอร์ชันเดิมเป็นค่าเริ่มต้น ซึ่งช่วยให้คุณสามารถลองอัปเกรดใหม่ได้โดยที่หน้าจอ console ยังคงเปิดใช้งานอยู่ snapshot ของเครื่องที่กำลังทำงานอยู่จะเป็นแบบ crash consistent ซึ่งหมายความว่าเป็นการบันทึกสถานะดิสก์เสมือนว่าไฟฟ้าถูกตัด ดังนั้นควรปิดเซิร์ฟเวอร์ก่อนหากผู้ให้บริการของคุณรองรับการทำ offline snapshot ทั้งนี้ snapshot ไม่ใช่การสำรองข้อมูล (backup) เนื่องจากโดยปกติแล้วมันจะถูกเก็บไว้บนโครงสร้างพื้นฐานเดียวกับ volume ที่คัดลอกมา การเข้าใจ ความแตกต่างระหว่าง VPS snapshots กับการสำรองข้อมูลจริง จะเป็นตัวตัดสินว่าวิธีใดจะช่วยคุณได้เมื่อเกิดความล้มเหลวที่รุนแรงกว่าปัญหา kernel

เรื่องนี้มีความสำคัญอย่างยิ่งในการอัปเกรด release ซึ่งมีการเปลี่ยนแปลงทั้ง kernel, เครื่องมือ initramfs, bootloader และการตั้งค่า GRUB ในคราวเดียว ให้สร้าง snapshot ทันทีก่อนที่คุณจะเริ่ม การอัปเกรด Ubuntu 24.04 ไปเป็น 26.04 ไม่ใช่สร้างไว้ตั้งแต่คืนก่อนหน้า เพื่อให้จุดกู้คืนตรงกับสถานะของเครื่องที่คุณกำลังจะเปลี่ยนแปลง หากเซิร์ฟเวอร์ของคุณยังไม่ได้รับการเสนอให้อัปเกรด สาเหตุเกิดจากการจัดตารางเวลาไม่ใช่เพราะการตั้งค่าผิดพลาด เนื่องจากรอบการอัปเกรดจาก LTS ไปยัง LTS จะเปิดให้ใช้งานได้ที่ point release แรก คือ 26.04.1 เท่านั้น

วิธีที่ unattended-upgrades จัดการกับแพ็กเกจ kernel

unattended-upgrades ของ Ubuntu จะติดตั้งอัปเดตความปลอดภัยโดยอัตโนมัติ และแพ็กเกจ kernel ก็จะถูกส่งผ่านช่องทาง security pocket เช่นเดียวกับแพ็กเกจอื่น ซึ่งส่งผลตามมา 2 ประการ

ประการแรก kernel ใหม่จะถูกติดตั้งลงในระบบแต่ยังไม่ได้ทำงาน เนื่องจาก kernel จะมีผลก็ต่อเมื่อทำการบูตเครื่องใหม่เท่านั้น ไฟล์ /var/run/reboot-required จะปรากฏขึ้น และ /var/run/reboot-required.pkgs จะระบุสาเหตุที่ต้องการให้รีบูต แต่จะไม่มีการรีบูตเกิดขึ้นเว้นแต่คุณจะเปิดใช้งาน Unattended-Upgrade::Automatic-Reboot ใน /etc/apt/apt.conf.d/50unattended-upgrades

cat /var/run/reboot-required.pkgs
grep -E 'Automatic-Reboot|Blacklist' /etc/apt/apt.conf.d/50unattended-upgrades

ประการที่สอง ช่องว่างระหว่างการติดตั้งกับการใช้งานนี้ทำให้หาสาเหตุได้ยาก เซิร์ฟเวอร์อาจติดตั้ง kernel ในเดือนมีนาคมและรีบูตในเดือนมิถุนายนด้วยเหตุผลอื่นที่ไม่เกี่ยวข้องกัน แล้วพบว่าไม่สามารถบูตเครื่องได้ การเปลี่ยนแปลงที่ทำให้ระบบบูตไม่ได้นั้นเกิดขึ้นมานานถึง 3 เดือนแล้ว ดังนั้นกิจกรรมที่คุณทำในวันนั้นจึงไม่ใช่สาเหตุของปัญหา คุณสามารถตรวจสอบการทำงานที่ติดตั้ง kernel ซึ่งทำให้เกิดปัญหาในปัจจุบันได้ที่ /var/log/apt/history.log

ควรทำการรีบูตด้วยตนเองในวันที่คุณกำหนด โดยเปิดหน้าต่าง console ทิ้งไว้ นิสัยเพียงอย่างเดียวนี้จะเปลี่ยนเหตุการณ์ระบบล่มที่หาสาเหตุไม่ได้ให้กลายเป็นการแก้ไขปัญหาที่ใช้เวลาเพียง 2 นาที หากคุณต้องการระบบอัตโนมัติโดยไม่ต้องการให้เกิดเหตุการณ์ไม่คาดฝัน ให้เปิดการติดตั้งอัตโนมัติไว้แต่ปิดการรีบูตอัตโนมัติ และดู วิธีการตั้งค่า unattended-upgrades บน Ubuntu สำหรับการตั้งค่าที่ถูกต้อง การระงับแพ็กเกจ kernel ด้วย sudo apt-mark hold linux-image-generic จะหยุดการอัปเดต kernel โดยสิ้นเชิง ซึ่งรวมถึงการแก้ไขช่องโหว่ความปลอดภัยของ kernel ด้วย ดังนั้นให้ถือว่านี่เป็นการแลกเปลี่ยนที่คุณตัดสินใจเลือกเอง ไม่ใช่มาตรการรักษาความปลอดภัย

FAQ

ฉันจะบูต kernel เวอร์ชันเก่าบน VPS ที่ไม่มีคีย์บอร์ดได้อย่างไร

ให้เปิดคอนโซลของผู้ให้บริการ (VNC หรือ serial) แล้วสั่ง hard reset จากแผงควบคุม เนื่องจากคุณไม่สามารถล็อกอินเพื่อสั่งรีบูตตามปกติได้ ในขณะที่เครื่องกำลังเริ่มทำงาน ให้กด Esc ซ้ำๆ หรือกด Shift ค้างไว้หากเป็น BIOS แบบเก่า เพื่อหยุดหน้าจอ GRUB เมนูไว้ จากนั้นเลือก "Advanced options for Ubuntu" และเลือกรายการที่อยู่ถัดจาก kernel เวอร์ชันล่าสุด เมื่อเข้าสู่ระบบได้แล้ว ให้รัน uname -r เพื่อตรวจสอบว่าคุณกำลังใช้งาน kernel เวอร์ชันใดอยู่ และใช้ dpkg -l 'linux-image-*' เพื่อดูว่ามีเวอร์ชันอื่นติดตั้งไว้อีกบ้าง ให้เริ่มวิเคราะห์ปัญหาหลังจากที่ระบบกลับมาทำงานได้อีกครั้งเท่านั้น

ทำไม VPS ของฉันถึงไม่แสดงเมนู GRUB เลย

อิมเมจบนคลาวด์มักตั้งค่า GRUB timeout เป็น 0 ไว้ในไฟล์ภายใต้ /etc/default/grub.d/ ทำให้ kernel เวอร์ชันล่าสุดเริ่มทำงานทันทีโดยไม่มีโอกาสให้กดปุ่มใดๆ ให้ตั้งค่า GRUB_TIMEOUT=10 และ GRUB_TIMEOUT_STYLE=menu ใน /etc/default/grub และเพิ่ม GRUB_TERMINAL="console serial" เพื่อให้เมนูแสดงผลผ่าน serial console ด้วย จากนั้นรัน sudo update-grub ให้ตรวจสอบผลลัพธ์ด้วย grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/ เนื่องจากไฟล์ในไดเรกทอรีดังกล่าวจะถูกอ่านหลังจากไฟล์หลักและอาจเขียนทับการตั้งค่าของคุณได้

ฉันควรลบ kernel เก่าเพื่อเพิ่มพื้นที่ใน /boot หรือไม่

ให้ลบเฉพาะเวอร์ชันที่เก่าที่สุดออกและเก็บไว้อย่างน้อยสองเวอร์ชัน การที่ /boot เต็มถือเป็นความล้มเหลวในตัวเอง เพราะจะทำให้การสร้าง initramfs ล้มเหลว และคุณจะเหลือเพียง kernel ที่ไม่มีอิมเมจสำหรับใช้งาน ให้ลบโดยระบุชื่อแพ็กเกจที่ถูกต้องหลังจากตรวจสอบ uname -r แล้ว เพื่อให้แน่ใจว่า kernel ที่กำลังใช้งานอยู่จะไม่ถูกลบออก หลีกเลี่ยงการใช้ sudo apt autoremove --purge แบบเหมาเข่งบนเครื่องที่ไม่มีหน้าจอ (headless) เนื่องจากรายการ kernel ที่ได้รับการป้องกันจะถูกสร้างใหม่ทุกครั้งที่มีการเปลี่ยนแปลง kernel และการรันคำสั่งในจังหวะที่ไม่เหมาะสมอาจทำให้คุณเหลือ kernel เพียงเวอร์ชันเดียวโดยไม่มีรายการสำรองในเมนูบูต

unattended-upgrades สามารถทำให้ระบบบูตไม่ได้หรือไม่

มันสามารถติดตั้ง kernel ที่บูตไม่ขึ้นในภายหลังได้ แต่จะไม่รีสตาร์ทเครื่องเองเว้นแต่จะตั้งค่า Unattended-Upgrade::Automatic-Reboot เป็น true ใน /etc/apt/apt.conf.d/50unattended-upgrades รูปแบบที่พบบ่อยคือความล้มเหลวที่ล่าช้า: kernel ถูกติดตั้งระหว่างการอัปเดตอัตโนมัติ /var/run/reboot-required ปรากฏขึ้น และปัญหาจะแสดงตัวออกมาเมื่อคุณรีบูตเครื่องในอีกหลายสัปดาห์ถัดมา ให้รีบูตเครื่องอย่างตั้งใจโดยเปิดคอนโซลทิ้งไว้ และอ่าน /var/log/apt/history.log เพื่อดูว่าการรันครั้งใดที่ติดตั้ง kernel ที่คุณกำลังบูตอยู่