ติดตั้งและลงนามโมดูลเคอร์เนลแบบกำหนดเองบน SLES 15 Secure Boot

ไดรเวอร์จากผู้พัฒนาภายนอกบน SUSE Linux Enterprise Server 15 อาจคอมไพล์ได้อย่างถูกต้อง แต่โหลดไม่สำเร็จโดยแสดงข้อความ “คีย์ที่จำเป็นไม่พร้อมใช้งาน” หรือ “คีย์ถูกปฏิเสธโดยบริการ” เมื่อ UEFI Secure Boot บังคับใช้ลายเซ็นโมดูล วิธีแก้ไขคือการลงนามโมดูลเคอร์เนลแบบกำหนดเองด้วยใบรับรองที่เชื่อถือได้ ลงทะเบียนใบรับรองนั้นผ่านการจัดการ Machine Owner Key (MOK) แล้วโหลดโมดูลตามปกติ โดยไม่ต้องปิดใช้งาน Secure Boot

ขั้นตอนนี้นั้นตั้งอยู่บนสมมติฐานของระบบ SLES 15 UEFI มาตรฐานที่ใช้ SUSE shim, kernel-defaultเคอร์เนล, สิทธิ์การเข้าถึงของผู้ดูแลระบบ และแหล่งที่มาที่เชื่อถือได้สำหรับไดรเวอร์ของคุณ ขั้นตอนนี้จะกล่าวถึง.koโมดูลที่กำหนดเอง ไม่ใช่การลงนามเคอร์เนลทดแทนหรือการเปลี่ยนแปลงคีย์แพลตฟอร์มเฟิร์มแวร์ ตัวอย่างต่างๆ เป็นไปตามแบบจำลองการจัดการ SLES 15 SP6/SP7 โปรดตรวจสอบความแตกต่างของแพ็กเกจและเวอร์ชันเคอร์เนลใน Service Pack ที่ติดตั้งของคุณ

1. ตรวจสอบ Secure Boot และเคอร์เนลที่กำลังทำงานอยู่ก่อน

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

uname -r
mokutil --sb-state
ls -ld "/lib/modules/$(uname -r)/build"
หน้าต่างเทอร์มินัลแสดงคำสั่ง uname -r, สถานะการบูตแบบปลอดภัยของ mokutil และการตรวจสอบไดเร็กทอรีการสร้างเคอร์เนลที่กำลังทำงานอยู่
ตรวจสอบเวอร์ชันเคอร์เนลที่ใช้งานอยู่และสถานะ Secure Boot ก่อนติดตั้งหรือลงนามไดรเวอร์

หากmokutilรายงานว่าเปิดใช้งาน Secure Boot แล้ว ลายเซ็นที่ไม่น่าเชื่อถืออาจเป็นสาเหตุหนึ่งที่ทำให้การโหลดคีย์ล้มเหลว หากปิดใช้งานอยู่ ให้ตรวจสอบสาเหตุอื่นๆ ก่อนสร้างคีย์ การบังคับใช้ลายเซ็นเคอร์เนลอย่างชัดเจนก็อาจมีความสำคัญเช่นกัน ตรวจสอบบันทึกเคอร์เนลหลังจากโหลดล้มเหลวเพื่อดูข้อความปฏิเสธที่แท้จริง

sudo journalctl -k -b --no-pager | tail -n 50

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

modinfo -F name /path/to/mydriver.ko
modinfo -F vermagic /path/to/mydriver.ko
หน้าต่างเทอร์มินัลแสดงรายการ modinfo ตัวอย่างสำหรับไดรเวอร์เคอร์เนลภายนอกและเส้นทางเครื่องมือลงนามเคอร์เนล
ตรวจสอบเมตาเดต้าของโมดูล โดยเฉพาะอย่างยิ่ง Vermagic แทนที่จะสันนิษฐานว่าไฟล์ .ko ทุกไฟล์จะเข้ากันได้กับ SLES 15

