สรุปฟีเจอร์ใหม่ Linux kernel 7.1 สำหรับเซิร์ฟเวอร์

มีอะไรใหม่ใน Linux kernel 7.1

Linux kernel 7.1 ได้รับการเผยแพร่เมื่อวันที่ 14 มิถุนายน 2026 ซึ่งเป็นเวลาเก้าสัปดาห์หลังจากเวอร์ชัน 7.0 สำหรับผู้เช่า VPS (virtual private server) การเปลี่ยนแปลงที่สำคัญจะอยู่ในสี่ด้าน ได้แก่ พื้นที่จัดเก็บข้อมูลและระบบไฟล์, ระบบเครือข่าย, การจัดการหน่วยความจำ และการควบคุมกระบวนการและคอนเทนเนอร์ ส่วนที่เหลือของการเผยแพร่นี้ส่วนใหญ่เป็นงานด้านเดสก์ท็อปและกราฟิก ซึ่งเซิร์ฟเวอร์แบบ headless จะไม่มีการโหลดใช้งาน

มีคำตอบที่สองที่คุณจำเป็นต้องทราบก่อน นั่นคือ 7.1 แทบจะไม่ได้ทำงานอยู่บนเซิร์ฟเวอร์ของคุณอย่างแน่นอน และจะยังไม่เป็นเช่นนั้นไปอีกนาน kernel.org ไม่ได้ระบุว่า 7.1 เป็นรุ่น longterm ณ วันที่ 11 สิงหาคม 2026 สายการพัฒนาแบบ longterm ได้แก่ 6.18, 6.12, 6.6, 6.1, 5.15 และ 5.10 โดยที่ distribution สำหรับเซิร์ฟเวอร์กระแสหลักทุกตัวจะสร้างขึ้นบนเวอร์ชันเหล่านี้หรือบนสายการพัฒนาที่ทางผู้ผลิตดูแลเอง "สิ่งใหม่ใน kernel" และ "สิ่งใหม่บนเซิร์ฟเวอร์ของคุณ" นั้นมีระยะห่างกันหลายปี ดังนั้นคู่มือนี้จึงครอบคลุมทั้งสองส่วน

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

uname -r
uname -srm
systemd-detect-virt

uname -r จะแสดงเวอร์ชันของเคอร์เนลที่กำลังทำงานอยู่ สำหรับ Ubuntu 24.04 ผลลัพธ์จะมีลักษณะเป็น 6.8.0-79-generic ส่วนที่อยู่ก่อนขีดกลางตัวแรกคือสายการพัฒนาหลัก (upstream line) และทุกสิ่งที่อยู่หลังจากนั้นคือหมายเลข build ของดิสทริบิวชันที่คุณใช้ ซึ่งไม่ได้ติดตามเวอร์ชันของ upstream แต่อย่างใด เคอร์เนล 6.8.0-79 ของ Canonical มีการนำการแก้ไขนับพันรายการจากเคอร์เนลรุ่นใหม่กว่ามาปรับใช้ย้อนหลัง (backport) ดังนั้นจึงไม่ใช่โค้ดชุดเดียวกับที่ Linus แท็กว่าเป็น 6.8 ในเดือนมีนาคม 2024 นี่คือเหตุผลที่การบอกว่า "เคอร์เนลของฉันเก่า" ไม่ได้สื่อความหมายได้มากเท่าที่คิด ฟีเจอร์อาจจะเก่า แต่การแก้ไขด้านความปลอดภัยมักจะทันสมัยอยู่เสมอ

systemd-detect-virt จะบอกคุณว่าคุณสามารถเปลี่ยนเคอร์เนลได้หรือไม่ โดยจะแสดงผลเป็น kvm บนเครื่องเสมือนแบบเต็ม (full virtual machine) ซึ่งคุณสามารถบูตอิมเมจเคอร์เนลของคุณเองได้และการอัปเกรดถือเป็นการอัปเกรดจริง แต่จะแสดงผลเป็น lxc หรือ openvz บนระบบเวอร์ชวลไลเซชันแบบคอนเทนเนอร์ ซึ่งมีการใช้เคอร์เนลร่วมกับโฮสต์ ในแผนแบบคอนเทนเนอร์ uname -r จะแสดงเคอร์เนลของผู้ให้บริการ การติดตั้งแพ็กเกจเคอร์เนลจะไม่เปลี่ยนแปลงสิ่งที่คุณสามารถบูตได้ และไม่มีฟีเจอร์ใดในรุ่นนั้นที่จะใช้งานได้จนกว่าผู้ให้บริการจะรีบูตโฮสต์ไปยังเคอร์เนลที่ใหม่กว่า ให้ตรวจสอบส่วนนี้ก่อนที่คุณจะวางแผนดำเนินการใดๆ เกี่ยวกับเคอร์เนล

