แก้ไขแล้ว: 'ไม่สามารถเริ่มต้นเลเยอร์การตรวจสอบ: การอนุญาตถูกปฏิเสธ' ข้อผิดพลาดใน libvirt-bin หลังจากอัปเกรด Ubuntu Server 14.04 เป็น Ubuntu Server 16.04

วันนี้ฉันตัดสินใจที่จะดำเนินการต่อและอัปเกรดเซิร์ฟเวอร์ของฉันจาก Ubuntu 14.04 เป็น 16.04 ไม่แนะนำให้ทำเช่นนี้บนเซิร์ฟเวอร์ที่ใช้งานจริงเนื่องจากมีปัญหามากมายที่อาจผิดพลาดได้ แนวทางปฏิบัติที่ดีที่สุดมักจะระบุว่าการหมุนเซิร์ฟเวอร์อื่นเป็นการทดแทนหรือเซิร์ฟเวอร์ชั่วคราวเป็นวิธีที่ปลอดภัยที่สุด ที่กล่าวมาใครไม่ชอบลองสิ่งที่ไม่ควรทำ

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

การทดลองครั้งแรกคือการแก้ไขปัญหาด้วย sudo dpkg –configure -a ไม่มีโชค ฉันยังพยายามใช้ตัวแก้ไขอัตโนมัติแบบถนัดจากนั้นล้างและติดตั้งใหม่ ยังไม่มีโชค

เพื่อไปถึงต้นตอของปัญหาแทนที่จะพยายามเดาอย่างโง่ ๆ ว่าฉันวิ่ง

sudo journalctl -xe

pubg ค้างอยู่ที่หน้าจอโหลด

ดังที่แสดงไว้ด้านบนข้อผิดพลาดใน apparmor ทำให้ libvirt-bin ไม่ได้รับอนุญาตให้ทำงานอีกต่อไปเนื่องจากไม่ได้กำหนดค่าไว้อีกต่อไป (ตลกดีฉันสาบานได้ว่าฉันบอกไปแล้ว)

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

sudo apparmor_parser –purge-cache

ต่อไปเราจะลบกฎที่ป้องกันไม่ให้ libvirt-bin เริ่มทำงาน

จากนั้นเราไปข้างหน้าและแทนที่

ในที่สุดเราจะบอกให้ libvirt รีสตาร์ทและทุกอย่างจะดี

sudo systemctl รีสตาร์ท libvirt-bin

ในการตรวจสอบสถานะของ libvirt-bin ให้ป้อนคำสั่งต่อไปนี้

sudo service libvirt-bin สถานะ

สิ่งนี้จะแสดงผลการตรวจสอบสถิติเล็ก ๆ น้อย ๆ ที่ดีของ libvirt-bin ซึ่งแสดงให้เห็นว่ากระบวนการที่ระบุไว้ข้างต้นทำเคล็ดลับ ตอนนี้เราสามารถเรียกใช้เครื่องเสมือนของเราได้อีกครั้ง!

ข้อผิดพลาดอื่น ๆ ที่ฉันกำลังตรวจสอบหลังการอัปเกรดรวมถึงแนวทางแก้ไขที่สามารถนำไปใช้ได้:

ไม่สามารถเริ่ม LSB: exim Mail Transport Agent นี่เป็นข้อผิดพลาด postfix ซึ่งได้รับการแก้ไขก่อนที่เครื่องจะบูตอย่างสมบูรณ์

snd_hda_intel 0000: 00: 1f.3: ไม่สามารถเพิ่ม i915_bpo component master (-19) นี่เป็นข้อผิดพลาดของการ์ดเสียงซึ่งสามารถแก้ไขได้โดยการอัปเกรด Alsa (ฉันไม่ได้วางแผนที่จะใช้เสียงจากเซิร์ฟเวอร์ดังนั้นจึงไม่ส่งผลต่อประสิทธิภาพ)

สุดท้าย dev-disk-by x2duuid-E7A1 x2dCC4A.device: Dev dev-disk-by x2duuid-E7A1 x2dCC4A.device ปรากฏขึ้นสองครั้งด้วย sysfs ที่แตกต่างกัน เห็นได้ชัดว่าการสำรองข้อมูลพาร์ติชัน EFI ของฉันมีความละเอียดเพียงพอที่จะลงทะเบียนเป็น UUID เดียวกัน ไดรฟ์ NVMe (หลัก) มีพาร์ติชัน UUID แต่ RAID (สำรอง) ไม่ได้ในการแก้ไขสิ่งนี้ฉันจะปล่อยให้ไดรฟ์หลักอยู่คนเดียวและเปลี่ยน UUID ของไดรฟ์สำรองโดยใช้ uuidgen จากนั้น tune2fs / dev / sdx -U ใหม่ -id-number-from-uuidgen