Megoldva: „Nem lehet inicializálni az ellenőrzési réteget: Engedély megtagadva” hiba a libvirt-bin-ben az Ubuntu Server 14.04 frissítése után Ubuntu Server 16.04-re

Ma úgy döntöttem, hogy folytatom és frissítem az egyik szerveremet az Ubuntu 14.04-ről 16.04-re. Ezt nem ajánlott éles kiszolgálón megtenni, mivel sok probléma tévedhet el. A bevált gyakorlatok mindig azt mutatják, hogy a legbiztonságosabb út egy másik szerver felpörgetése akár helyettesítő, akár ideiglenes szerverként. Ez azt mondta, aki nem szívesen próbál olyan dolgokat, amelyeket nem szabad megtenni.

A frissítés meglehetősen jól sikerült, egy kirívó kivétellel a libvirt-bin nem tudta megfelelően frissíteni. Itt vannak a helyzet kijavításának lépései, valamint azok a lépések, amelyek nem fognak megoldani.

Az első próba a sudo dpkg –configure -a problémájának megoldása volt, ott nem volt szerencsés. Megpróbáltam az aptitude auto resolver használatát is, majd kitisztítottam és újratelepítettem. Szintén nincs szerencséje.

Ahhoz, hogy rátérjek a probléma gyökerére, ahelyett, hogy ostobán próbálnám kitalálni, futottam

sudo journalctl -xe

Amint az fent látható, az apparmor hibája miatt a libvirt-bin már nem volt jogosult a futtatásra, mivel már nem volt konfigurálva (vicces, hogy megesküdhettem volna, hogy elmondtam).

A probléma és a gyökér kijavítása a következőképpen történik. Először ki kell ürítenünk az apparmor elemző gyorsítótárát, mivel a tárolt adatok miatt a libvirt-bin nem tud elindulni.

sudo apparmor_parser –purge-cache

Ezután eltávolítjuk a szabályt, amely megakadályozza a libvirt-bin indítását.

Aztán megyünk előre, és kicseréljük.

Végül meg kell mondanunk a libvirtnek, hogy indítsa újra, és minden jó lesz.

sudo systemctl indítsa újra a libvirt-bin fájlt

A libvirt-bin állapotának ellenőrzéséhez írja be a következő parancsot

sudo szolgáltatás libvirt-bin állapota

Ez a libvirt-bin szép kis statisztikai ellenőrzését eredményezi, amely megmutatja, hogy a fent vázolt folyamat elvégezte a trükköt. Most újra futtathatjuk virtuális gépeinket!

A többi jelenleg vizsgált hiba, a frissítés utáni, valamint a megvalósítható megoldások:

Nem sikerült elindítani az LSB-t: Exim Mail Transport Agent. Ez egy postfix hiba volt, amelyet a gép teljes indítása előtt orvosoltak.

snd_hda_intel 0000: 00: 1f.3: nem sikerült hozzáadni az i915_bpo komponens-mestert (-19). Ez egy hangkártya-hiba, kijavítható az Alsa frissítésével (nem tervezem, hogy a hangot kiszolgálón kívül használjam, így ez nem befolyásolja a teljesítményt).

Végül dev-disk-by x2duuid-E7A1 x2dCC4A.device: Dev dev-disk-by x2duuid-E7A1 x2dCC4A.device kétszer jelent meg különböző sysf-ekkel. Nyilvánvalóan az EFI partícióm biztonsági másolata elég alapos volt ahhoz, hogy pontosan ugyanazon UUID néven regisztrálja. Az NVMe meghajtó (elsődleges) rendelkezik UUID partícióval, azonban a RAID (biztonsági mentés) nem. Ennek kijavításához egyedül hagyom az elsődleges meghajtót, és az uuidgen használatával megváltoztatom a biztonsági másolat meghajtó UUID-jét, majd a tune2fs / dev / sdx -U new -id-number-from-uuidgen.