วิธีลบ kernel เก่าบน Ubuntu เพื่อเพิ่มพื้นที่ใน /boot

เหตุใด apt จึงหยุดทำงานเมื่อ /boot เต็มไปด้วย kernel เก่า

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

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

ลักษณะของความล้มเหลวที่เกิดขึ้นจริง

การติดตั้ง kernel เวอร์ชันใหม่จะนำไฟล์ขนาดใหญ่สองไฟล์ไปวางไว้ใน /boot ได้แก่ kernel ที่ถูกบีบอัด (vmlinuz-<version>) และ initramfs (initial RAM filesystem, initrd.img-<version> ซึ่งเป็นไฟล์ archive ขนาดเล็กที่ kernel จะแตกไฟล์ออกมาก่อนที่จะ mount root filesystem จริง) ไฟล์ initramfs จะถูกสร้างขึ้นบนเครื่องของคุณในระหว่างการติดตั้ง นี่คือเหตุผลว่าทำไมการติดตั้งจึงต้องการพื้นที่ว่างบนดิสก์ ไม่ใช่แค่ความเร็วในการดาวน์โหลดเท่านั้น หากพื้นที่ไม่เพียงพอ กระบวนการสร้างไฟล์จะล้มเหลวและส่งผลให้การติดตั้งแพ็กเกจนั้นไม่สำเร็จ

update-initramfs: Generating /boot/initrd.img-6.8.0-64-generic
gzip: stdout: No space left on device
E: mkinitramfs failure gzip 1
update-initramfs: failed for /boot/initrd.img-6.8.0-64-generic with 1.
dpkg: error processing package linux-image-6.8.0-64-generic (--configure):
 installed linux-image-6.8.0-64-generic package post-installation script subprocess returned error exit status 1

สตริงเวอร์ชันจะเป็นไปตามเวอร์ชันที่คุณใช้งาน ชื่อของโปรแกรมบีบอัดจะมาจาก COMPRESS= ใน /etc/initramfs-tools/initramfs.conf ดังนั้นอิมเมจรุ่นใหม่ๆ อาจระบุเป็น zstd ในขณะที่รุ่นเก่าอาจระบุเป็น gzip บรรทัดสองบรรทัดที่ระบุถึงปัญหานี้คือ No space left on device และบรรทัด dpkg: error processing package ที่อยู่ด้านล่าง

หลังจากนั้น แพ็กเกจจะอยู่ในสถานะที่ถูกกำหนดค่าไม่สมบูรณ์ การรัน apt ในครั้งถัดๆ ไปจะพยายามกำหนดค่าแพ็กเกจนี้ซ้ำอีกครั้ง แต่ก็จะล้มเหลวด้วยสาเหตุเดิมและจบลงด้วย E: Sub-process /usr/bin/dpkg returned an error code (1) นี่คือส่วนที่สำคัญนอกเหนือจากเรื่องพื้นที่ดิสก์ เพราะ unattended-upgrades จะทำงานตามตัวตั้งเวลาของมัน เมื่อเจอข้อผิดพลาดเดียวกันก็จะหยุดทำงาน ทำให้เซิร์ฟเวอร์ดูเหมือนปกติแต่หยุดการติดตั้งแพตช์ความปลอดภัยไปอย่างเงียบๆ นอกจากนี้ยังหมายความว่าการติดตั้งซอฟต์แวร์อื่นๆ ที่ไม่เกี่ยวข้องจะล้มเหลวด้วยข้อความเดียวกัน และความผิดจะไปตกอยู่กับสิ่งที่คุณกำลังติดตั้งในขณะนั้น ซึ่งเป็นเหตุผลว่าทำไม การติดตั้ง Tailscale ที่ล้มเหลบบน Ubuntu จึงควรถูกอ่านในฐานะข้อผิดพลาดของ apt เป็นอันดับแรก หาก apt update ล้มเหลวก่อนที่จะมาถึงขั้นตอนนี้ นั่นถือเป็นปัญหาแยกต่างหาก ซึ่งมักจะเป็น รายการซ้ำหลังจากย้ายไปใช้ deb822 sources