[
  {
    "distro": "Ubuntu 26.04 LTS (7.0)",
    "releases_behind_7_1": 1,
    "notes": "GA kernel, shipped with the April 2026 release"
  },
  {
    "distro": "Ubuntu 24.04 LTS, HWE (6.17)",
    "releases_behind_7_1": 4,
    "notes": "6.17 came with 24.04.4; 7.0 is rolling out ahead of 24.04.5 on 27 August 2026"
  },
  {
    "distro": "Debian 13 trixie (6.12)",
    "releases_behind_7_1": 9,
    "notes": "upstream longterm line, kernel.org projected EOL December 2028"
  },
  {
    "distro": "RHEL 10 and its rebuilds (6.12)",
    "releases_behind_7_1": 9,
    "notes": "Red Hat backports fixes into its own frozen 6.12 stream"
  },
  {
    "distro": "Ubuntu 24.04 LTS, GA (6.8)",
    "releases_behind_7_1": 13,
    "notes": "the default unless you install the HWE stack"
  },
  {
    "distro": "Ubuntu 22.04 LTS, GA (5.15)",
    "releases_behind_7_1": 26,
    "notes": "upstream longterm line, kernel.org projected EOL December 2026"
  }
]

นั่นคือแพลตฟอร์มจำนวน 6 รายการ และไม่มีรายการใดเลยที่บูตด้วย 7.1 รุ่นที่ใหม่ที่สุดคือ Ubuntu 26.04 LTS (7.0) ซึ่งตามหลังรุ่น upstream อยู่ 1 รุ่น ส่วนรุ่นที่เก่าที่สุดที่ยังได้รับการสนับสนุนอยู่ตามหลังอยู่ 26 รุ่น เคอร์เนล GA เริ่มต้นของ Ubuntu 24.04 ตามหลังอยู่ 13 รุ่น ในขณะที่ Debian 13 และ RHEL 10 ตามหลังอยู่ 9 รุ่นบนสายการพัฒนาแบบ longterm 6.12 การนับจำนวนรุ่นเป็นเพียงการวัดแบบคร่าวๆ เพราะไม่ได้คำนึงถึงสิ่งที่ดิสทริบิวชันนำมา backport แต่ก็แสดงให้เห็นถึงช่องว่างของเวอร์ชัน หากคุณกำลังชั่งน้ำหนักว่าจะเลือกรุ่นใดมาใช้งาน การแลกเปลี่ยนระหว่าง LTS กับรุ่น interim บนเซิร์ฟเวอร์ คือการตัดสินใจที่อยู่เบื้องหลังตัวเลขเหล่านี้

การจัดเก็บข้อมูลและระบบไฟล์ใน 7.1

7.1 เพิ่มความสามารถในการสร้างและตรวจสอบ T10 PI (protection information) ภายในระบบไฟล์ แทนที่จะทำได้เฉพาะในระดับ block layer พร้อมกับการรองรับการจัดแนว T10 ที่ยืดหยุ่น T10 PI คือไบต์ส่วนเกินที่แนบไปกับแต่ละบล็อก โดยเก็บค่า checksum และแท็กที่ระบุว่าข้อมูลนั้นเป็นของบล็อกใด เพื่อให้สามารถตรวจพบการเขียนข้อมูลที่ผิดพลาดหรือข้อมูลที่ไม่สมบูรณ์ แทนที่จะส่งคืนข้อมูลเหล่านั้นว่าเป็นข้อมูลที่ถูกต้อง ข้อจำกัดสำหรับผู้เช่า VPS คือฮาร์ดแวร์ ข้อมูล metadata ด้านความสมบูรณ์ของข้อมูลจะต้องถูกเปิดเผยโดยอุปกรณ์ ซึ่งโดยปกติแล้ว virtual disk จะไม่เปิดเผยข้อมูลส่วนนี้

ls /sys/block/vda/integrity/

