SSD Nodes Learn Hosting plans →
คู่มือ Matt Connorโดย Matt Connor · อัปเดตเมื่อ 2026-08-28

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

เมื่อพาร์ทิชัน /boot เต็มจน apt แจ้งเตือน Error ไม่สามารถติดตั้งแพ็กเกจได้ เรียนรู้วิธีตรวจสอบและลบไฟล์ kernel เก่าทิ้งอย่างปลอดภัยโดยไม่กระทบต่อระบบที่กำลังใช้งานอยู่

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

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

ลำดับขั้นตอนมีความสำคัญ เคอร์เนลที่กำลังทำงานอยู่เป็นแพ็กเกจเดียวที่คุณห้ามลบ และเครื่องอาจอยู่ในสถานะที่ 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 จะทำงานตามเวลาที่ตั้งไว้ (timer) และเมื่อพบข้อผิดพลาดเดียวกันก็จะหยุดทำงานไป ส่งผลให้เซิร์ฟเวอร์ดูเหมือนปกติแต่หยุดการติดตั้งแพตช์ความปลอดภัยโดยเงียบๆ นอกจากนี้ยังหมายความว่าการติดตั้งซอฟต์แวร์อื่นที่ไม่เกี่ยวข้องที่คุณพยายามทำจะล้มเหลวด้วยข้อความเดียวกัน และความผิดจะไปตกอยู่กับสิ่งที่คุณกำลังติดตั้งในขณะนั้น ซึ่งเป็นเหตุผลว่าทำไม การติดตั้ง Tailscale ที่ล้มเหลวบน Ubuntu จึงควรถูกอ่านในฐานะข้อผิดพลาดของ apt เป็นอันดับแรก หาก apt update ล้มเหลวก่อนที่คุณจะมาถึงขั้นตอนนี้ นั่นถือเป็นปัญหาแยกต่างหาก ซึ่งมักจะเป็น รายการซ้ำหลังจากการย้ายแหล่งที่มาแบบ deb822

ตรวจสอบว่า /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 ที่คุณกำลังใช้งานอยู่ในขณะนี้ นโยบายการเก็บรักษา 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 ของซอฟต์แวร์อื่น สำหรับเคอร์เนลที่คุณติดตั้งด้วยตนเองผ่าน apt install linux-image-6.8.0-40-generic ระบบจะทำเครื่องหมายว่าเป็นแบบ manual ดังนั้น autoremove จะไม่ลบเคอร์เนลเหล่านั้นออกไม่ว่าจะเก่าเพียงใดก็ตาม

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

เคอร์เนลที่มีเวอร์ชันระบุไว้ในผลลัพธ์ดังกล่าวจะถูกมองข้ามโดย 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 จึงจำเป็นต้องถูกลบออกในธุรกรรมเดียวกัน รายการที่แสดงนี้คือการตรวจสอบความปลอดภัยที่สำคัญที่สุด ซึ่งจะช่วยให้คุณสังเกตเห็นหากมี 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 จะป้องกัน kernel ไว้ด้วยกฎ autoremove ของ apt และปล่อยให้เป็นหน้าที่ของคุณหรือ unattended-upgrades ในการจัดการล้างข้อมูล ในขณะที่ dnf จะบังคับใช้จำนวนที่กำหนดไว้ใน installonly_limit และลบ kernel ที่เก่าที่สุดออกโดยอัตโนมัติทันทีที่มีการติดตั้ง kernel ใหม่เกินจำนวนดังกล่าว คุณสามารถอ่านค่าที่บังคับใช้อยู่ได้ด้วย grep installonly_limit /etc/dnf/dnf.conf และ man 5 dnf.conf และล้างรายการที่ค้างอยู่ได้ด้วย sudo dnf remove --oldinstallonly ทั้งนี้ kernel ที่กำลังทำงานอยู่จะได้รับการป้องกันไว้เช่นกัน สำหรับการเปรียบเทียบคำสั่งระหว่างตัวจัดการแพ็กเกจทั้งสองระบบ โปรดดูที่ คำสั่งที่เทียบเท่ากันระหว่าง dnf และ apt

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

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

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

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

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 คือหลักฐานสำคัญ มันจะบันทึกการทำงานแต่ละครั้ง ดังนั้นการอัปเกรดที่ล้มเหลวเนื่องจากพื้นที่ไม่เพียงพอจะปรากฏใน 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 มีพื้นที่ไม่เพียงพอ หากเซิร์ฟเวอร์ LTS ของคุณยังไม่ได้รับการเสนอให้อัปเกรด สาเหตุเป็นเรื่องของช่วงเวลาไม่ใช่ความผิดพลาด เนื่องจาก Ubuntu จะชะลอการอัปเกรดจาก LTS ไปยัง LTS จนกว่า รุ่น point release 26.04.1 จะถูกปล่อยออกมา ซึ่งจะให้ช่วงเวลาที่คุณทราบล่วงหน้าเพื่อจัดการ /boot ให้เรียบร้อยก่อน

FAQ

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

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

การรัน 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 จะจัดการเฉพาะแพ็กเกจที่ทำเครื่องหมายเป็นแบบอัตโนมัติเท่านั้น ให้รัน apt-mark showmanual | grep -E '^linux-' หากมี kernel เวอร์ชันใดปรากฏในรายการ แสดงว่ามีการติดตั้งด้วยตนเองในบางช่วงเวลา ให้เปลี่ยนสถานะเป็นแบบอัตโนมัติด้วย 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 ชี้ไปยังไฟล์ที่ไม่มีอยู่จริง ส่งผลให้เครื่องไม่สามารถบูตได้ในการรีบูตครั้งถัดไป แทนที่จะเกิดข้อผิดพลาดในขณะที่คุณกำลังแก้ไขไฟล์