ตรวจสอบว่า /boot เป็นพาร์ทิชันแยกต่างหากหรือไม่

ก่อนจะลบสิ่งใด ให้ตรวจสอบก่อนว่าคุณกำลังเพิ่มพื้นที่ว่างจากส่วนใด

findmnt /boot
findmnt -T /boot
df -h /boot /

คำสั่งแรกจะแสดงบรรทัดออกมาก็ต่อเมื่อ /boot เป็นจุดเชื่อมต่อ (mount point) ของตัวเองเท่านั้น ส่วนคำสั่งที่สองจะแสดงผลเสมอและระบุชื่อระบบไฟล์ที่ถือครอง /boot อยู่จริง หากทั้งสองคำสั่งระบุชื่อระบบไฟล์เดียวกันกับ / แสดงว่า /boot เป็นเพียงไดเรกทอรีหนึ่งบนระบบไฟล์ root และไม่สามารถเต็มได้ด้วยตัวเอง: ระบบไฟล์ root ของคุณกำลังเต็ม และ kernel เก่าเป็นเพียงปัจจัยหนึ่งในหลายๆ ปัจจัย ในกรณีนั้น sudo apt clean ซึ่งเป็นการล้างไฟล์ .deb ที่ดาวน์โหลดมาภายใต้ /var/cache/apt/archives จะช่วยเพิ่มพื้นที่ว่างให้คุณได้ แต่บนเครื่องที่มีพาร์ทิชัน /boot แยกต่างหาก apt clean จะไม่ช่วยเพิ่มพื้นที่ว่างในส่วนนั้นเลย เพราะแคชถูกจัดเก็บไว้บนระบบไฟล์อื่น

จากนั้นให้ดูตัวเลขที่คุณต้องใช้ในการพิจารณา

df -h /boot
ls -lh /boot/vmlinuz-$(uname -r) /boot/initrd.img-$(uname -r)

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

ค้นหาเคอร์เนลที่คุณกำลังใช้งานอยู่

uname -r
cat /var/run/reboot-required.pkgs

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

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

แสดงรายการแพ็กเกจเคอร์เนลและสถานะของแพ็กเกจเหล่านั้น

dpkg --list | grep -E 'linux-(image|modules|headers|tools)' | awk '{print $1, $2}'

ฟิลด์แรกคือรหัสสถานะของ dpkg โดย ii หมายถึงติดตั้งและกำหนดค่าเรียบร้อยแล้ว iF หมายถึงติดตั้งแล้วแต่กำหนดค่าไม่สมบูรณ์ ซึ่งเป็นสถานะที่ค้างอยู่หลังจากเกิดการอัปเกรดล้มเหลวตามที่กล่าวไปข้างต้น rc หมายถึงถูกลบออกไปแล้วแต่ไฟล์กำหนดค่ายังคงอยู่บนดิสก์ ซึ่งไม่ได้ใช้พื้นที่ใน /boot และสามารถสั่ง purge ได้อย่างปลอดภัย

ฟิลด์ที่สองระบุประเภทของแพ็กเกจ ชื่อที่มีเวอร์ชันกำกับอยู่ เช่น linux-image-6.8.0-64-generic คือเคอร์เนลเวอร์ชันเฉพาะ ส่วนชื่อที่ไม่มีเวอร์ชัน เช่น linux-image-generic, linux-headers-generic หรือ linux-generic คือ meta package ซึ่งไม่มีตัวเคอร์เนลอยู่ภายใน หน้าที่หลักของมันคือการระบุ dependency ไปยังเคอร์เนลเวอร์ชันล่าสุดเพื่อให้ apt upgrade ดึงเคอร์เนลใหม่เข้ามาติดตั้ง การลบ meta package จะทำให้เครื่องไม่ได้รับอัปเดตเคอร์เนลอีกต่อไป และจะไม่มีการแจ้งเตือนใดๆ หลังจากนั้น