บนดิสก์ VPS ส่วนใหญ่จะส่งคืนค่า No such file or directory เนื่องจาก block layer จะสร้างไดเรกทอรี integrity ก็ต่อเมื่ออุปกรณ์มีการลงทะเบียนรองรับความสมบูรณ์ของข้อมูลเท่านั้น ข้อผิดพลาดดังกล่าวเป็นผลลัพธ์ปกติในกรณีนี้ ไม่ใช่ความผิดพลาด หากคุณต้องการทราบว่าดิสก์ของคุณคืออะไรก่อนที่จะอ่านรายละเอียดเกี่ยวกับฟีเจอร์การจัดเก็บข้อมูลเพิ่มเติม การตรวจสอบว่าดิสก์ VPS เป็น NVMe จริงหรือไม่ คือขั้นตอนแรก และ ช่องว่างระหว่าง NVMe กับ SATA SSD บน VPS จะอธิบายว่าเหตุใดคำตอบนี้จึงส่งผลต่อตัวเลขประสิทธิภาพของคุณ

Btrfs ได้รับการแก้ไขปัญหา copy-on-write amplification ในสภาวะที่มีแรงกดดันด้านหน่วยความจำ รวมถึงการปรับเปลี่ยนที่ช่วยเพิ่มความเร็วในการล้าง extent แรกใน tracked range ซึ่งรายงานว่ามี throughput เพิ่มขึ้น 10% ในภาระงานตัวอย่างที่ระบุไว้ในการรวมโค้ด (merge) การทำงานของคำสั่ง shutdown ไม่ถูกระบุว่าเป็น experimental อีกต่อไป XFS ปรับปรุงการล้างข้อมูล zero range และการค้นหาผ่าน iomap และเพิ่ม write pointer ให้กับ real-time group geometry ซึ่งเป็นการวางรากฐานสำหรับ zoned devices ส่วน NTFS เป็นการเขียนใหม่ทั้งหมดในรุ่นนี้ โดยรองรับการเขียนเต็มรูปแบบและการแปลง iomap ซึ่งมีความสำคัญหากคุณจำเป็นต้อง mount ดิสก์อิมเมจจากเครื่อง Windows บนเซิร์ฟเวอร์ของคุณ

รายการการจัดเก็บข้อมูลขนาดเล็กอื่นๆ ที่น่าสนใจ: ublk ซึ่งเป็น user-space block driver ได้รับการรองรับ zero-copy I/O, io_uring รองรับคำสั่ง SCSI passthrough, การรองรับ SED-OPAL self-encrypting drive ได้รับคำสั่ง STACK_RESET และขยายโหมด single user, มีไดรเวอร์ตัวอักษร fs-dax ใหม่สำหรับอุปกรณ์แบบ direct-access และ VFS ได้ขยาย inode->i_ino จาก unsigned long เป็น u64 ซึ่งช่วยลบข้อจำกัดของหมายเลข inode บน build แบบ 32-bit ในส่วนของ network filesystem นั้น NFS server ในเคอร์เนลสามารถลงลายมือชื่อ file handle ได้ผ่านตัวเลือกการ mount sign_fh และ CIFS client รองรับ O_TMPFILE แล้ว

ระบบเครือข่าย: การเช่าคิว (queue leasing) และสิ่งที่มอบให้กับคอนเทนเนอร์

การเปลี่ยนแปลงที่สำคัญที่สุดในส่วนของระบบเครือข่ายคือการเช่าคิวฮาร์ดแวร์ (hardware queue leasing) ปัจจุบัน virtual netdev สามารถเช่าคิวที่ผูกกับคิวจริงบน physical netdev และทำหน้าที่เป็นพร็อกซีให้ได้ จุดประสงค์หลักคือเพื่อรองรับคอนเทนเนอร์ ก่อนหน้านี้คอนเทนเนอร์ที่ต้องการใช้งาน AF_XDP (address family express data path ซึ่งเป็นประเภทของซ็อกเก็ตที่ส่งแพ็กเก็ตดิบไปยัง user space โดยไม่ต้องคัดลอกผ่าน network stack) จำเป็นต้องได้รับสิทธิ์เข้าถึงอุปกรณ์เกือบทั้งหมด แต่ด้วยการเช่าคิว คอนเทนเนอร์จะได้รับคิวฮาร์ดแวร์เพียงหนึ่งคิวเพื่อรัน AF_XDP และ memory providers ด้วยความเร็วระดับ native ในขณะที่โฮสต์ยังคงควบคุม NIC ส่วนที่เหลือไว้ได้ ฟีเจอร์นี้ถูกเพิ่มเข้ามาพร้อมกับการรองรับ AF_XDP ในเส้นทาง zero-copy ของ io_uring

