Šiandien nusprendžiau atnaujinti vieną iš savo serverių iš „Ubuntu 14.04“ į „16.04“. Tai nerekomenduojama daryti gamybos serveryje, nes yra daug problemų, kurios gali suklysti. Geriausios praktikos pavyzdžiai visada rodo, kad saugiausias būdas yra sukurti kitą serverį kaip pakaitinį arba laikiną serverį. Sakė, kam nepatinka išbandyti tai, ko nereikėtų daryti.
Atnaujinimas vyko gana gerai, išskyrus vieną ryškią išimtį, „libvirt-bin“ nepavyko tinkamai atnaujinti. Čia pateikiami veiksmai, kaip išspręsti situaciją, taip pat veiksmai, kurių nebus.
Pradinis bandymas buvo išspręsti problemą su sudo dpkg –configure -a, ten nesisekė. Aš taip pat bandžiau naudoti „aptitude auto resolver“, tada išvalyti ir iš naujo įdiegti. Taip pat nesiseka.
Norėdami sužinoti problemos esmę, užuot kvailai bandę atspėti, kad bėgau
sudo journalctl -xe
Kaip parodyta aukščiau, aparmaro klaida privertė libvirt-bin nebeturėti leidimo paleisti, nes jis nebebuvo sukonfigūruotas (juokinga, aš galėjau prisiekti, kad aš jam liepiau).
Štai kaip išspręsti problemą ir jos šaknį. Pirmiausia turime išvalyti „apparmor“ analizatoriaus talpyklą, nes joje yra duomenų, todėl „libvirt-bin“ negalima paleisti.
sudo apparmor_parser –purge-cache
Tada pašalinsime taisyklę, neleidžiančią paleisti „libvirt-bin“.
Tada mes einame į priekį ir pakeičiame jį.
Galiausiai mes turime pasakyti libvirt paleisti iš naujo, ir viskas bus gerai.
sudo systemctl paleiskite iš naujo libvirt-bin
Norėdami patikrinti libvirt-bin būseną, įveskite šią komandą
sudo paslaugos libvirt-bin būsena
Tai suteiks gražų nedidelį libvirt-bin statistinį patikrinimą, parodydamas, kad aukščiau aprašytas procesas padarė apgaulę. Dabar mes galime vėl paleisti savo virtualias mašinas!
Kitos klaidos, kurias šiuo metu tiriu, atnaujinimas ir sprendimai, kuriuos galima įdiegti:
Nepavyko paleisti LSB: exim Mail Transport Agent. Tai buvo „postfix“ klaida, išspręsta prieš pilnai įkeliant mašiną.
snd_hda_intel 0000: 00: 1f.3: nepavyko pridėti „i915_bpo“ komponentų pagrindinio elemento (-19). Tai yra garso plokštės klaida, ją galima ištaisyti atnaujinant „Alsa“ (neplanuoju naudoti garso iš serverio, todėl tai neturi įtakos našumui).
Galiausiai dev-disk-by x2duuid-E7A1 x2dCC4A.device: Dev dev-disk-by x2duuid-E7A1 x2dCC4A.device pasirodė du kartus su skirtingais sistemomis. Akivaizdu, kad mano EFI skaidinio atsarginė kopija buvo pakankamai išsami, kad galėčiau užregistruoti kaip tą patį UUID. „NVMe“ diske (pagrindinis) yra skaidinio UUID, tačiau RAID (atsarginės kopijos) nėra. Norėdami tai ištaisyti, pagrindinį diską paliksiu ramybėje ir pakeisiu atsarginės kopijos disko UUID naudodamas uuidgen ir tada tune2fs / dev / sdx -U new -id-number-from-uuidgen.
2 minutes perskaityta