2. ใช้แพ็คเกจไดรเวอร์ที่รองรับ หรือสร้างโมดูลที่เข้ากันได้

ขั้นแรก ให้ขอแพ็คเกจโมดูลเคอร์เนล (KMP) ที่ลงนามแล้วและเข้ากันได้กับ SLES จากผู้จำหน่ายฮาร์ดแวร์หรือซอฟต์แวร์ วิธีนี้ดีกว่าการติดตั้งไบนารีด้วยตนเอง เนื่องจากผู้จำหน่ายอาจมีวิธีการจัดการการอัปเดตเคอร์เนลและกระบวนการลงทะเบียนใบรับรองที่บันทึกไว้ อย่างไรก็ตาม ลายเซ็นของผู้จำหน่ายไม่ได้ได้รับการยอมรับโดยอัตโนมัติในทุกเครื่องที่ใช้ Secure Boot

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

sudo zypper install gcc make openssl mokutil kernel-devel kernel-default-devel
rpm -q kernel-default-devel kernel-devel
readlink -f "/lib/modules/$(uname -r)/build"
เทอร์มินัลแบบ SLES แสดงการติดตั้ง zypper สำหรับการพัฒนาเคอร์เนลและข้อกำหนดเบื้องต้นในการลงนาม
ติดตั้งแพ็กเกจพัฒนาเคอร์เนลและเครื่องมือเข้ารหัสลับที่เกี่ยวข้องก่อนใช้งานโมดูลที่กำหนดเอง

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

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

cd /path/to/driver-source
make -C "/lib/modules/$(uname -r)/build" M="$PWD" modules
หน้าต่างเทอร์มินัลแสดงคำสั่ง kbuild make ที่กำลังคอมไพล์โมดูลเคอร์เนลภายนอกกับเคอร์เนล SLES ที่กำลังทำงานอยู่
ใช้โครงสร้างการสร้างเคอร์เนลและไดเร็กทอรีซอร์สโค้ดของไดรเวอร์เพื่อสร้างไฟล์ .ko ที่ตรงกัน

ข้ามขั้นตอนการคอมไพล์หากคุณมีไฟล์ที่เข้ากันได้.koจากผู้จำหน่ายที่เชื่อถือได้อยู่แล้ว ห้ามบังคับโหลดโมดูลที่มีลายเซ็นไม่ถูกต้องvermagicเพราะลายเซ็นไม่สามารถแก้ไขไบนารีที่ไม่เข้ากันได้

3. สร้างคีย์ลงนามและลงนามในโมดูลที่ติดตั้งแล้ว

สร้างคีย์ RSA และใบรับรอง X.509 เฉพาะในไดเร็กทอรีที่เข้าถึงได้เฉพาะผู้ใช้ root เท่านั้น ใบรับรองสาธารณะจะถูกลงทะเบียน ส่วนคีย์ส่วนตัวจะต้องได้รับการปกป้อง เนื่องจากผู้ที่ควบคุมคีย์ส่วนตัวนี้สามารถลงนามในโมดูลเพิ่มเติมที่เครื่องนี้อาจเชื่อถือได้

sudo -i
umask 077
mkdir -p /root/module-signing
cd /root/module-signing
openssl req -new -x509 -newkey rsa:3072 -sha256 -days 3650 -nodes \
  -subj "/CN=SLES Custom Module Signing/" \
  -keyout MOK.priv -out MOK.pem
openssl x509 -in MOK.pem -outform DER -out MOK.der
chmod 600 MOK.priv
หน้าต่างเทอร์มินัลแสดงคำสั่ง OpenSSL ที่สร้างคีย์ส่วนตัว RSA ในเครื่องและใบรับรองการลงนามโมดูล X.509
สร้างคู่คีย์ลงนามโมดูลแยกต่างหาก และเก็บคีย์ส่วนตัวไว้เฉพาะผู้ดูแลระบบเท่านั้น

