Aktualizacja microcode procesora w Debianie Wheezy – HOWTO.

Jakiś czas temu pisałem o 3 rzeczach, których zapewne nie aktualizujesz w Debianie (piszę w Debianie, ale zapewne prawdziwe jest dla większości dystrybucji opartych na nim). Jeśli chodzi o mikrokod, było prosto, łatwo, i przyjemnie. I minęło, wraz z nadejściem Wheezy’ego.

Magiczne polecenie update-intel-microcode, o którym wówczas pisałem, niestety nie jest już obecne w Debianie poczynając od wersji Wheezy. Zamiast tego, trzeba zrobić wszystko ręcznie. Nie wnikałem, ale zapewne chodziło o kwestie licencyjno-copyrightowe – przy pobieraniu pliku z mikrokodem ze strony Intela jest pytanie o zaakceptowanie licencji. W każdym razie nie ma już narzędzia i trzeba zadbać ręcznie o aktualizację mikrokodu.

Jest za to inne narzędzie, które – wraz z bazowymi mikrokodami – znajduje się w pakiecie intel-microcode.

Po pierwsze wchodzimy na stronę Intela, skąd możemy pobrać mikrokod. Wielkiego wyboru nie widzę, ale może się zmienić – wybieramy najnowszą wersję. Akceptujemy licencję, pobieramy plik. Na dysku ląduje plik o nazwie zbliżonej do microcode-20120606-v2.tgz. Należy go rozpakować, a naszym oczom ukaże się microcode.dat. To są mikrokody, których szukacie! 😉

Po drugie, przy pomocy narzędzia iucode_tool produkujemy z niego pliki w formie strawnej dla pozostałych narzędzi. Ja zdecydowałem się na rozpakowanie ich „na boczek”, żeby ręcznie porównać:

mkdir /tmp/ucode && iucode_tool -K/tmp/ucode/ /tmp/microcode.dat

Po tym zabiegu w katalogu /tmp/ucode mamy w tym momencie całkiem sporą ilość plików, które są gotowymi do użycia mikrokodami. Aby były używane, należy je skopiować do /lib/firmware/intel-ucode. Oczywiście jest możliwość rozpakowywania bezpośrednio w domyślną systemową lokalizację, wystarczy użyć przełącznika –overwrite i nie podawać katalogu docelowego.