ในส่วนของการใช้งานทั่วไป ซ็อกเก็ตใน sockfs รองรับ user.* extended attributes แล้ว ก่อนหน้านี้ AF_UNIX socket แบบอิงตามพาธได้รับสิทธิ์รองรับ xattr จากระบบไฟล์ที่อยู่เบื้องล่างอยู่แล้ว แต่ซ็อกเก็ตที่อยู่ใน sockfs เพียงอย่างเดียวกลับไม่มี ตอนนี้กระบวนการทำงานสามารถติดป้ายกำกับ (label) ให้กับซ็อกเก็ตได้ และโปรแกรม eBPF สามารถใช้ป้ายกำกับนั้นในการกรองข้อมูลได้

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

การจัดการหน่วยความจำ: ตาราง swap เสร็จสมบูรณ์แล้ว

การปรับปรุงระบบ swap เข้าสู่ระยะที่ 3 แล้ว โดยในระยะนี้จะทำการลบ static swap map ออกไป ข้อมูล swap count จะถูกเก็บไว้ใน swap table โดยตรง การเปลี่ยนแปลงนี้ช่วยประหยัดหน่วยความจำที่ใช้สำหรับ static swap metadata ได้ประมาณ 30% ซึ่งเป็นหน่วยความจำที่ kernel ต้องสำรองไว้ตามขนาดของอุปกรณ์ swap ของคุณไม่ว่าจะมีการใช้งาน swap หรือไม่ก็ตาม ในเชิงปริมาณอาจดูไม่มากนักสำหรับ swap file ขนาดเล็ก แต่จะเพิ่มขึ้นตามขนาดของ swap ที่คุณกำหนดค่าไว้

MGLRU (multi-generational least recently used ซึ่งเป็นอัลกอริทึมการเรียกคืนหน้าหน่วยความจำแบบใหม่) สามารถตรวจสอบ young flag บนหน้าหน่วยความจำแบบเป็นกลุ่ม (batch) ได้แล้ว แทนที่จะตรวจสอบทีละหน้า ตัวเลขที่เผยแพร่พร้อมกับการเปลี่ยนแปลงนี้ระบุว่าประสิทธิภาพดีขึ้นกว่า 60% บนเซิร์ฟเวอร์ Arm64 แบบ 32-core การประมวลผลแบบกลุ่มให้ผลลัพธ์ที่ดีที่สุดในกรณีที่ต้นทุนต่อหน้าหน่วยความจำสูง ซึ่งเป็นเหตุผลว่าทำไมตัวเลขดังกล่าวจึงมาจากเครื่อง Arm ขนาดใหญ่ หากคุณใช้งาน Arm VPS แทนที่จะเป็น x86 นี่คือการเปลี่ยนแปลงในเวอร์ชัน 7.1 ที่คุณน่าจะสังเกตเห็นได้จากการวัดผลของคุณเอง แม้ว่าจะไม่เห็นผลในระดับเดียวกันบนเครื่องที่มี 2 หรือ 4 core ก็ตาม

นอกจากนี้ ยังมีการเปลี่ยนแปลงอื่น ๆ ได้แก่ การยกเลิกการถ่ายโอนข้อมูลออกจาก memory cgroups ที่กำลังจะถูกลบ, khugepaged ลดการใช้ CPU ในการสแกน และการปรับโครงสร้างครั้งใหญ่ของ maple tree ในส่วนการจัดการโหนดขนาดใหญ่ ทั้งหมดนี้ไม่ใช่สิ่งที่คุณต้องกำหนดค่า แต่เป็นสิ่งที่คุณจะสังเกตเห็นได้จาก system time ที่ลดลงเล็กน้อย

ตัวจัดตารางเวลา: ตัวจัดตารางเวลาเสริม sched_ext และการเปิดใช้งาน FRED เป็นค่าเริ่มต้น

sched_ext ซึ่งเป็นคลาสตัวจัดตารางเวลาแบบขยายได้ที่ช่วยให้คุณเขียนตัวจัดตารางเวลา CPU เป็นโปรแกรม BPF และโหลดใช้งานขณะรันไทม์ได้นั้น ถูกเพิ่มเข้ามาในเวอร์ชัน 6.12 ส่วนเวอร์ชัน 7.1 ได้เพิ่มโครงสร้างหลักสำหรับตัวจัดตารางเวลาเสริม (sub-schedulers) เพื่อให้ในอนาคตกลุ่มควบคุม (control group) สามารถรันภายใต้ตัวจัดตารางเวลาของตนเองได้ โปรดอ่านประโยคนั้นอย่างละเอียด การดำเนินการดังกล่าวยังไม่เสร็จสมบูรณ์ใน 7.1 โดยเฉพาะส่วนของเส้นทางการจัดคิว (enqueue path) ที่ยังขาดอยู่ ดังนั้นนี่จึงเป็นเพียงการวางรากฐานสำหรับรุ่นถัดไป ไม่ใช่ฟีเจอร์ที่คุณสามารถเปิดใช้งานได้ในวันนี้