-nodesตัวอย่างง่ายๆ คือ การสร้างคีย์ส่วนตัวที่ไม่เข้ารหัส สำหรับกระบวนการลงนามในระบบการผลิต ควรใช้คีย์ที่เข้ารหัสและได้รับการปกป้องอย่างเหมาะสม หรือบริการลงนามภายนอกภายใต้นโยบายความปลอดภัยของคุณ ระยะเวลาใช้งานสิบปีที่แสดงไว้ที่นี่เป็นเพียงตัวอย่าง ไม่ใช่คำแนะนำเกี่ยวกับอายุการใช้งานของใบรับรองสำหรับองค์กร

คัดลอกโมดูลที่เสร็จสมบูรณ์แล้วไปยังไดเร็กทอรีโมดูลของเคอร์เนลที่กำลังทำงานอยู่ ลงชื่อในไฟล์ที่ติดตั้งอย่างถูกต้องหลังจากทำการบรรจุ ตัดแต่ง หรือแก้ไขไฟล์อื่นๆ แล้วmydriverแทนที่ `<basename>` และพาธของมันด้วยชื่อพื้นฐานและตำแหน่งจริงของโมดูล

install -D -m 0644 /path/to/mydriver.ko \
  "/lib/modules/$(uname -r)/extra/mydriver.ko"
SIGN_FILE="$(readlink -f /lib/modules/$(uname -r)/build)/scripts/sign-file"
test -x "$SIGN_FILE" || echo "Locate the sign-file binary for this kernel"
"$SIGN_FILE" sha256 /root/module-signing/MOK.priv \
  /root/module-signing/MOK.der \
  "/lib/modules/$(uname -r)/extra/mydriver.ko"
modinfo -F signer "/lib/modules/$(uname -r)/extra/mydriver.ko"
หน้าต่างเทอร์มินัลแสดงตัวอย่างการเรียกใช้ไฟล์ลงนามและการตรวจสอบตัวลงนาม modinfo สำหรับโมดูลเคอร์เนล
ใส่ลายเซ็นลงในไฟล์ .ko ที่ติดตั้งแล้ว และตรวจสอบช่องผู้ลงนามก่อนที่จะโหลดไฟล์นั้น

หากsign-fileไม่มีเครื่องมือดังกล่าวในเส้นทางนั้น ให้ค้นหาเครื่องมือที่มาพร้อมกับไฟล์สร้างเคอร์เนลที่ตรงกันแทนที่จะคัดลอกเวอร์ชันที่ไม่เกี่ยวข้อง การแสดงชื่อผู้ลงนามหมายความว่าไฟล์นั้นมีข้อมูลเมตาของลายเซ็น แต่ไม่ได้หมายความว่าผู้ลงนามนั้นได้รับการลงทะเบียนแล้ว ห้ามลบหรือแก้ไขโมดูลหลังจากลงนามแล้ว

4. ลงทะเบียนใบรับรองสาธารณะโดยใช้ MOK

นำเข้าใบรับรองสาธารณะในรูปแบบ DER — ไม่ใช่MOK.priv— และตั้งรหัสผ่านการลงทะเบียนครั้งเดียวตามที่ร้องขอโดยmokutilจัดเตรียมการเข้าถึงคอนโซลก่อนรีบูต การอนุญาตจะเกิดขึ้นในอินเทอร์เฟซ MokManager ในระหว่างการบูต ไม่ใช่ในเชลล์ SSH

mokutil --import /root/module-signing/MOK.der
mokutil --list-new
reboot
เมนูบูตสีน้ำเงินสไตล์ MokManager โดยมีตัวเลือก Enroll MOK เด่นอยู่เหนือตัวเลือก Machine Owner Key อื่นๆ
ในเมนูบูต UEFI ให้เลือก Enroll MOK และยืนยันการลงทะเบียนใบรับรองที่ร้องขอ

