25 maja 2010 społeczności udostępniona została wersja 1.0 MeeGo - lekkiej dystrybucji Linuksa przeznaczonej na urządzenia przenośne. Projekt wydał mi się ciekawy tym bardziej, że często potrzebuję uruchomić swojego netbooka żeby na szybko sprawdzić coś w sieci i przydałaby mi się funkcja małego, błyskawicznego systemu. Nie było jednak łatwo.
Założenia były następujące: zainstalować MeeGo w układzie dual-boot z istniejącym już systemem (PLD), co umożliwiłoby mi pracę na "dużym" systemie oraz szybkie uruchamianie uproszczonej wersji do Internetu i poczty. Wymagało to zachowania nie tylko obecnej instalacji, ale także partycji z danymi, której rozmiar przekracza nieznacznie 100GB. Zadanie wydaje się zatem banalnie proste - zmniejszyć rozmiar istniejącej partycji systemowej, zainstalować na zwolnionym miejscu MeeGo oraz odpowiednio skonfigurować bootloadery. Zapowiadał się przyjemny wieczór.
Pierwsze schody pojawiły się gdy dotarło do mnie, iż żaden z programów do zmiany rozmiaru partycji z zachowaniem danych nie obsługuje systemu plików XFS, który króluje na systemach instalowanych przeze mnie. Układ partycji przedstawiał się następująco:
- sda1 - partycja wymiany (swap) - ok. 1GB
- sda2 - główna partycja systemowa (root) - ok. 60GB
- sda3 - partycja z katalogami domowymi (home), zaszyfrowana (Crypto LUKS) - ok. 100GB
Po długich chwilach zadumy i przetrząsania Internetu postanowiłem przepartycjonować dysk, pozostawiając jedynie wolumin sda3 nienaruszony. Archiwizacja konfiguracji systemowej nie nastręcza w Uniksach większych problemów, takoż i zabezpieczenie listy zainstalowanych pakietów, repartycjonowanie nie jest zatem procesem uciążliwym, lecz nienaturalnie siłowym. Czasu miałem jednak niewiele, więc nie było co wydziwiać. Partycje sda1 oraz sda2 zmieniły się w sda1, sda2 oraz sda3, zaś partycja home dostała tylko nowe oznaczenie (sda4) i pozostała nietknięta.
Humor nieco mi się się pogorszył, kiedy instalator MeeGo (nieco zmodyfikowana Anaconda) stwierdził, że czas wykrywania istniejących dysków powinien dążyć do nieskończoności. Po piętnastu minutach niecierpliwego wpatrywania się w komunikat Finding storage devices stwierdziłem, iż coś jest tu nie tak jak powinno. Analiza logów niewiele dała (żadnych znaczących błędów), zaś twórcy nie udostępnili konsoli z shellem aby można było bardziej dogłębnie sprawdzić co temu wężowi się nie podoba. Kiedy zdałem sobie sprawę, że właśnie ślęczę nad kodem źródłowym Anacondy próbując dojść do przyczyny problemu, czym prędzej wszystko pozamykałem i zarejestrowałem się na forum użytkowników MeeGo, gdzie chwilę później łamaną angielszczyzną z lekką mieszaniną niemieckiego, francuskiego, polskiego i hindi wyłożyłem swój problem wraz z cytatami zapisów w logach.
Minęły prawie dwie i pół minuty, odpowiedzi nie było, postanowiłem zatem powrócić do dłubania. Ponownie przepartycjonowałem dysk, a nawet wyczyściłem go pozostawiając jedynie drogocenną i obszerną partycję z danymi. Rezultat wciąż pozostawał ten sam. Problem musiał być specyficzny dla mojego systemu, gdyż inni użytkownicy tego netbooka (MSI Wind U100 Plus) raportowali poprawną instalację. Nie pozostawało mi zatem nic innego jak dokonać archiwizacji partycji z danymi i podejść do instalatora z czystym dyskiem. 100GB zaszyfrowanych danych w postaci surowej wysysanych przez dd i wysyłanych netcatem po sieci na inną maszynę przeleciało przez switch w ok. dwie godziny. PXE rządzi. Partycja z danymi została usunięta, lecz skrzętnie zanotowałem sobie jej pozycję na dysku zapisując początkowy i końcowy blok.
Anaconda czystym dyskiem była zachwycona do tego stopnia, że bez zbędnych ceregieli uporała się z wykrywaniem "storedżowych diwajsów" (w liczbie 1) oraz partycji (które nie istniały). Zatem instalator ma ogromne problemy z woluminami szyfrowanymi... Czy on je próbuje odszyfrować? Po co? Przecież podaję mu hasło kiedy o nie prosi. Ale może jest jakiś powód, do zrozumienia którego mój umysł jest zbyt prymitywny, np. cholerny błąd programisty... Postępując zgodnie z pierwotnym planem założyłem partycję wymiany i partycję dla MeeGo, zaś pozostałą część dysku zostawiłem leżącą odłogiem. Na nią przyjdzie czas później. Ale pojawił się kolejny problem. Instalator kategorycznie zażądał oddzielnej partycji startowej (boot). Oznaczało to, że skończyły mi się urządzenia na partycje. Nie jestem fanem woluminów rozszerzonych, więc ograniczony jestem do czterech partycji podstawowych, co daje: swap, boot dla MeeGo, root dla MeeGo, root dla PLD... a gdzie zaszyfrowana partycja z danymi?
Zdecydowałem się na rozwiązanie bałaganiarskie, ale skuteczne - partycja startowa MeeGo będzie jednocześnie główną partycją systemową PLD. Pliki kernela i startowego ramdysku mogą sobie koegzystować w niczym niezakłóconej harmonii, zatem wystarczy tylko pamiętać, że tam są przy każdej aktualizacji bootsectora i odpowiednio dostosować konfiguracje bootloaderów do nowej sytuacji. Oznaczało to także, że muszę zrezygnować z systemu plików XFS na rzecz EXT3, gdyż instalator MeeGo tego pierwszego nie obsługuje. Powstał więc następujący układ:
- sda1 - partycja wymiany (swap)
- sda2 - partycja startowa MeeGo (boot) oraz systemowa PLD (root)
- sda3 - partycja systemowa MeeGo (root)
I to byłoby na tyle... gdyby nie kolejny problem. Instalator postanowił tym razem zawisnąć na aktualizacji bootsectora. Świecący w nieskończoność komunikat Finding storage devices zastąpił teraz Installing bootloader. Po wielu WTF!?! okazało się, iż Anaconda osiąga taki stan błogiej niemocy w przypadku, gdy partycję systemową MeeGo umieścimy na systemie plików innym niż BTRFS (w moim przypadku był to EXT3)... Nie widzę na ten temat najmniejszej wzmianki w dokumentacji, ani w samym instalatorze, zaś do tego wniosku doszedłem eksperymentalnie. Skąd ma o czymś takim wiedzieć użytkownik, który nie wie co to jest system plików? A do takich ludzi jest m.in. kierowana ta dystrybucja.
Po ponownej instalacji, tym razem na BTRFS, MeeGo wreszcie zadziałało... prawie. Oczywiście, jest to wersja testowa, zatem coś może nie działać lub działać nieprawidłowo. I w istocie tak jest. Najważniejsze rzeczy działają bez problemów, nie zaobserwowałem także wywrotek, które użytkownicy zgłaszali na forum. Dźwięk działa, przeglądarka działa, komunikator działa, terminal znakowy też działa (huuuuraaaa!!!), a nawet Bluetooth bez zająknięcia odnalazł mój telefon komórkowy, z czym sam mam czasem problemy. Klient DHCP jednakże z uporem maniaka nie chce mi ustawiać domyślnej bramy. Automagiczna konfiguracja DNS też jest dla mnie dziwna, gdyż nie działa. Przez cały czas w resolv.conf jest ustawiony serwer 127.0.0.1 (co samo w sobie jest pomysłem dość nietypowym). Co gorsza, przy konfiguracji statycznej nie ma możliwości wpisania swojego adresu serwera DNS, a zawartość resolv.conf jest nadpisywana przy każdym starcie przez wynalazek o nazwie Connection Manager, który... nie posiada plików konfiguracyjnych. Są też inne upierdliwości. Na przykład, MeeGo - działający na systemie wieloużytkownikowym - jest jednoużytkownikowy. Możemy założyć tylko jedno konto (w terminalu możemy założyć ich więcej, ale nie będą one respektowane przez środowisko graficzne), a przecież taka dystrybucja aż prosi się o możliwość zalogowania jako gość, np. jeśli znajomi chcą na chwilę skorzystać z dostępu do Internetu. Projekt jednakże jest jeszcze młody i być może zostanie to zmienione.
Zapewne cieszycie się, że to już koniec tej przydługiej historii. Ja też się cieszyłem, do czasu aż zauważyłem, że zakładka połączeń sieciowych zdaje się nie zauważać mojej karty WiFi. Urządzenie przenośne, dystrybucja służąca do surfowania po internecie, brak obsługi połączeń bezprzewodowych. Która z funkcji (lub jej brak) tutaj nie pasuje? Na forum MeeGo ludzie zgłaszają problemy z WiFi, zatem obsługa takowa najwyraźniej jest... tylko gdzie? Jak się okazało, MeeGo 1.0 nie wspiera kart RTL8187SE, ponieważ nie ma do nich modułu kernela. Wydało mi się to dość podejrzane, gdyż biega to na kernelu 2.6.33.3, a w PLD mam moduł do tej karty na kernelu 2.6.33.5... Czas powrócić zatem do dłubania.
Analiza źródeł kernela 2.6.33 (oraz 2.6.34) wykazała, że sterownik znajduje się w gałęzi staging, czyli - mówiąc w uproszczeniu - nie jest jeszcze w pełni gotów. Pod PLD jak dotychczas nie robił mi żadnych przykrych niespodzianek, zatem działa. Można by się zgodzić co do tego, że twórcy MeeGo nie chcieli włączać obsługi na sterowniku w wersji przedprodukcyjnej (pomimo, że MSI Wind U100 jest dość popularnym sprzętem), gdyby nie fakt iż nie mieli takich rozterek względem innych sterowników z tej gałęzi. No, ale z developerami kłócił się nie będę, skompiluję sobie sam. TAK! MeeGo pozwala nawet na instalację kompilatora! Czyż to nie piękne?
Kiedy pobrałem (wewnętrznym zarządcą pakietów, którym jest "fedorowy" yum) podejrzanie mały pakiet ze źródłami kernela i zajrzałem do środka, mój humor opadł jeszcze niżej, po tych długich walkach osiągając poziom ok. -623. Ze źródeł została usunięta połowa plików z kodem źródłowym. Między innymi z kodem sterownika RTL8187SE. Dlaczego? To jest bez sensu! Żeby oszczędzić miejsce na urządzeniu? Przecież ten pakiet nie jest instalowany domyślnie. Trzeba jawnie, w terminalu znakowym wpisać długaśne polecenie żeby go pobrać i zainstalować, a co za tym idzie, wiedzieć co się robi. Czy to jest jakaś forma kiepskiego zabezpieczenia przed własnoręczną kompilacją i użytkowaniem kernela lub jego modułów, które nie są supportowane przez twórców MeeGo? Jedyne, co tym osiągają, to utrudnianie życia użytkownikom. Wykrzyknąłem Ja się nie dam!, wciągnąłem flagę na maszt, odegrałem sygnał do ataku i... wróciłem do dłubania.
Kompilacja ze źródeł dostarczonych w pakiecie oczywiście nie była możliwa. Pobrałem zatem kod z repozytorium Linuksa, przerzuciłem brakujące pliki sterownika RTL8187SE, zmodyfikowałem konfigurację kompilacji, zapuściłem make i... JASNA CHOLERA! Do kompilacji nawet nie dochodziło, gdyż błędami sypało już na etapie przygotowania źródeł. Wyłączanie targetu prepare w Makefile (w tym przypadku niepotrzebnego) generowało inne błędy, w innych miejscach. Krótko mówiąc, źródła kernela z dystrybucyjnej paczki RPM nie umożliwiają kompilacji jądra systemu, nawet jeśli nic nie zmienimy w jej konfiguracji. Gdzie tu sens? Gdzie logika? Po co ten pakiet jest w takim razie? Żeby był i miał ładną nazwę?
Mocno już podłamany przerzuciłem konfigurację kompilacji z pakietu dystrybucyjnego do pobranych z repozytorium Linuksa źródeł, zmodyfikowałem pliki nagłówkowe zgodnie z ustawieniami MeeGo, skompilowałem moduł, załadowałem, karta WiFi odżyła i działa. Źródła wywaliłem i nie zamierzam więcej do nich wracać.
Ale to nie koniec kłopotów. Po zainstalowaniu PLD okazało się, że nie mogę użyć lilo ani grub jako bootloadera. MeeGo używa do uruchomienia Extlinux (modyfikacji Syslinux), który ustawia rozdzielczość bufora ramki VESA na natywną rozdzielczość wyświetlacza (1024x600), po czym proces dalszego ładowania systemu z tego korzysta. Ani lilo, ani grub nie umożliwiają ustawienia takiej rozdzielczości, gdyż obsługują jedynie formaty 4:3. Uruchomienie MeeGo w takim stanie powoduje rozjazdy i tzw. "rozkaszanienie" obrazu. Z tym jednakże było już znacznie mniej roboty. Jako bootloadera obu systemów użyłem Extlinux (na co PLD nie jest przygotowany, ale da się z tym żyć) i mam działający dual-boot na netbooku: MeeGo do "lekkiej rozrywki" i PLD do "cięższej pracy". Jeszcze tylko odtworzenie zaszyfrowanej partycji z danymi na podstawie uprzednio zanotowanego położenia na dysku i wszystko wróciło do normy.
Jeśli ktoś z Was dotarł aż tutaj z czytaniem niniejszego wpisu - podziwiam cierpliwość. Przynajmniej nie będziecie narzekać, że mało piszę ;)
Brak komentarzy:
Prześlij komentarz
Uwaga. Komentarze są moderowane i mogą nie pojawić się natychmiast po utworzeniu. Autor niniejszego bloga zastrzega sobie prawo do niedopuszczenia komentarzy będących SPAMem i/lub nie odnoszących się do komentowanego wpisu i/lub łamiących zasady kulturalnej wymiany opinii.