Intel FRED (flexible return and event delivery) ถูกเปิดใช้งานเป็นค่าเริ่มต้นแล้วบนฮาร์ดแวร์ที่รองรับ FRED เข้ามาแทนที่เส้นทางการส่งเหตุการณ์ (event delivery path) แบบเดิมของ x86 ด้วยเส้นทางที่สะอาดกว่า โดยอยู่ในเคอร์เนลมาตั้งแต่เวอร์ชัน 6.9 ภายใต้การตั้งค่าผ่านอาร์กิวเมนต์การบูต fred=on การเปลี่ยนมาเปิดใช้งานเป็นค่าเริ่มต้นแสดงให้เห็นว่าฮาร์ดแวร์ที่วางจำหน่ายได้รับการทดสอบเพียงพอแล้ว ผลการวัดที่เผยแพร่ออกมาจนถึงปัจจุบัน ซึ่งอยู่ในช่วง 4% ถึง 7% สำหรับภาระงานที่เน้น I/O นั้น มาจากการทดสอบของ Phoronix บนชิปฝั่งไคลเอนต์ ดังนั้นอย่าเพิ่งคาดหวังผลลัพธ์ดังกล่าวบนเซิร์ฟเวอร์จนกว่าคุณจะได้ทดสอบกับภาระงานของคุณเอง

Proxy execution ได้รับการเพิ่มความสามารถในการย้าย donor เพื่อเร่งการทำงานของเจ้าของล็อกระยะไกล (remote lock owner), EEVDF ได้รับการแก้ไขปัญหาเกี่ยวกับค่าความหน่วงติดลบ (negative lag) และแกนหลักของตัวจับเวลาความละเอียดสูง (high-resolution timer core) ได้รับการเขียนใหม่เกือบทั้งหมด การเปลี่ยนแปลงเหล่านี้ส่งผลต่อคุณภาพของความหน่วง (latency) ซึ่งไม่มีไฟล์กำหนดค่าใดที่สามารถปรับแต่งได้

การควบคุมกระบวนการและคอนเทนเนอร์ใหม่ใน clone3()

มีการเพิ่ม flag สามรายการลงใน clone3() ซึ่งแต่ละรายการช่วยปิดช่องโหว่ที่ผู้ดูแลระบบต้องคอยแก้ไขด้วยตนเองมานานหลายปี CLONE_AUTOREAP ทำให้ child process ล้างสถานะตัวเองเมื่อจบการทำงาน เพื่อไม่ให้กลายเป็น zombie ที่รอคอย parent process ซึ่งอาจไม่เคยเรียกใช้ wait() เลย CLONE_NNP จะตั้งค่า no_new_privs ให้กับ child process ตั้งแต่ขณะสร้าง ซึ่งช่วยปิดช่องว่างระหว่างการเรียก clone และการที่ child process ตั้งค่า flag ดังกล่าวด้วยตนเอง CLONE_PIDFD_AUTOKILL จะผูกอายุขัยของ child process ไว้กับ pidfd ที่ส่งคืนให้ parent process หากปิด pidfd นั้น child process จะถูกสั่งฆ่าทันที ทำให้ supervisor ที่หยุดทำงานไปจะไม่ทิ้ง process ลูกให้ค้างอยู่

Mount namespace ได้รับการปรับปรุงในลักษณะเดียวกัน CLONE_EMPTY_MNTNS สำหรับ clone3() และ UNSHARE_EMPTY_MNTNS สำหรับ unshare() จะสร้าง mount namespace ที่ว่างเปล่า แทนที่จะคัดลอก mount ทั้งหมดของ parent process มาตามปกติซึ่ง runtime ต้องคอย unmount ออกในภายหลัง FSMOUNT_NAMESPACE ช่วยให้ fsmount() สามารถวาง filesystem ลงใน namespace ใหม่ได้โดยตรง Container runtime ใช้วิธีประกอบสิ่งเหล่านี้ด้วยตนเองมานับทศวรรษ การทำผ่านคำสั่งเดียวจึงหมายความว่า runtime จะไม่เริ่มต้นจาก namespace ที่เต็มไปด้วย mount ของ host อีกต่อไป