ระหว่างการบูตครั้งถัดไป ให้เลือกEnroll MOKทำตามคำแนะนำการยืนยัน ป้อนรหัสผ่านแบบใช้ครั้งเดียว และดำเนินการบูตต่อไป ลักษณะของเมนูจะขึ้นอยู่กับเวอร์ชันของเฟิร์มแวร์และชิม การกลับไปยัง Linux โดยไม่ยืนยันการลงทะเบียนจะทำให้ใบรับรองใหม่ไม่น่าเชื่อถือ

หลังจากบูตเครื่องแล้ว ให้ตรวจสอบว่าได้ลงทะเบียนใบรับรองที่ระบุเรียบร้อยแล้ว:

sudo mokutil --test-key /root/module-signing/MOK.der
sudo mokutil --list-enrolled

5. โหลดโมดูลที่ลงนามแล้วและแยกข้อผิดพลาดที่เหลืออยู่

อัปเดตเมตาเดต้าการพึ่งพาของโมดูลและโหลดโมดูลโดยใช้ชื่อ ไม่ใช่เส้นทางไฟล์แบบเต็มmodprobeแก้ไขปัญหาการพึ่งพาและเคารพการกำหนดค่าโมดูลมาตรฐาน

sudo depmod -a
sudo modprobe mydriver
lsmod | grep -w mydriver
modinfo -F signer mydriver
หน้าต่างเทอร์มินัลแสดงคำสั่ง modprobe, lsmod และ kernel-log ที่ใช้ในการตรวจสอบโมดูลที่ลงนามแล้ว
ตรวจสอบให้แน่ใจว่าโมดูลที่ลงนามแล้วปรากฏอยู่ในรายการโมดูลที่โหลดแล้ว และตรวจสอบบันทึกเคอร์เนลเพื่อหาข้อผิดพลาด

หากการโหลดล้มเหลว ให้เลือกวิธีการแก้ไขที่สอดคล้องกับหลักฐานที่พบ:

  • คีย์ไม่ถูกต้องหรือคีย์ที่ต้องการไม่พร้อมใช้งาน:ลองใหม่อีกครั้งmokutil --test-key; ตรวจสอบว่าไฟล์ที่คุณติดตั้งเป็นไฟล์ที่ลงนามแล้วหรือไม่ และตรวจสอบว่าการอัปเดตไดรเวอร์ได้แทนที่ไฟล์นั้นหรือไม่
  • รูปแบบโมดูลไม่ถูกต้อง:เปรียบเทียบmodinfo -F vermagicกับuname -rไฟล์ต้นฉบับ สร้างใหม่สำหรับเคอร์เนลที่ใช้งานอยู่ และตรวจสอบสถาปัตยกรรม CPU
  • สัญลักษณ์ที่ไม่รู้จักหรือส่วนประกอบที่จำเป็นขาดหายไป:ตรวจสอบjournalctl -k -bโมดูลที่ผู้จำหน่ายกำหนด และ ABI ของเคอร์เนล การเพิ่มลายเซ็นอื่นจะไม่สามารถแก้ไขสัญลักษณ์ที่ขาดหายไปได้

สำหรับไดรเวอร์จัดเก็บข้อมูลหรือเครือข่ายที่สำคัญต่อการบูตระบบ ให้ทดสอบบนระบบที่ไม่ใช่ระบบใช้งานจริงก่อน และตรวจสอบให้แน่ใจว่ามีคอนโซลกู้คืนให้ใช้งานได้ กำหนดค่าการโหลดอัตโนมัติเฉพาะเมื่อไดรเวอร์ทำงานได้อย่างน่าเชื่อถือแล้วเท่านั้น เอกสารของ SUSE /etc/modules-load.d/สำหรับโมดูลที่ไม่โหลดตามปกติเมื่อตรวจพบอุปกรณ์นั้นมีไว้เพื่อกำหนดค่าการโหลดอัตโนมัติ

ตรวจสอบผลลัพธ์หลังจากรีบูตเครื่อง