ตระกูลของแพ็กเกจแบ่งออกได้ดังนี้ linux-image-* เก็บไฟล์เคอร์เนลที่บีบอัดไว้ใน /boot ส่วน linux-modules-* และ linux-modules-extra-* เก็บไดรเวอร์ไว้ภายใต้ /lib/modules และ linux-headers-* เก็บ build headers ไว้ภายใต้ /usr/src ซึ่งหมายความว่าการ purge แพ็กเกจ headers จะช่วยเพิ่มพื้นที่ใน root filesystem ไม่ใช่พื้นที่ใน /boot หากปัญหาของคุณคือพาร์ทิชัน /boot เต็ม แพ็กเกจประเภท image คือสิ่งที่คุณต้องจัดการ

ls -1 /boot/vmlinuz-*
ls -1 /lib/modules/

รายการทั้งสองนี้ควรตรงกันและสอดคล้องกับผลลัพธ์ของ dpkg --list หากพบไดเรกทอรีใน /lib/modules ที่ไม่มีแพ็กเกจที่ติดตั้งไว้รองรับ แสดงว่าเป็นไฟล์ตกค้างจากการลบไฟล์ด้วยตนเอง

วิธีที่ apt ตัดสินใจว่าจะเก็บ kernel ใดไว้

apt autoremove จะไม่ลบ kernel ที่ถือว่าได้รับการป้องกัน ซึ่งชุดที่ได้รับการป้องกันนี้รวมถึง kernel ที่คุณกำลังใช้งานอยู่ในขณะนี้ นโยบายการเก็บรักษาได้มีการเปลี่ยนแปลงไปในแต่ละรุ่นของ Ubuntu ดังนั้นโปรดตรวจสอบจากเครื่องของคุณเองแทนที่จะเชื่อตัวเลขที่ระบุไว้ในเอกสารอื่น

apt-config dump | grep -i -e neverautoremove -e versionedkernel
ls -l /etc/apt/apt.conf.d/01autoremove /etc/apt/apt.conf.d/01autoremove-kernels

APT::NeverAutoRemove คือรายการรูปแบบชื่อแพ็กเกจที่ apt autoremove ปฏิเสธที่จะดำเนินการใดๆ APT::VersionedKernelPackages คือรายการคำนำหน้าชื่อที่ apt ถือว่าเป็นแพ็กเกจ kernel แบบมีเวอร์ชันตั้งแต่แรก ในรุ่นที่สร้างไฟล์ /etc/apt/apt.conf.d/01autoremove-kernels ขึ้นมา ไฟล์นั้นจะถูกเขียนทับโดย /etc/kernel/postinst.d/apt-auto-removal ทุกครั้งที่มีการติดตั้งแพ็กเกจ kernel ดังนั้นการแก้ไขด้วยตนเองจึงไม่มีผลใดๆ เพราะการติดตั้ง kernel ครั้งถัดไปจะเขียนทับสิ่งที่คุณแก้ไขไว้ ในรุ่นที่ไม่มีไฟล์ดังกล่าว apt จะใช้การป้องกันเดียวกันนี้ภายในระบบ ไม่ว่าในกรณีใด apt-config dump จะแสดงกฎที่บังคับใช้อยู่บนเครื่องของคุณ และผลลัพธ์นั้นคือคำตอบที่ถูกต้องสำหรับรุ่นที่คุณใช้งานอยู่

การล้างข้อมูลที่ปลอดภัยในการดำเนินการ

sudo apt update
sudo apt autoremove --purge --dry-run