ในส่วนของการทำ virtualisation นั้น guest_memfd รองรับ userfaultfd แล้ว ทำให้ hypervisor สามารถจัดการ page fault ของ guest ได้จาก user space ส่วน Protected KVM บน Arm ได้รับการรองรับ anonymous memory เพิ่มเติม ซึ่งในบันทึกการ merge ระบุว่ายังไม่พร้อมสำหรับการใช้งานจริงในระดับ production

kernel 7.1 จะมาถึงเซิร์ฟเวอร์ของคุณเมื่อใด

Fedora มี kernel เวอร์ชันนี้ใช้งานแล้ว โดย repository ของ Fedora 44 ได้เปลี่ยนมาใช้ kernel ซีรีส์ 7.1 ในช่วงเดือนกรกฎาคมและสิงหาคม 2026 เนื่องจาก Fedora มีนโยบายปรับฐาน kernel ไปยังเวอร์ชัน stable ใหม่ภายในรอบการ release ของตนเอง เช่นเดียวกับ Arch และ openSUSE Tumbleweed ซึ่งเป็นระบบที่เหมาะสำหรับการทดสอบ ไม่ใช่สำหรับรันบริการจริง

ระบบปฏิบัติการอื่นทั้งหมดต้องรอ ซึ่งการรอนี้เป็นไปตามการออกแบบ Debian 13 มาพร้อมกับ 6.12 และจะคงอยู่ที่ 6.12 ตลอดอายุการใช้งานของ release นั้น โดยจะมีการ backport เฉพาะการแก้ไขบั๊กเข้ามาให้ RHEL 10 มาพร้อมกับ 6.12.0 และใช้นโยบายเดียวกัน Ubuntu 26.04 LTS มาพร้อมกับ 7.0 ในเดือนเมษายน 2026 ส่วน Ubuntu 24.04 LTS มี hardware enablement stack (HWE) ซึ่งจะดึง kernel เวอร์ชันใหม่กว่าจาก Ubuntu release ถัดไปมาไว้ใน LTS โดย stack ดังกล่าวอยู่ที่ 6.17 ณ ช่วง point release 24.04.4 และมีกำหนดการจะเปลี่ยนไปใช้ 7.0 ในเวอร์ชัน 24.04.5 วันที่ 27 สิงหาคม 2026 ทั้งนี้ point release ไม่ใช่ Ubuntu เวอร์ชันใหม่ แต่เป็น 24.04 เดิมที่รวมการอัปเดตทั้งหมดไว้ในสื่อติดตั้งใหม่ ดังนั้น สิ่งที่ 24.04.5 เปลี่ยนแปลงบนเซิร์ฟเวอร์ที่คุณ patch อยู่แล้ว จึงมีเพียงแค่ kernel line ของ HWE เท่านั้น

ส่วนที่คนมักเข้าใจผิดคือ HWE stack จะกระโดดไปใช้ kernel เวอร์ชันใดก็ตามที่ interim release ล่าสุดใช้งานอยู่ ดังนั้นมันจึงสามารถข้าม kernel line ของ upstream ไปได้เลย 7.0 อยู่ใน Ubuntu LTS แต่ 7.1 อาจไม่เคยเป็นฐานของ LTS ใดๆ เพราะ interim release ถัดไปจะใช้ kernel line ที่ใหม่กว่า สิ่งที่จะมาถึง LTS ของคุณจาก 7.1 คือการแก้ไขบั๊กที่ถูก backport เข้ามาใน kernel line ที่คุณใช้งานอยู่ ส่วนฟีเจอร์ใหม่ส่วนใหญ่จะไม่ได้ถูกนำเข้ามาด้วย

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

# Ubuntu 24.04 LTS: install the hardware enablement stack
sudo apt update
sudo apt install --install-recommends linux-generic-hwe-24.04
sudo reboot

# Debian 13, with trixie-backports enabled in your apt sources
apt-cache policy linux-image-amd64
sudo apt install -t trixie-backports linux-image-amd64
sudo reboot

หลังจาก reboot ให้ตรวจสอบว่าระบบบูตด้วย kernel เวอร์ชันใด:

uname -r
dpkg -l 'linux-image-*' | grep ^ii
ls /var/run/reboot-required

