Днес реших да продължа и да надстроя един от сървърите си от Ubuntu 14.04 на 16.04. Не се препоръчва да правите това на производствен сървър, тъй като има много проблеми, които могат да се объркат. Най-добрите практики винаги показват, че завъртането на друг сървър или като заместител, или временен сървър е най-безопасният начин да се премине. Въпреки това, който не обича да опитва неща, които не бива да се правят.
Надстройката премина доста добре, с едно явно изключение, libvirt-bin не можа да бъде надграден правилно. Ето стъпките за коригиране на ситуацията, както и стъпките, които няма.
Първоначалното изпитание трябваше да реши проблема със sudo dpkg –configure -a, няма късмет там. Също така се опитах да използвам автоматичния преобразувател на aptitude, след което продухване и повторно инсталиране. Също така няма късмет.
За да стигна до корена на проблема, вместо глупаво да се опитвам да позная, че бягах
sudo journalctl -xe
Както е показано по-горе, грешка в apparmor причинява, че libvirt-bin вече няма разрешение за стартиране, тъй като вече не е конфигуриран (смешно, можех да се закълна, че го казах).
Ето как да разрешите проблема и корена на проблема. Първо трябва да прочистим кеша на анализатора на apparmor, тъй като той има съхранените данни, което прави libvirt-bin неспособен да стартира.
sudo apparmor_parser –purge-cache
След това премахваме правилото, предотвратяващо стартирането на libvirt-bin.
След това продължаваме и го заместваме.
И накрая, трябва да кажем на libvirt да се рестартира и всичко ще бъде добре.
sudo systemctl рестартирайте libvirt-bin
За да проверите състоянието на libvirt-bin, въведете следната команда
sudo услуга libvirt-bin статус
Това ще изведе хубава малка проверка на статията на libvirt-bin, показваща, че описаният по-горе процес е свършил работа. Сега можем да стартираме нашите виртуални машини отново!
Другите грешки, които разследвам в момента, след надстройка, както и решения, които могат да бъдат внедрени:
Неуспешно стартиране на LSB: exim Mail Transport Agent. Това беше грешка в постфикса, разрешена преди пълното стартиране на машината.
snd_hda_intel 0000: 00: 1f.3: не успя да добави главен компонент i915_bpo (-19). Това е грешка на звукова карта, може да бъде коригирана чрез надстройка на Alsa (не смятам да използвам звук извън сървъра, така че това не влияе на производителността).
И накрая dev-disk-by x2duuid-E7A1 x2dCC4A.device: Dev dev-disk-by x2duuid-E7A1 x2dCC4A.device се появи два пъти с различни sysfs. Очевидно архивирането на моя дял EFI беше достатъчно задълбочено, за да го регистрирам като абсолютно същия UUID. Устройството NVMe (основно) има UUID на дяла, но RAID (архивиране) няма. За да го коригирам, ще оставя основното устройство на мира и ще сменя UUID на резервното устройство, използвайки uuidgen и след това tune2fs / dev / sdx -U нов -id-номер-от-uuidgen.
2 минути четене