หากการโหลดค้างเป็นปัญหา ให้รีบูตอีกครั้งในช่วงเวลาการบำรุงรักษา ตรวจสอบให้แน่ใจว่า Secure Boot ยังคงเปิดใช้งานอยู่ คีย์สาธารณะได้รับการลงทะเบียนแล้ว โมดูลมีอยู่ และเคอร์เนลไม่รายงานข้อผิดพลาดในการตรวจสอบหรือความเข้ากันได้ใหม่ สร้างใหม่หรือติดตั้งใหม่และลงนามในเวอร์ชันอัปเดต.koหลังจากอัปเกรดเคอร์เนลหรือไดรเวอร์ของผู้จำหน่าย

mokutil --sb-state
sudo mokutil --test-key /root/module-signing/MOK.der
modinfo -F signer mydriver
lsmod | grep -w mydriver
sudo journalctl -k -b --no-pager | tail -n 30

เอกสารอ้างอิงหลัก: SUSE SLES 15 SP6: UEFI และรหัสเจ้าของเครื่อง ; SUSE: การจัดการโมดูลเคอร์เนล ; เคอร์เนล Linux: ระบบลงนามโมดูล ; เคอร์เนล Linux: การสร้างโมดูลภายนอกคู่มือการดูแลระบบ SLES 15 SP6 ได้รับการอัปเดตเมื่อวันที่ 17 กันยายน 2026; พฤติกรรมของคำสั่งสำหรับโปรแกรมติดตั้งไดรเวอร์ของบุคคลที่สามและเคอร์เนลเวอร์ชันที่ไม่ใช่ค่าเริ่มต้นจะต้องได้รับการยืนยันจากผู้ดูแลระบบ

ฝากความเห็น

การตั้งค่า KVM ใน SLES 15: กำหนดให้ VM ที่เลือกเริ่มต้นทำงานเมื่อบูตเครื่อง

การตั้งค่า KVM ใน SLES 15: กำหนดให้ VM ที่เลือกเริ่มต้นทำงานเมื่อบูตเครื่อง

ติดตั้งเครื่องมือ SLES 15 KVM และ libvirt เปิดใช้งานบริการโฮสต์ที่ถูกต้อง และกำหนดค่าเครื่องเสมือนที่เลือกให้เริ่มต้นทำงานหลังจากรีบูตเครื่อง

ทำการสำรองข้อมูล Nextcloud อย่างสม่ำเสมอโดยอัตโนมัติด้วย Restic และ Cron

ทำการสำรองข้อมูล Nextcloud อย่างสม่ำเสมอโดยอัตโนมัติด้วย Restic และ Cron

สำรองข้อมูลไฟล์ของ Nextcloud และ MariaDB ไปพร้อมกัน กำหนดเวลาสร้างสแนปช็อต Restic ที่เข้ารหัสด้วย cron และตรวจสอบการกู้คืนโดยไม่ต้องเสี่ยงต่อเซิร์ฟเวอร์ที่ใช้งานอยู่

สำรองข้อมูลและกู้คืนกล่องจดหมาย Zimbra CE โดยใช้การส่งออก TGZ

สำรองข้อมูลและกู้คืนกล่องจดหมาย Zimbra CE โดยใช้การส่งออก TGZ

ส่งออกกล่องจดหมาย Zimbra Community Edition ส่วนบุคคล ตรวจสอบความถูกต้องของการสำรองข้อมูล TGZ และกู้คืนรายการที่หายไปโดยไม่เขียนทับอีเมลที่มีอยู่

อนุญาตให้ผู้ใช้ที่ได้รับอนุญาตสร้างห้อง Jitsi ด้วยการลงชื่อเข้าใช้ Keycloak

อนุญาตให้ผู้ใช้ที่ได้รับอนุญาตสร้างห้อง Jitsi ด้วยการลงชื่อเข้าใช้ Keycloak

