S-A REZOLVAT: bug-ul „Imposibil de inițializat stratul de audit: permisiunea refuzată” în libvirt-bin după actualizarea Ubuntu Server 14.04 la Ubuntu Server 16.04

Astăzi am decis să merg mai departe și să actualizez unul dintre serverele mele de la Ubuntu 14.04 la 16.04. Nu este recomandat să faceți acest lucru pe un server de producție, deoarece există multe probleme care pot merge prost. Cele mai bune practici indică întotdeauna că folosirea unui alt server fie ca înlocuitor, fie un server temporar este cea mai sigură cale de parcurs. Acestea fiind spuse, cui nu îi place să încerce lucruri care nu ar trebui făcute.

Actualizarea a mers destul de bine, cu o excepție evidentă, libvirt-bin nu a putut fi actualizat corect. Iată pașii pentru a remedia situația, precum și pașii care nu o vor face.

Prima încercare a fost de a rezolva problema cu sudo dpkg –configure -a, fără noroc acolo. De asemenea, am încercat să folosesc rezolvarea automată aptitude, apoi să purg și să reinstalez. De asemenea, fără noroc.

Pentru a ajunge la rădăcina problemei, în loc să încerc să prost să ghicesc am fugit

sudo journalctl -xe

După cum se arată mai sus, o eroare în apparmor a făcut ca libvirt-bin să nu mai aibă permisiunea de a rula, deoarece nu mai era configurat (amuzant că aș fi putut jura că i-am spus).

Iată cum să remediați problema și rădăcina problemei. Mai întâi trebuie să curățăm cache-ul parserului apparmor, deoarece acesta are datele stocate, ceea ce face ca libvirt-bin să nu poată porni.

sudo apparmor_parser –purge-cache

Apoi eliminăm regula care împiedică pornirea libvirt-bin.

Apoi mergem înainte și îl înlocuim.

În cele din urmă, vom spune lui libvirt să repornească și totul va fi bine.

sudo systemctl reporniți libvirt-bin

Pentru a verifica starea libvirt-bin, introduceți următoarea comandă

sudo service statutul libvirt-bin

Acest lucru va afișa o mică verificare statistică a libvirt-bin, arătând că procesul descris mai sus a făcut truc. Acum putem rula din nou mașinile noastre virtuale!

Celelalte erori pe care le investighez în prezent, după actualizare, precum și soluții care pot fi implementate:

Nu a putut porni LSB: exim Mail Transport Agent. Aceasta a fost o eroare postfix, rezolvată înainte ca computerul să fie pornit complet.

snd_hda_intel 0000: 00: 1f.3: nu s-a adăugat i915_bpo component master (-19). Aceasta este o eroare a plăcii de sunet, care poate fi corectată prin actualizarea Alsa (nu intenționez să folosesc sunetul de pe server, deci acest lucru nu afectează performanța).

în cele din urmă dev-disk-by x2duuid-E7A1 x2dCC4A.device: Dev dev-disk-by x2duuid-E7A1 x2dCC4A.device a apărut de două ori cu sisteme diferite. Aparent, copierea de rezervă a partiției mele EFI a fost suficient de detaliată pentru a o înregistra exact ca UUID. Unitatea NVMe (primară) are o partiție UUID, cu toate acestea RAID (copie de rezervă) nu. Pentru a remedia acest lucru, voi lăsa unitatea primară singură și voi schimba UUID-ul unității de rezervă folosind uuidgen și apoi tune2fs / dev / sdx -U new -id-number-from-uuidgen.