uname -r ควรแสดง kernel line ใหม่ และ dpkg -l จะแสดง kernel image ทั้งหมดที่ยังคงติดตั้งอยู่ในระบบ หาก uname -r แสดงเวอร์ชันเก่าในขณะที่ dpkg -l แสดงเวอร์ชันใหม่ แสดงว่าแพ็กเกจถูกติดตั้งแล้วแต่ bootloader ไม่ได้เปลี่ยนค่าเริ่มต้น ให้ตรวจสอบรายการในเมนู GRUB การที่ /var/run/reboot-required ปรากฏอยู่หมายความว่ามีการอัปเกรด kernel แต่ระบบยังไม่ได้ reboot ซึ่งเป็นสาเหตุที่พบบ่อยที่สุดที่ทำให้เซิร์ฟเวอร์ที่ patch แล้วยังคงรันโค้ดที่มีช่องโหว่อยู่

คุณควรไล่ตามเวอร์ชัน 7.1 บน VPS ที่ใช้งานจริงหรือไม่

ไม่ควร และเหตุผลไม่ใช่เพียงเพราะความระมัดระวังเกินเหตุ Kernel ของ Distribution มาพร้อมกับสัญญาการสนับสนุน Canonical, Red Hat, SUSE และ Debian ต่างทำ backport แพตช์ความปลอดภัยเข้าสู่เวอร์ชันที่ตรึงไว้ (frozen line) และทดสอบกับ userspace ที่มาพร้อมกัน แต่การใช้ Mainline kernel จากคลังเก็บของบุคคลที่สามหรือการคอมไพล์เอง จะทำให้คุณได้ฟีเจอร์ใหม่แต่สูญเสียการสนับสนุนดังกล่าวไป เพราะไม่มีใครทำ backport แพตช์ให้บิลด์ของคุณ คุณจะกลายเป็นผู้ดูแล Kernel ด้วยตัวเอง

ข้อยกเว้นนั้นมีจริงแต่จำกัดมาก เช่น ฮาร์ดแวร์ที่ Kernel เวอร์ชันเก่าไม่รองรับ หรือการเปลี่ยนแปลงด้านประสิทธิภาพที่คุณวัดผลได้จากภาระงานของคุณเองและต้องการมันมากพอที่จะรับผลกระทบที่ตามมา สำหรับ VPS ข้อแรกแทบไม่เกิดขึ้นเลยเพราะฮาร์ดแวร์ที่คุณเห็นเป็นแบบเสมือน สำหรับกรณีอื่นทั้งหมด ให้รักษา Kernel ของ Distribution ให้เป็นปัจจุบันและรีบูตเมื่อระบบร้องขอ หากการอัปเกรด Distribution อยู่ในแผนงานของคุณอยู่แล้ว การ ย้ายจาก Ubuntu 24.04 ไปยัง 26.04 จะทำให้คุณขยับจาก 6.8 ไปเป็น 7.0 ในขั้นตอนเดียว ซึ่งเป็นการก้าวกระโดดที่ใหญ่กว่าการอัปเดตแพ็กเกจ Kernel เพียงตัวเดียวจะให้คุณได้

FAQ

ฉันจะตรวจสอบได้อย่างไรว่า VPS ของฉันกำลังรัน Linux kernel เวอร์ชันใด?

ให้รันคำสั่ง uname -r ซึ่งจะแสดงผลลัพธ์ในรูปแบบคล้ายกับ 6.8.0-79-generic ตัวเลขก่อนขีดแรกคือสายการพัฒนาหลัก (upstream line) ที่ distribution ของคุณใช้เป็นฐาน ส่วนตัวเลขหลังขีดคือหมายเลข build ของ distribution เอง ซึ่งรวมการแก้ไขที่ทำแบบ backport ไว้แล้ว จากนั้นให้รัน systemd-detect-virt หากแสดงผลเป็น lxc หรือ openvz แสดงว่าคุณกำลังใช้งานบน container virtualisation ซึ่งเป็นการแชร์ kernel ร่วมกับโฮสต์และคุณไม่สามารถเปลี่ยน kernel เองได้ แต่หากแสดงผลเป็น kvm แสดงว่าคุณบูตด้วย kernel image ของคุณเอง และคุณต้องเป็นผู้จัดการการอัปเกรดด้วยตนเอง

Linux 7.1 เป็น kernel รุ่น longterm support หรือไม่?