--dry-run จะไม่เปลี่ยนแปลงข้อมูลใดๆ บนดิสก์ แต่จะแสดงรายการสิ่งที่การทำงานจริงจะลบออกให้เห็น ให้ตรวจสอบรายการดังกล่าว หากพบสองสิ่งนี้ควรหยุดดำเนินการทันที: หากมี meta package เช่น linux-generic หรือ linux-image-generic อยู่ในรายการที่จะลบ แสดงว่ามีบางอย่างทำเครื่องหมายแพ็กเกจนั้นไว้ว่าเป็นแบบอัตโนมัติ ซึ่งการลบออกจะทำให้การอัปเดต kernel ของคุณหยุดทำงาน และหากมีสตริงจาก uname -r อยู่ในรายการที่จะลบ แสดงว่า kernel ที่กำลังใช้งานอยู่ไม่ได้รับการป้องกัน ซึ่งไม่ควรเกิดขึ้นและจำเป็นต้องตรวจสอบก่อนดำเนินการต่อ

หากรายการถูกต้อง ให้ดำเนินการจริง

sudo apt autoremove --purge
df -h /boot

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

จากนั้นให้ยืนยันว่าเมนูการบูตถูกสร้างใหม่แล้ว การลบแพ็กเกจ kernel จะเรียกใช้ update-grub ให้โดยอัตโนมัติ ดังนั้นเมนูควรจะอ้างอิงเฉพาะไฟล์ที่มีอยู่จริงเท่านั้น

sudo grep -o 'vmlinuz-[^ ]*' /boot/grub/grub.cfg | sort -u
ls -1 /boot/vmlinuz-*

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

เหตุใด apt autoremove บางครั้งจึงไม่ลบแพ็กเกจใดเลย

apt autoremove จะลบเฉพาะแพ็กเกจที่ถูกทำเครื่องหมายว่าเป็น automatic เท่านั้น ซึ่งหมายถึงแพ็กเกจที่ถูกติดตั้งโดยอัตโนมัติในฐานะ dependency ของซอฟต์แวร์อื่น ส่วน kernel ที่คุณติดตั้งด้วยตนเองผ่าน apt install linux-image-6.8.0-40-generic จะถูกทำเครื่องหมายว่าเป็น manual ซึ่ง autoremove จะไม่ลบแพ็กเกจเหล่านี้ไม่ว่าจะเก่าเพียงใดก็ตาม

apt-mark showmanual | grep -E '^linux-'

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

sudo apt-mark auto linux-image-6.8.0-40-generic linux-modules-6.8.0-40-generic
sudo apt autoremove --purge --dry-run

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

การลบ kernel ที่ระบุออกโดยเจตนา

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

sudo apt purge linux-image-6.8.0-40-generic

apt จะแสดงรายการที่จะถูกลบออกก่อนดำเนินการใดๆ เนื่องจาก linux-modules-extra-* มีความสัมพันธ์แบบ dependency กับแพ็กเกจ image จึงจำเป็นต้องถูกลบออกใน transaction เดียวกัน รายการที่แสดงออกมานี้คือการตรวจสอบความปลอดภัยที่แท้จริงของคุณ ซึ่งเป็นจุดที่คุณจะสังเกตเห็นได้หากมี meta package ถูกลบออกไปพร้อมกับเวอร์ชันที่คุณต้องการลบ ให้ตอบ n หากมีสิ่งใดที่ไม่คาดคิดปรากฏอยู่ในรายการ จากนั้นให้ใช้ sudo apt autoremove --purge ตามเพื่อลบแพ็กเกจ module และ header ที่ไม่มีความจำเป็นต้องใช้งานอีกต่อไป

เหตุผลที่คุณไม่ควรลบ kernel ที่กำลังทำงานอยู่

kernel ที่อยู่ในหน่วยความจำจะยังคงทำงานต่อไปแม้ไฟล์ของมันจะถูกลบไปแล้ว ทำให้ดูเหมือนไม่มีอะไรเสียหายในตอนแรก สิ่งที่จะเกิดปัญหาคือทุกอย่างที่ kernel ยังไม่ได้โหลดเข้ามาใช้งาน การสั่ง purge linux-modules-$(uname -r) จะเป็นการลบ /lib/modules/$(uname -r)/ ออกไป ส่งผลให้การโหลด module ในครั้งถัดไปล้มเหลว:

