Linux kernel 7.1 มีอะไรใหม่สำหรับเซิร์ฟเวอร์และ VPS

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

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

มีคำตอบที่สองที่คุณจำเป็นต้องทราบก่อน Linux kernel 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 บน virtual machine แบบเต็ม ซึ่งคุณสามารถบูตอิมเมจเคอร์เนลของคุณเองได้และการอัปเกรดถือเป็นการอัปเกรดจริง แต่จะแสดงผลเป็น lxc หรือ openvz บนระบบ virtualisation แบบคอนเทนเนอร์ ซึ่งมีการแชร์เคอร์เนลร่วมกับโฮสต์ ในแผนการใช้งานแบบคอนเทนเนอร์ 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 ก็ต่อเมื่ออุปกรณ์มีการลงทะเบียนรองรับ integrity เท่านั้น ข้อผิดพลาดดังกล่าวเป็นผลลัพธ์ปกติในกรณีนี้ ไม่ใช่ความผิดพลาดของระบบ หากคุณต้องการทราบว่าดิสก์ของคุณคืออะไรก่อนที่จะอ่านรายละเอียดเกี่ยวกับฟีเจอร์การจัดเก็บข้อมูลเพิ่มเติม การตรวจสอบว่าดิสก์ VPS เป็น NVMe จริงหรือไม่ คือขั้นตอนแรก และ ช่องว่างระหว่าง NVMe กับ SATA SSD บน VPS จะอธิบายว่าเหตุใดคำตอบนี้จึงส่งผลต่อตัวเลขประสิทธิภาพของคุณ

Btrfs ได้รับการแก้ไขปัญหา copy-on-write amplification ในสภาวะที่หน่วยความจำมีจำกัด รวมถึงการปรับเปลี่ยนที่ช่วยเพิ่มความเร็วในการล้าง extent แรกในช่วงที่ถูกติดตาม ซึ่งรายงานว่ามี throughput เพิ่มขึ้น 10% ในภาระงานตัวอย่างที่ระบุไว้ในการรวมโค้ด (merge) และการทำงานในสถานะ shutdown ไม่ถูกระบุว่าเป็น experimental อีกต่อไป XFS ปรับปรุงการล้างข้อมูลช่วงศูนย์ (zero range flushing) และการค้นหาผ่าน 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 จะต้องคอมไพล์รวมไว้ในเคอร์เนลโดยตรง การเปลี่ยนแปลงรายการหลังนี้จะไม่ส่งผลกระทบต่อ kernel ของดิสทริบิวชันทั่วไป เนื่องจากดิสทริบิวชันสำหรับเซิร์ฟเวอร์ส่วนใหญ่ได้คอมไพล์ IPv6 รวมไว้ในเคอร์เนลอยู่แล้ว

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

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

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

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

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

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

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

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

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

มีการเพิ่ม flag 3 รายการให้กับ clone3() ซึ่งแต่ละรายการช่วยอุดช่องโหว่ที่ระบบ supervisor เคยต้องใช้วิธีแก้ปัญหาด้วยตนเองมานานหลายปี 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() สามารถวางระบบไฟล์ลงใน 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 มีนโยบาย rebase kernel ไปยังรุ่น stable ใหม่ภายในรอบการปล่อยเวอร์ชัน ส่วน Arch และ openSUSE Tumbleweed ก็ได้รับ kernel เวอร์ชันนี้ด้วยเหตุผลเดียวกัน เครื่องเหล่านี้เหมาะสำหรับการทดสอบ ไม่ใช่สำหรับรันบริการจริง

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

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

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

# 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

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

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

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

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

ไม่ควร และเหตุผลไม่ใช่เพียงเพราะความระมัดระวังเกินเหตุ Kernel ของ Distribution มาพร้อมกับสัญญาการสนับสนุน Canonical, Red Hat, SUSE และ Debian ต่างทำ backport แพตช์ความปลอดภัยเข้าสู่เวอร์ชันที่ตรึงไว้ (frozen line) และทดสอบกับ userspace ที่มาพร้อมกัน ส่วน 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 ออกมาแล้ว และสำหรับ Ubuntu hardware enablement stack นั้นจะข้ามไปใช้ kernel เวอร์ชันใดก็ตามที่รุ่น interim ใหม่ล่าสุดใช้งานอยู่ ดังนั้นจึงอาจข้ามสายการพัฒนา upstream ไปเลยก็ได้ Ubuntu 24.04 LTS มีกำหนดการอัปเดต HWE kernel เป็น 7.0 ในรุ่น point release 24.04.5 วันที่ 27 สิงหาคม 2026 การแก้ไขจาก 7.1 จะถูกส่งถึงคุณในรูปแบบ backport เข้าสู่ kernel รุ่นเก่า แต่ฟีเจอร์ใหม่ๆ มักจะไม่ถูกรวมเข้ามาด้วย

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

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

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

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