GIẢI QUYẾT: Lỗi “Không thể khởi tạo lớp kiểm tra: Quyền bị từ chối” trong libvirt-bin sau khi nâng cấp Ubuntu Server 14.04 lên Ubuntu Server 16.04



Hãy Thử Công Cụ CủA Chúng Tôi Để LoạI Bỏ Các VấN Đề

Hôm nay tôi quyết định tiếp tục và nâng cấp một trong các máy chủ của mình từ Ubuntu 14.04 lên 16.04. Bạn không nên thực hiện việc này trên máy chủ sản xuất vì có nhiều sự cố có thể xảy ra. Các phương pháp hay nhất luôn chỉ ra rằng quay lại một máy chủ khác để thay thế hoặc một máy chủ tạm thời là cách an toàn nhất để thực hiện. Điều đó nói lên rằng, ai mà không thích thử những điều không nên làm.



Việc nâng cấp diễn ra khá tốt, với một ngoại lệ rõ ràng, libvirt-bin không thể được nâng cấp đúng cách. Dưới đây là các bước để khắc phục tình huống cũng như các bước không thực hiện được.



Không thể khởi chạy lớp kiểm tra 1



Thử nghiệm ban đầu là để khắc phục sự cố với sudo dpkg –configure -a, không có may mắn ở đó. Tôi cũng đã thử sử dụng trình giải quyết tự động aptitude, sau đó xóa và cài đặt lại. Cũng không có may mắn.

Để tìm ra gốc rễ của vấn đề, thay vì cố đoán một cách ngu ngốc, tôi đã chạy

Không thể khởi chạy lớp kiểm tra 2



sudo journalctl -xe

Như được hiển thị ở trên, một lỗi trong apparmor, khiến libvirt-bin không còn quyền chạy nữa, vì nó không còn được định cấu hình (buồn cười là tôi có thể thề là tôi đã nói với nó).

Dưới đây là cách khắc phục sự cố và gốc rễ của vấn đề. Trước tiên, chúng ta cần xóa bộ nhớ cache của trình phân tích cú pháp apparmor, vì nó có dữ liệu được lưu trữ khiến libvirt-bin không thể khởi động.

sudo apparmor_parser –purge-cache

Tiếp theo, chúng tôi xóa quy tắc ngăn libvirt-bin khởi động.

Không thể khởi chạy lớp kiểm tra 4

Sau đó, chúng tôi tiếp tục và thay thế nó.

Không thể khởi chạy lớp kiểm tra 5

Cuối cùng, chúng tôi yêu cầu libvirt khởi động lại, và tất cả sẽ tốt.

sudo systemctl khởi động lại libvirt-bin

Để kiểm tra trạng thái của libvirt-bin, hãy nhập lệnh sau

trạng thái libvirt-bin của dịch vụ sudo

Thao tác này sẽ xuất ra một kiểm tra thống kê nhỏ của libvirt-bin, cho thấy rằng quy trình nêu trên đã thực hiện một thủ thuật. Bây giờ chúng ta có thể chạy lại các máy ảo của mình!

Không thể khởi chạy lớp kiểm tra 3

Các lỗi khác mà tôi hiện đang điều tra, sau khi nâng cấp, cũng như các giải pháp có thể được triển khai:

Không khởi động được LSB: exim Mail Transport Agent. Đây là một lỗi postfix, được giải quyết trước khi máy được khởi động hoàn toàn.

snd_hda_intel 0000: 00: 1f.3: không thêm được thành phần chính i915_bpo (-19). Đây là lỗi card âm thanh, có thể được sửa chữa bằng cách nâng cấp Alsa (Tôi không định sử dụng âm thanh tắt máy chủ, vì vậy điều này không ảnh hưởng đến hiệu suất).

Cuối cùng dev-disk-by x2duuid-E7A1 x2dCC4A.device: Dev dev-disk-by x2duuid-E7A1 x2dCC4A.device xuất hiện hai lần với các sysfs khác nhau. Rõ ràng, bản sao lưu phân vùng EFI của tôi đã đủ kỹ lưỡng để đăng ký nó dưới dạng UUID chính xác. Ổ NVMe (chính) có UUID phân vùng, tuy nhiên RAID (sao lưu) thì không. Để khắc phục điều này, tôi sẽ để riêng ổ chính và thay đổi UUID của ổ sao lưu bằng uuidgen và sau đó điều chỉnh 2fs / dev / sdx -U new -id-number-from-uuidgen.

2 phút đọc