modprobe: FATAL: Module nf_tables not found in directory /lib/modules/6.8.0-64-generic

การโหลด firewall ใหม่จะล้มเหลวจากจุดนี้ รวมถึงการ mount ระบบไฟล์ประเภทที่ kernel นี้ยังไม่ได้เรียกใช้งานตั้งแต่เริ่มบูต ในขณะเดียวกัน /boot/vmlinuz-$(uname -r) ก็ถูกลบไปแล้ว ทำให้เมนูบูตไม่แสดง kernel ที่คุณกำลังใช้งานอยู่ และการรีบูตครั้งถัดไปจะนำไปสู่สถานะที่ไม่สามารถบูตได้ เครื่องยังคงให้บริการ traffic ได้ตามปกติแต่ไม่สามารถบูตเข้าสู่ระบบได้อีกต่อไป ให้ตรวจสอบ uname -r เทียบกับรายการที่จะลบทุกครั้ง

เมื่อ /boot เต็มจนไม่สามารถรัน apt ได้

นี่คือสถานะที่ทำให้ผู้ใช้ต้องเข้ามาค้นหาหน้านี้ apt autoremove จำเป็นต้องใช้ dpkg เพื่อดำเนินการตั้งค่าแพ็กเกจเคอร์เนลที่ค้างอยู่ให้เสร็จสิ้นก่อน ซึ่งขั้นตอนดังกล่าวจะสร้าง initramfs ขึ้นใหม่ โดยต้องใช้พื้นที่ใน /boot ซึ่งในขณะนี้ไม่มีพื้นที่เหลืออยู่ คุณต้องทำลายวงจรนี้ด้วยตนเองหนึ่งครั้ง

uname -r
ls -1 /boot/initrd.img-*

เลือก initrd หนึ่งเวอร์ชันที่ไม่ใช่สตริงที่ uname -r แจ้งคุณมา แล้วลบไฟล์นั้นทิ้งเพียงไฟล์เดียว

sudo rm /boot/initrd.img-6.8.0-40-generic
sudo apt --fix-broken install
sudo apt autoremove --purge
sudo update-grub

แต่ละบรรทัดมีเหตุผลรองรับ rm เป็นข้อยกเว้นที่ตั้งใจทำขึ้นเพื่อให้ dpkg เข้าใจว่าไฟล์ยังมีอยู่ทั้งที่ไม่มีจริง apt --fix-broken install จะดำเนินการตั้งค่าที่เคยล้มเหลวให้เสร็จสมบูรณ์ เนื่องจากตอนนี้มีพื้นที่ว่างเพียงพอสำหรับ initramfs แล้ว จากนั้น autoremove --purge จะลบแพ็กเกจที่มีไฟล์ที่คุณเพิ่งลบทิ้งไปพร้อมกับเวอร์ชันเก่าอื่นๆ ซึ่งจะทำให้ dpkg กลับมาสอดคล้องกับสถานะของดิสก์อีกครั้ง update-grub จะสร้างเมนูขึ้นใหม่จากไฟล์ที่มีอยู่จริง ห้ามรีบูตเครื่องระหว่างขั้นตอน rm และ update-grub เพราะในช่วงเวลานั้นเมนูอาจยังชี้ไปยังไฟล์ที่คุณเพิ่งลบไป หาก dpkg แจ้งเตือนว่าถูกขัดจังหวะ sudo dpkg --configure -a จะทำหน้าที่ซ่อมแซมเช่นเดียวกับ apt --fix-broken install

งานเดียวกันบนระบบ dnf