Pora na użycie. I tu przyznaję zaczynają się schody. O ile wcześniej bez problemu można było załadować mikrokod online, to teraz iucode_tool -vk /tmp/ucode/* niby się wykonuje (wczytując wszystkie, czyli dla różnych procesorów mikrokody – zupełnie tego nie rozumiem), ale chyba nie działa. W każdym razie śladu w dmesg żadnego… Wygląda, że mikrokod jest dodawany do initramfs. Aby dodać mikrokody znajdujące się w domyślnej systemowej lokalizacji do wszystkich zainstalowanych kerneli, popełniamy:

update-initramfs -k all -uv

Po reboocie powinniśmy działać na nowym mikrokodzie. Uwaga: domyślnie do initramfs trafiają tylko mikrokody dla procesora, na którym jest wydawane polecenie. Można to zmienić w /etc/default/intel-microcode.

Dla procesorów AMD istnieje analogiczny pakiet, ale nie mam takiego pod ręką, by przetestować.

Przy pisaniu wpisu posiłkowałem się opisem Mikrokodu na wiki Arch. Co prawda niewiele się zgadza, ale może komuś się przyda. Warto też zajrzeć na ogłoszenie dotyczące mikrokodu, które znalazłem już po napisaniu wpisu.

 

Jak naprawiłem Libre Office 3.5.4 w Debianie.

Niedawno chciałem odczytać jakiś dokument w formacie .doc i okazało się, że Libre Office nie startuje. Pojawiała się plansza logowania i tyle. Potrzebowałem tylko odczytu, więc zwaliłem na Debiana w wersji unstable, locale ustawione na iso-8859-2, więc użyłem sąsiedniego kompa, skonwertowałem do PDF i zapomniałem o sprawie.

Jakiś czas później chciałem coś napisać, więc wróciłem do sprawy. Uruchomienie z wiersza poleceń, zmiana locale itp. nie pomogły. Jedyny komunikat, który dostałem, zawierał:

com::sun::star::uno::RuntimeException

Podejrzewałem Debiana unstable, więc szybkie sprawdzenie bugów i jest jeden #641412, w miarę pasujący opisem, ale niestety bez rozwiązania. Spróbowałem Google i tu efekt był lepszy. Znalazłem tę stronę [SOLVED] LibreOffice 3.5 error: Missing vcl resource. Tytuł optymistyczny.

Zainstalowałem pakiet libreoffice-gnome, tym razem przy uruchomieniu w oknie pojawiła się informacja o braku praw do pliku. Faktycznie, jeden z katalogów z plikami konfiguracyjnymi miał właściciela root. Usunąłem (z roota) ~/.config/libreoffice ~/.config/.libreoffice oraz ~/.config/.openoffice.org (ostatnia nazwa niedokładna), uruchomiłem Libre Office… Tadam!

Alternatywa dla VirtualBox – AQEMU.

Zachciało mi się zmiany kernela z 3.2 na 3.5. Inspiracją był znajomy, który zaobserwował spadek zużycia prądu na laptopie przy zmianie z kernela 3.2 do 3.4 z 28W do 19W (pomiar wg powertop). VirtualBox po zmianie kernela oczywiście przestał działać. Nic nowego i nawet pisałem o tym, że debianowa paczka dla VirtualBox jest pod konkretny kernel robiona. Pisałem też, jak uruchomić VirutalBox na Debianie z własnym kernelem.

Co prawda u mnie kernel 3.5 nic nie daje w kwestii zużycia energii, ale skoro już pojawił się temat, to trzeba go pociągnąć. Mogłem użyć poprzednio opisanego sposobu z uruchomieniem VirutalBox na Debianie z własnym kernelem, ale jakoś nie uśmiechała mi się zmiana VirtualBox na wersję z repozytorium Oracle (poza tym, kiedyś różniły się licencją – w Debianie było OSE, nie żeby miało to jakiekolwiek znaczenie w tym przypadku), ściąganie plików nagłówkowych i kompilacja kernela, więc postanowiłem się rozejrzeć za alternatywami dla VirtualBox.

Ludzie podszepnęli KVM, który jak najbardziej znam i używam, ale w innym, serwerowym zastosowaniu. Okazuje się, że KVM ma także, obok narzędzi do zarządzania CLI i webowych, także narzędzia desktopowe, czyli GUI. Na stronie z listą frontendów dla KVM znaleźć można trzy frontendy typu desktop: AQEMU, virt-manager oraz GKVM. W pierwszym podejściu przeoczyłem virt-managera i wziąłem się za AQEMU. Już miałem orzec, że bootowanie z obrazu iso płyty CD nie działa, ale dogrzebałem się do ustawienia, które pozwala wybrać medium (i które nie jest zapamiętywane, bug zgłoszony).

Po tym było już z górki. Wirtualizacja desktopu z użyciem KVM generalnie po prostu działa. Nie testowałem jakoś specjalnie mocno, bo służy mi to głównie do zabaw z różnymi systemami liveCD, ale sieć działa, bootowanie z CD-ROM działa, przeglądarka działa. Zarządzanie, wygląd i dostęp do opcji też wygląda też sensownie, co można zobaczyć na screenshocie poniżej.

AQEMU screenshot

Źródło: strona projektu AQEMU

Zrobiłem, po przebootowaniu do 3.2, rzecz jasna, krótki benchmark, a w zasadzie namiastkę benchmarku, dla AQEMU i VirtualBox, w postaci zmierzenia czasu uruchamiania systemu z liveCD (padło na T(A)ILS – akurat nowe wydanie jest; 1GB RAM dla wirtualki, 1 CPU, parę uruchomień, ustawienia zbliżone do domyślnych). Dla AQEMU bootowanie (do momentu pierwszej interaktywności) trwało zwykle 44,9 sekundy, dla VirtualBox – 45,2 sekundy. Różnica pomijalna. Co ciekawe, dołożenie drugiego procesora nie wpływa na wynik i to w żadnym z przypadków.

Przy okazji, gdyby ktoś się brzydził frontendami i był hardcore’owym użytkownikiem wiersza poleceń, to do uruchomienia liveCD z w pliku o nazwie plik.iso użyciem KVM wystarczy:

kvm -m 1024 -vga vmware -boot d -cdrom plik.iso

Chwilowo to wszystko nt. wirtualizacji na desktopie. Szybki wniosek VirtualBox nie jest jedynym rozwiązaniem, AQEMU daje radę i wygląda na rozwiązanie wygodniejsze, jeśli ktoś używa Debiana niekoniecznie z dystrybucyjnym kernelem, lub kernelem z innej wersji. Nie będę testował GKVM – projekt wygląda na porzucony. Prawdopodobnie niebawem szansę dostanie virt-manager – na razie nie uruchomił się OOTB i krzyczy o niemożności dostania się do libvirtd. Nie miałem czasu bliżej się przyjrzeć sprawie. Jak uruchomię, to nie omieszkam opisać. Stay tuned.