I dag besluttede jeg at gå videre og opgradere en af mine servere fra Ubuntu 14.04 til 16.04. Det anbefales ikke at gøre dette på en produktionsserver, da der er mange problemer, der kan gå galt. Bedste praksis indikerer altid, at spinding af en anden server enten som erstatning eller en midlertidig server er den sikreste vej at gå. Når det er sagt, hvem nyder ikke at prøve ting, der ikke bør gøres.
Opgraderingen gik ret godt, med en skarp undtagelse kunne libvirt-bin ikke opgraderes ordentligt. Her er trinene til løsning af situationen samt de trin, der ikke gør det.
Indledende prøve var at løse problemet med sudo dpkg –configure -a, ikke held der. Jeg forsøgte også at bruge aptitude auto resolver og derefter rense og geninstallere. Også ikke held.
For at komme til roden af problemet i stedet for tåbeligt at prøve at gætte, løb jeg
sudo journalctl -xe
Som vist ovenfor forårsagede en bug i apparmor, at libvirt-bin ikke længere har tilladelse til at køre, da den ikke længere var konfigureret (sjovt kunne jeg have svoret, at jeg havde fortalt det).
Her er hvordan du løser problemet og roden til problemet. Først skal vi rense apparmor-parser-cachen, da den har de gemte data, hvilket gør libvirt-bin ikke i stand til at starte.
sudo apparmor_parser – purge-cache
Dernæst fjerner vi reglen, der forhindrer libvirt-bin i at starte.
Så fortsætter vi og udskifter det.
Endelig får vi at fortælle libvirt at genstarte, og alt vil være godt.
sudo systemctl genstart libvirt-bin
For at kontrollere status for libvirt-bin skal du indtaste følgende kommando
sudo service libvirt-bin status
Dette udsender en dejlig lille statskontrol af libvirt-bin, der viser, at den ovenfor beskrevne proces gjorde tricket. Nu kan vi køre vores virtuelle maskiner igen!
De andre fejl, jeg i øjeblikket undersøger, efter opgradering, samt løsninger, der kan implementeres:
Kunne ikke starte LSB: exim Mail Transport Agent. Dette var en postfix-fejl, løst før maskinen blev fuldt startet.
snd_hda_intel 0000: 00: 1f.3: kunne ikke tilføje i915_bpo komponentmasteren (-19). Dette er en lydkortfejl, kan rettes ved at opgradere Alsa (jeg planlægger ikke at bruge lyd fra serveren, så dette påvirker ikke ydeevnen).
Endelig dev-disk-by x2duuid-E7A1 x2dCC4A.device: Dev dev-disk-by x2duuid-E7A1 x2dCC4A.device dukkede op to gange med forskellige sysfs. Tilsyneladende var sikkerhedskopien af min EFI-partition grundig nok til at registrere den som den nøjagtige samme UUID. NVMe-drevet (primært) har en partition UUID, men RAID (backup) gør det ikke. For at rette op på dette vil jeg lade det primære drev være alene og ændre UUID på backup-drevet ved hjælp af uuidgen og derefter tune2fs / dev / sdx -U nyt -id-nummer-fra-uuidgen.
2 minutter læst