หาก VPS ของคุณรัน Fedora หรือ RHEL rebuild เช่น Rocky Linux กลไกการทำงานจะกลับกัน Debian และ Ubuntu จะปกป้องเคอร์เนลด้วยกฎ apt autoremove และปล่อยให้เป็นหน้าที่ของคุณหรือ unattended-upgrades ในการสั่งล้างข้อมูล ในขณะที่ dnf จะบังคับใช้จำนวนที่เรียกว่า installonly_limit และลบเคอร์เนลที่เก่าที่สุดออกโดยอัตโนมัติทันทีที่มีการติดตั้งเคอร์เนลใหม่เกินจำนวนที่กำหนด คุณสามารถอ่านค่าที่บังคับใช้อยู่ได้ด้วย grep installonly_limit /etc/dnf/dnf.conf และ man 5 dnf.conf และล้างรายการเคอร์เนลเก่าที่ค้างอยู่ได้ด้วย sudo dnf remove --oldinstallonly ทั้งนี้เคอร์เนลที่กำลังรันอยู่จะได้รับการปกป้องในระบบนี้เช่นกัน สำหรับการเปรียบเทียบคำสั่งระหว่างตัวจัดการแพ็กเกจทั้งสองแบบ โปรดดูที่ คำสั่งที่เทียบเท่ากันระหว่าง dnf และ apt

ป้องกันไม่ให้เกิดซ้ำ

การล้างข้อมูลที่ต้องอาศัยการจดจำของคุณจะล้มเหลวในที่สุด ดังนั้นให้ใส่คำสั่งไว้ในส่วนที่ติดตั้ง kernel โดยเปิดไฟล์ /etc/apt/apt.conf.d/50unattended-upgrades แล้วมองหาคีย์เหล่านี้ ซึ่งไฟล์ที่ติดตั้งมาพร้อมระบบมีบรรทัดเหล่านี้อยู่แล้วในรูปแบบคอมเมนต์:

Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";

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

apt-config dump | grep -i 'Unattended-Upgrade::Remove'
sudo unattended-upgrade --dry-run --debug
sudo tail -n 40 /var/log/unattended-upgrades/unattended-upgrades.log

Log คือหลักฐานสำคัญ มันจะบันทึกการทำงานแต่ละครั้งไว้ ดังนั้นการอัปเกรดที่ล้มเหลวเพราะพื้นที่ไม่เพียงพอจะปรากฏในนั้นก่อนที่ใครจะสังเกตเห็นว่าเครื่องไม่ได้อัปเดตแพตช์ การตั้งค่าส่วนที่เหลือครอบคลุมอยู่ใน การอัปเดตความปลอดภัยอัตโนมัติบน Ubuntu

ก่อนที่ kernel ถัดไปจะมาถึง มีตัวเลขหนึ่งชุดที่ต้องตรวจสอบ ซึ่งเป็นคำสั่งคู่เดิมจากตอนเริ่มต้นของคู่มือนี้:

df -h /boot
ls -lh /boot/initrd.img-$(uname -r)

หาก Avail ไม่ได้มีขนาดใหญ่กว่าไฟล์นั้นอย่างเพียงพอ kernel ถัดไปจะล้มเหลวในลักษณะเดียวกับที่อธิบายไว้ข้างต้น ดังนั้นให้แก้ไขเสียตั้งแต่ตอนนี้แทนที่จะไปทำระหว่างการอัปเกรด การตรวจสอบนี้คุ้มค่าที่จะเสียเวลาสักนาทีควบคู่ไปกับ การตรวจสอบสุขภาพของดิสก์บน VPS ของคุณ สิ่งนี้สำคัญที่สุดก่อนการอัปเกรดเวอร์ชันหลัก เพราะ การย้าย Ubuntu 24.04 ไปยัง 26.04 จะติดตั้ง kernel ใหม่ตั้งแต่ช่วงต้นของกระบวนการ และ do-release-upgrade จะปฏิเสธที่จะดำเนินการต่อเมื่อ /boot มีพื้นที่ไม่เพียงพอ

FAQ

ทำไม Ubuntu ถึงเก็บ kernel รุ่นเก่าไว้แทนที่จะลบออก?