อนุญาตเฉพาะบัญชีที่ได้รับอนุมัติเท่านั้นให้เริ่มห้องประชุม Jitsi Meet โดยใช้ Keycloak และการตรวจสอบสิทธิ์ด้วยโทเค็น ในขณะที่ยังคงเปิดให้ผู้เยี่ยมชมเข้าร่วมได้เมื่อจำเป็น

ซิงค์ผู้ใช้ Active Directory กับ ONLYOFFICE DocSpace ผ่าน LDAP

ซิงค์ผู้ใช้ Active Directory กับ ONLYOFFICE DocSpace ผ่าน LDAP

เชื่อมต่อ ONLYOFFICE DocSpace กับ Active Directory หรือ OpenLDAP นำเข้าผู้ใช้และกลุ่มได้อย่างปลอดภัย แมปฟิลด์บัญชี และกำหนดเวลาการซิงโครไนซ์ที่เชื่อถือได้

เพิ่มฟอนต์ลงใน ONLYOFFICE Document Server: Docker เทียบกับ Linux

เพิ่มฟอนต์ลงใน ONLYOFFICE Document Server: Docker เทียบกับ Linux

ติดตั้งฟอนต์แบบกำหนดเองใน ONLYOFFICE Document Server เปรียบเทียบการเมานต์ Docker แบบถาวรกับสำเนาโดยตรง สร้างรายการฟอนต์ใหม่ และตรวจสอบผลลัพธ์

วาง ONLYOFFICE Docs ไว้หลัง HAProxy โดยไม่ทำให้การแก้ไขเอกสารหยุดชะงัก

วาง ONLYOFFICE Docs ไว้หลัง HAProxy โดยไม่ทำให้การแก้ไขเอกสารหยุดชะงัก

ตั้งค่า HAProxy สำหรับ HTTPS, การส่งต่อส่วนหัว, การหมดเวลาของ WebSocket และการตรวจสอบสถานะสำหรับ ONLYOFFICE Docs จากนั้นตรวจสอบการแก้ไขและการบันทึก

ติดตั้งและลงนามโมดูลเคอร์เนลแบบกำหนดเองบน SLES 15 Secure Boot

ติดตั้งและลงนามโมดูลเคอร์เนลแบบกำหนดเองบน SLES 15 Secure Boot

โหลดโมดูลเคอร์เนล SLES 15 แบบกำหนดเองโดยไม่ต้องปิดใช้งาน Secure Boot จับคู่เคอร์เนลที่กำลังทำงานอยู่ ลงนามในไฟล์ .ko ลงทะเบียนคีย์ MOK และตรวจสอบการโหลด

การส่งต่อ Syslog ของ SLES อย่างปลอดภัยด้วย rsyslog และ Mutual TLS

การส่งต่อ Syslog ของ SLES อย่างปลอดภัยด้วย rsyslog และ Mutual TLS

ส่งบันทึกระบบ SLES ไปยังตัวเก็บรวบรวม rsyslog ระยะไกลผ่าน TLS ที่มีการตรวจสอบสิทธิ์ พร้อมด้วยการตรวจสอบใบรับรอง การบัฟเฟอร์เมื่อระบบขัดข้อง และการทดสอบการส่งมอบ

วิธีการบูต Ubuntu Server เข้าสู่โหมดฉุกเฉิน: คู่มือการกู้คืนทีละขั้นตอน

วิธีการบูต Ubuntu Server เข้าสู่โหมดฉุกเฉิน: คู่มือการกู้คืนทีละขั้นตอน

ตรวจสอบและวินิจฉัยโหมดฉุกเฉินของ Ubuntu Server อย่างปลอดภัย อ่านบันทึกการบูต ตรวจสอบการเมานต์รูทและ fstab ซ่อมแซมหน่วยที่ล้มเหลว จัดการข้อผิดพลาดของระบบไฟล์ และตรวจสอบการรีบูตที่สะอาดหมดจด