LÖST: ”Det gick inte att initiera granskningsskikt: Tillstånd nekad” fel i libvirt-bin efter uppgradering av Ubuntu Server 14.04 till Ubuntu Server 16.04

Idag bestämde jag mig för att fortsätta och uppgradera en av mina servrar från Ubuntu 14.04 till 16.04. Det rekommenderas inte att göra detta på en produktionsserver, eftersom det finns många problem som kan gå fel. Bästa praxis indikerar alltid att det är det säkraste sättet att spinna upp en annan server antingen som en ersättning eller en tillfällig server. Som sagt, vem tycker inte om att prova saker som inte bör göras.

Uppgraderingen gick ganska bra, med ett uppenbart undantag kunde libvirt-bin inte uppgraderas ordentligt. Här är stegen för att åtgärda situationen och stegen som inte gör det.

Den inledande prövningen var att åtgärda problemet med sudo dpkg –configure -a, ingen tur där. Jag försökte också använda aptitude auto resolver, sedan rensa och installera om. Inte heller lycka till.

För att komma till roten till problemet istället för att dumt försöka gissa jag sprang

sudo journalctl -xe

Som visas ovan orsakade ett fel i apparmor att libvirt-bin inte längre har tillstånd att köra, eftersom det inte längre var konfigurerat (roligt jag kunde ha svurit att jag sa till det).

Så här åtgärdar du problemet och orsaken till problemet. Först måste vi rensa apparmor-parser-cachen, eftersom den har lagrad data vilket gör att libvirt-bin inte kan starta.

sudo apparmor_parser – purge-cache

Därefter tar vi bort regeln som förhindrar att libvirt-bin startar.

Sedan fortsätter vi och byter ut det.

Slutligen får vi berätta för libvirt att starta om, och allt kommer att bli bra.

sudo systemctl starta om libvirt-bin

För att kontrollera status för libvirt-bin anger du följande kommando

sudo service libvirt-bin status

Detta kommer att ge en trevlig liten statskontroll av libvirt-bin, vilket visar att processen som beskrivs ovan gjorde tricket. Nu kan vi köra våra virtuella maskiner igen!

De andra felen jag för närvarande undersöker, efter uppgradering, samt lösningar som kan implementeras:

Det gick inte att starta LSB: exim Mail Transport Agent. Detta var ett postfix-fel, löst innan maskinen startades helt.

snd_hda_intel 0000: 00: 1f.3: det gick inte att lägga till i915_bpo komponentmastern (-19). Detta är ett ljudkortfel, kan korrigeras genom att uppgradera Alsa (jag planerar inte att använda ljud från servern, så detta påverkar inte prestanda).

Slutligen dev-disk-by x2duuid-E7A1 x2dCC4A.device: Dev dev-disk-by x2duuid-E7A1 x2dCC4A.device dök upp två gånger med olika sysfs. Tydligen var säkerhetskopian av min EFI-partition noggrann för att registrera den som exakt samma UUID. NVMe-enheten (primär) har en partition UUID, men RAID (säkerhetskopiering) gör det inte. För att åtgärda detta lämnar jag den primära enheten ensam och ändrar UUID för säkerhetskopieringsenheten med hjälp av uuidgen och sedan tune2fs / dev / sdx -U ny -id-nummer-från-uuidgen.