เพราะหาก kernel ที่อัปเดตใหม่บูตไม่ขึ้น คุณจะไม่มีตัวเลือกอื่นให้ใช้งาน การเก็บเวอร์ชันก่อนหน้าไว้ช่วยให้คุณสามารถกู้คืนระบบจากเมนู GRUB ได้หากการอัปเดตมีปัญหา แทนที่จะต้องไปแก้ไขผ่าน rescue console ของผู้ให้บริการ apt จึงปกป้องชุดแพ็กเกจ kernel ไม่ให้ถูกลบโดยอัตโนมัติ โดยจะรวมเวอร์ชันที่คุณกำลังใช้งานอยู่เสมอ ให้รัน apt-config dump | grep -i neverautoremove เพื่อดูรูปแบบการปกป้องของรุ่นที่คุณใช้ เนื่องจากนโยบายมีการเปลี่ยนแปลงไปในแต่ละ release

การรัน apt autoremove --purge บนเซิร์ฟเวอร์ production ปลอดภัยหรือไม่?

ปลอดภัย หากคุณตรวจสอบผลลัพธ์จากการจำลองการทำงาน (dry run) ก่อน ให้รัน sudo apt autoremove --purge --dry-run ซึ่งจะไม่เขียนข้อมูลใดๆ ลงในระบบ แล้วตรวจสอบรายการที่แสดงขึ้นมา หากพบ meta package เช่น linux-generic หรือ linux-image-generic ให้หยุดทันที เพราะการลบแพ็กเกจเหล่านี้จะทำให้การอัปเดต kernel ในอนาคตหยุดชะงัก และให้หยุดเช่นกันหากรายการนั้นรวมถึงเวอร์ชันที่แสดงโดย uname -r หากไม่พบรายการดังกล่าว แสดงว่าสิ่งที่ถูกลบคือ kernel รุ่นเก่าและ dependency ที่ไม่ได้ใช้งานแล้ว

apt autoremove ไม่ลบอะไรเลย แต่ /boot ยังเต็มอยู่ ต้องทำอย่างไร?

เป็นไปได้สูงว่า kernel รุ่นเก่าถูกทำเครื่องหมายว่าติดตั้งด้วยตนเอง (manual) ซึ่งคำสั่ง autoremove จะจัดการเฉพาะแพ็กเกจที่ทำเครื่องหมายว่าติดตั้งอัตโนมัติ (automatic) เท่านั้น ให้รัน apt-mark showmanual | grep -E '^linux-' หากมี kernel เวอร์ชันใดปรากฏในรายการ แสดงว่าเคยมีการติดตั้งด้วยตนเองในอดีต ให้เปลี่ยนสถานะเป็น automatic ด้วยคำสั่ง sudo apt-mark auto linux-image-<version> แล้วรันคำสั่งจำลองการทำงานอีกครั้ง หรือจะลบเวอร์ชันนั้นออกโดยตรงด้วย sudo apt purge linux-image-<version> ก็ได้

ฉันสามารถลบไฟล์ใน /boot ด้วยตนเองได้หรือไม่?

ทำได้เฉพาะกรณีจำเป็นเร่งด่วนเท่านั้น เมื่อ /boot เต็มจน apt ไม่สามารถตั้งค่าแพ็กเกจ kernel ที่เสียหายได้ ให้ลบไฟล์ initrd.img-<version> เพียงไฟล์เดียวที่เวอร์ชันไม่ตรงกับผลลัพธ์ของ uname -r จากนั้นให้รัน sudo apt --fix-broken install, sudo apt autoremove --purge และ sudo update-grub ทันที การลบไฟล์โดยไม่มีขั้นตอนเหล่านี้จะทำให้ dpkg บันทึกแพ็กเกจที่ไฟล์ต้นทางหายไปแล้ว และทำให้เมนู GRUB ชี้ไปยังไฟล์ที่ไม่มีอยู่จริง ซึ่งจะส่งผลให้เครื่องบูตไม่ขึ้นในการรีบูตครั้งถัดไป แทนที่จะเกิดปัญหาในขณะที่คุณกำลังแก้ไขไฟล์