Udało się! Spakowany wcześniej Gentoo rozpakował się bez problemu. Alive & kicking.

drogie_gentusie

System jest o wiele szybszy od Kubuntu, który instalowałem wcześniej z nadzieją uniknięcia problemów z kompilacją. Szkoda, bo odnośnie samego Kubuntu miałem nadzieję na prostsze aktualizacje. Stało się jednak inaczej – Gentoo powrócił.

Mimo wszystko spakowana wersja systemu to niezły śmietnik, który wymagał aktualizacji oraz przebudowania drzewa zależności. Zamiast jednak przebudowy wybrałem…

 

Świeża instalacja

Jak świeże bułeczki smakują najlepiej, tak samo świeże Gentoo pozbawione jest rozbieżności z obecnie dostępnym oprogramowaniem – mam w ten sposób zamiar uniknąć m.in. problemu z PYTHON_SINGLE_TARGETS zależnym od kompilowanego pakietu. W trakcie, gdy regularnie używam obecnego, nieco zapuszczonego systemu, w tle kompiluje mi się nowy.

W trakcie pisania tego artykułu odhaczyłem już:

  • Pobranie i rozpakowanie plików stage3
  • Pobranie i rozpakowanie drzewa portów (portage)
  • Skopiowanie konfiguracji ze starego systemu – fstab, mdadm.conf, make.conf, resolv.conf, net, lilo.conf
  • Ustawienie stref czasowych (timezones)
  • Ustawienie nazwy hosta i wpisów w pliku hosts
  • Ustawienie hasła roota
  • Pobranie i rozpakowanie gentoo-sources (jądro systemu z patchami od Gentoo)
  • Skopiowanie konfiguracji .config do nowego jądra
  • Makeconfig na jądrze, sprawdzenie konfiguracji i kompilacja
  • Instalacja modułów i skopiowanie pliku bzImage do katalogu /boot
  • Poprawienie wpisów w lilo.conf
  • Kompilacja syslog-ng oraz vixie-cron (w trakcie)

W związku z tym, iż chcę, aby komputer pozostał jak najmniej nieaktywnym (praca), do wykonania pozostały jeszcze:

  • Instalacja narzędzi obsługi software RAID (mdadm)
  • Instalacja managera rozruchu (LILO)
  • Instalacja pakietów obsługi systemu plików (xfsprogs, jfsutils)
  • Instalacja pakietów związanych z tunelami (OpenVPN)
  • Instalacja sterowników binarnych NV (nvidia-drivers)
  • Kompilacja KDE-META wraz z zależnościami – pociągnięty automatycznie zostanie cały X.org, cmake oraz Qt.

drogie_gentusie2

  • Instalacja programów graficznych: Gimp, InkScape, Blender, Krita
  • Instalacja programów biurowych: LibreOffice
  • Instalacja przeglądarki: Mozilla Firefox
  • Instalacja multimediów: FFMPEG, VLC, Spotify
  • Instalacja oprogramowania dla programistów: NetBeans (pociągnie OpenJDK), QtCreator (pociągnie dodatkowe pakiety Qt)

Wówczas będę mógł spokojnie przepiąć system na nowy.

 

Rekompilacja stage3

Jak się okazało, stage3 został źle skompilowany albo do procesu kompilacji wykorzystano bug-owaty kompilator. Podczas kompilacji LILO a następnie kilku innych pakietów, jak np. jfsutils proces przerwał błąd. Z opisu błędu (Note) wynikało, że kompilator podczas procesu konfiguracji (configure) otrzymał większą wartość INT niż LONG. Technicznie rzecz biorąc wskazywałoby to na problem z procesorem, jednak w tym przypadku jest to na pewno wina oprogramowania.

Aktualizuję obecnie GCC, następnie binutils. Później znów przebuduję GCC z nowym binutils. To powinno sprawić, że podstawowe środowisko kompilacji będzie wolne od błędów.

Na marginesie: dlaczego najnowszy stage3 jest rozpowszechniany z GCC 4.7, skoro portage jest w stanie zaktualizować GCC do wersji 4.8.2?

 

Po przebudowaniu binutils oraz GCC wykonam standardowy:

emerge -e world

Polecenie przebuduje cały system, bez zwracania uwagi na zainstalowane wcześniej, stare zależności.

Po przebudowaniu GCC ponownie uruchomiłem kompilację LILO. Po dłuższej analizie – w sieci nie znalazłem nic na ten temat – okazało się, że problem nie tkwi w GCC ale jeszcze niżej. Kompilacja była przerywana z powodu kompilatora asemblera. Problem dotyka pakietów sys-devel/bin86 z większą wersją niż 0.16.17. Zasłoniłem zatem odpowiednio pakiety tak aby w przyszłości nie zaktualizować automatycznie bin86:

plik /etc/portage/package.mask/bin86:
>sys-devel/bin86-0.16.17

Po przebudowaniu bin86 re-kompilacja LILO powiodła się.

Revdep-rebuild

W związku z tym, że podczas aktualizacji sys-devel/bin86 sporo plików zostało zachowanych jako @preserved-libraries uruchomiłem od razu:

emerge gentoolkit
revdep-rebuild

drogie_gentusie1

Ufff! Wszystko jest ok.

libmp4v2-2.0.0 i Locale-gettext (perl)

drogie_gentusie3

W moim przypadku proces kompilacji KDE zakończył się błędem podczas budowania libmp4v2-2.0.0. Po analizie logów okazało się, że system nie widzi zainstalowanego modułu perla do obsługi Gettext.

Perl sprawia nieco problemów w procesie kompilacji, nie jest wykrywany np. XML-Parser, który również będzie trzeba ponownie zainstalować. Ciężko jest mi określić jednoznacznie, dlaczego takie ustrojstwo jak Perl wymaga tak wiele uwagi w Gentoo. Najlepiej byłoby, gdyby funkcje napisane w perlu zastępować odpowiednikami w Pythonie – co jest zgodnie z naturą Gentoo.

Wracając jednak do tematu – jeśli problem występuje także u Ciebie, zainstaluj ponownie – pomimo, iż system widzi pakiet jako zainstalowany:

drogie_gentusie4

emerge Locale-gettext

i ponownie wznów kompilację KDE/libmp4v2-2.0.0. Budowa tej biblioteki powinna zakończyć się powodzeniem.

drogie_gentusie5

 

Finał

System zbudował się od stage 3. Dodatkowo przygotowałem TAR z całością skompilowanego i skonfigurowanego systemu na wypadek, gdyby coś poszło nie tak w trakcie aktualizacji.

Po raz pierwszy zamiast stosować dowiązania /dev/mdX w FSTAB zastosowałem UUID.

Plus:

  • Problem dowolnego przypisania dowiązania macierzy przez jądro (np. MD0 staje się nagle MD125 – boot failed) znika. UUID jest niezmienny…

Minus:

  • do kolejnego formatowania. Każde formatowanie zmienia UUID i należy poprawić plik FSTAB.

UUID można sprawdzić zaraz po formatowaniu za pomocą:

# blkid

i skorygować odpowiednio plik FSTAB. Wpisy w MDADM możecie poprawić za pomocą:

# mdadm -d /dev/md127

TIP: Dodatkowo nowe minimalne płyty instalacyjne Gentoo obsługują myszkę. Tekst można zaznaczyć lewym przyciskiem, otworzyć plik i klikając prawym wkleić go w odpowiednie miejsce pliku konfiguracyjnego. To znacznie przyspiesza konfigurację.

 

M.M.