ไม่เป็น ณ วันที่ 11 สิงหาคม 2026 สายการพัฒนาแบบ longterm ที่ระบุไว้บน kernel.org ได้แก่ 6.18, 6.12, 6.6, 6.1, 5.15 และ 5.10 โดยไม่มี 7.1 รวมอยู่ด้วย มันเป็นเพียงรุ่น stable ปกติ ซึ่งสายการพัฒนาแบบ stable จะถูกยกเลิกหลังจากรุ่น mainline ถัดไปออกวางจำหน่าย หากคุณต้องการ kernel ที่มีการแก้ไขต่อเนื่องมาหลายปีและจะมีการแก้ไขต่อไปอีกหลายปี นั่นคือสิ่งที่ kernel ของ distribution ที่คุณใช้อยู่นั้นเป็นอยู่แล้ว

Ubuntu หรือ Debian จะปล่อย kernel 7.1 ออกมาเมื่อใด?

อาจจะไม่ปล่อยออกมาเป็นค่าเริ่มต้น Debian 13 จะใช้ 6.12 ตลอดอายุการใช้งานของรุ่น และ RHEL 10 ก็ใช้ 6.12.0 เช่นกัน Ubuntu 26.04 LTS มาพร้อมกับ 7.0 และ stack การรองรับฮาร์ดแวร์ (hardware enablement stack) ของ Ubuntu จะข้ามไปยัง kernel ใดก็ตามที่รุ่น interim ใหม่ล่าสุดใช้งานอยู่ ดังนั้นจึงอาจข้ามสายการพัฒนา upstream ไปเลยก็ได้ Ubuntu 24.04 LTS มีกำหนดการอัปเกรด HWE kernel เป็น 7.0 ในรุ่น point release 24.04.5 วันที่ 27 สิงหาคม 2026 การแก้ไขจาก 7.1 จะถูกส่งถึงคุณในรูปแบบ backports เข้าสู่สายการพัฒนาที่เก่ากว่า แต่ฟีเจอร์ใหม่ๆ มักจะไม่ถูกรวมเข้ามาด้วย

มีอะไรใน Linux 7.1 ที่สำคัญต่อ virtual private server บ้าง?

มี 4 รายการ ได้แก่ Hardware queue leasing ที่ช่วยให้ container สามารถใช้คิว NIC จริงหนึ่งคิวสำหรับ AF_XDP ได้ด้วยความเร็วระดับ native, เฟสที่สามของการปรับปรุง swap ที่ยกเลิก static swap map และลด metadata ที่ kernel เก็บไว้สำหรับอุปกรณ์ swap ของคุณลงถึง 30%, MGLRU ที่สามารถตรวจสอบ page young flags เป็นชุดๆ ซึ่งให้ประสิทธิภาพเพิ่มขึ้นอย่างมากบนเซิร์ฟเวอร์ Arm แบบหลายคอร์ และ clone3() ที่เพิ่ม CLONE_AUTOREAP, CLONE_NNP และ CLONE_PIDFD_AUTOKILL เข้ามา ซึ่งช่วยให้การดูแลกระบวนการลูก (child processes) ปลอดภัยยิ่งขึ้น นอกจากนี้ยังมีข้อมูลการป้องกัน T10 ในระดับไฟล์ระบบเพิ่มเข้ามาด้วย แต่ดิสก์เสมือนมักไม่เปิดเผย metadata ความสมบูรณ์ของข้อมูลที่จำเป็นต้องใช้

การอัปเกรด kernel จะทำให้ VPS ของฉันพังหรือไม่?

ความล้มเหลวที่พบบ่อยมักเกิดขึ้นตอนบูต การใช้ /boot จนเต็มพื้นที่ทำให้ update-initramfs ล้มเหลวด้วยข้อผิดพลาด No space left on device ระหว่างการติดตั้ง ส่งผลให้แพ็กเกจถูกกำหนดค่าไม่สมบูรณ์ ให้ล้าง kernel เก่าออกด้วย sudo apt autoremove --purge แล้วติดตั้งใหม่ โมดูลภายนอก (out-of-tree modules) ที่สร้างขึ้นสำหรับ kernel เก่าจะหยุดโหลด ดังนั้นสิ่งที่จัดการโดย DKMS จะต้องถูกสร้างใหม่ และหากการสร้างใหม่ล้มเหลว ระบบจะไม่แจ้งเตือนจนกว่าจะพบว่าโมดูลหายไปในขณะรันไทม์ และหาก uname -r ยังคงแสดงเวอร์ชันเก่าหลังจากรีบูต ในขณะที่ dpkg -l แสดงรายการ image ใหม่ แสดงว่าการติดตั้งไม่ได้มีปัญหา แต่ bootloader ยังไม่ได้เปลี่ยนค่าเริ่มต้นให้ชี้ไปยังเวอร์ชันใหม่