Okołozimowo: hibernacja w F9

Jak zapewne użytkownicy Fedory i zapewne innych dystrubucji dobrze wiedzą, hibernacja pod Linuksem ma się dobrze.
Niestety, brak paska postępu wprowadza niepewność, czy aby na pewno komputer przechodzi w stan hibernacji, czy nie.

Dobrym sposobem na rozświetlenie sytuacji jest skorzystanie z projektu zwanego TuxOnIce (lub też Suspend2) wraz z odpowiednim userUI.

Korzystający z fedory mogą skorzystać z repozytorium Matthiasa Henslera, wystarczy zapisać plik repozytorium do katalogu /etc/yum.repos.d/

Jak zapewne użytkownicy Fedory i zapewne innych dystrubucji dobrze wiedzą, hibernacja pod Linuksem ma się dobrze.
Niestety, brak paska postępu wprowadza niepewność, czy aby na pewno komputer przechodzi w stan hibernacji, czy nie.

Dobrym sposobem na rozświetlenie sytuacji jest skorzystanie z projektu zwanego TuxOnIce (lub też Suspend2) wraz z odpowiednim userUI.

Korzystający z fedory mogą skorzystać z repozytorium Matthiasa Henslera, wystarczy zapisać plik repozytorium do katalogu /etc/yum.repos.d/

Następnie instalujemy pakiety userui-tuxonice-* (wersja tekstowa i graficzna ui wraz z wszystkimi dostępnymi pakietami theme – oczywiście, po zapoznaniu się z themami możemy usunąć niepodobające się lub stworzyć samemu theme) z repozytorium, pobieramy kernel z wkompilowaną obsługą suspend2 (sudo yum install kernel-tuxonice) wraz z wszelkimi potrzebnymi zależnościami.

Uruchamiamy ponownie system z jajkiem z wkompilowanym tuxonice. Przełączamy się na konsolę tekstową (ctrl+alt+f1), sprawdzamy poprawność instalacji /sbin/tuxoniceui_text -t oraz /sbin/tuxoniceui_fbsplash -t.
Powinny się wyświetlić odpowiednie (tekstowe lub graficzne) paski postępu procesu hibernacji.
Uwaga: Jeśli chcemy korzystać z graficznej wersji ui, musimy dodać w /etc/grub.conf jako parametr do kernela vga=(odpowiedni tryb graficzny, dla 1024×756×32b wynosi 318, możemy też wyświetlić wszystkie dostępne tryby za pomocą vbetest).

Teraz możemy skonfigurować sam proces hibernacji, w pliku /etc/hibernate/suspend2 możemy ustalić typ hibernacji, możliwość anulowania hibernacji, ponowne uruchomienie komputera po hibernacji oraz wiele innych.
W chwili obecnej interesuje nas opcja ProcSetting userui_program – usuwamy znak komentarza przy interesującej nas opcji (/sbin/suspend2ui_fbsplash – graficzne ui, /sbin/suspend2ui_text – tekstowe).

Po zakończeniu konfiguracji, uruchomienie jako root polecenia hibernate powinno poskutkować wyświetleniem odpowiedniego paska postępu procesu hibernacji oraz oczywiście zahibernowaniem systemu.

Więcej szczegółów odnośnie instalacji oraz konfiguracji TuxOnIce możemy znaleźć na stronie www.tuxonice.net

F9 i Asus A6KM-Q097

To już 2 tygodnie minęły od wydania kolejnej, 9-tej odsłony Fedory, czas na podsumowanie.

Modele z serii A6km, podobnie jak wiele dzieci Asus’a, cierpią na chroniczne problemy z bios‘em – a konkretnie z tablicą DSDT. Błędny wpis w DSDT skutkuje niemożnością uruchomienia jakiejkolwiek (no, bez przesady, odpowiedni patch [acpi-dsdt-initrd-vX-2.X.X.patch] mają Ubuntu oraz Mandriva) dystrybucji linuksa gdy podczas bootowania podłączone są urządzenia USB.

To już 2 tygodnie minęły od wydania kolejnej, 9-tej odsłony Fedory, czas na podsumowanie.

Modele z serii A6km, podobnie jak wiele dzieci Asus’a, cierpią na chroniczne problemy z bios‘em – a konkretnie z tablicą DSDT. Błędny wpis w DSDT skutkuje niemożnością uruchomienia jakiejkolwiek (no, bez przesady, odpowiedni patch [acpi-dsdt-initrd-vX-2.X.X.patch] mają Ubuntu oraz Mandriva) dystrybucji linuksa gdy podczas bootowania podłączone są urządzenia USB.

Oczywiście, błąd leży po stronie producenta – on powinien wypuszczać poprawne wersje bios’u. Niestety, ostatnią poprawną(?) wersją jest 202, kolejne wersje zawierają już ten bug, aż do 300 włącznie.

Sposobów na obejście tego problemu jest kilka – od zmiany biosu na wersję 202 (niezbyt polecane), po rekompilację i patchowanie kernela oraz ręczna naprawa tablicy DSDT, wyłączania obsługi ACPI (co w laptopie jest samobójstwem), aż po odłączanie urządzeń USB podczas bootowania.

Po niezbyt udanej rekompilacji i patchowaniu kernela, doszedłem do wniosku, że dla poprawy zdrowia psychicznego pozostawię to jak jest, wybierając bramkę nr 4 (czyli odłączanie urządzeń USB).

Poza tym powtarzającym się z wersji na wersję problemem (co prawda nie zawinionym przez twórców kernela oraz twórców dystrybucji), Fedora nadal jest dystrybucją która najbardziej odpowiada moim gustom.

Instalacja z wersji na wersję coraz prostsza, domyślnie włączone do dystybucji acpi4asus (obsługa klawiszy funkcyjnych, diod led etc), poprawiony NetworkManager, poprawiona obsługa karty Broadcom Corporation BCM4318 (wystarczy wypakować firmware do /lib/firmware), bezproblemowa obsługa dongle Bluetooth, czytnika kart SD, skalowanie częstotliwości procesora etc.

Jedyne, co mnie boli, to zrobienie z Fedory poligonu do testowania nowych rozwiązań (jak np wersja beta xorg, co nie pozwala zainstalować sterowników nvidii, czy korzystania z synaptics). Dobrze, że firefox 3 b5 jest na tyle stabilna, że to nie pogarsza nadszarpniętego wizerunku dystrybucji.

Na plus:
ulepszony proces instalacji, działający z pudełka pulseaudio (co poprzednio nie było tak oczywiste), odczuwalna poprawa szybkości uruchamiania i zamykania systemu.

Na minus:
stawanie się poligonem doświadczalnym dla RHEL

Może jest ktoś, komu udało się spatchować kernel F9 patchem acpi-dsdt-initrd? Proszę o kontakt, może w końcu dowiem się jakie błędy popełniłem przy patchowaniu.

Aktualizacja-problem-Fedora 8.

Fedora 8 (a konkretnie yum z opcją update) ma małe problemy z rozwiązywaniem zależności między pakietami, a konkretnie podczas aktualizacji kernela – jako, że nowy kernel nie jest nadal zainstalowany, jest zaznaczany jako brakujący podczas aktualizacji xorg-drv-nvidia oraz ndiswrapper.
Tymczasowe rozwiązanie jest proste:
Odinstalowanie bieżących pakietów xorg-drv-nvidia wraz z kmod-nvidia, a także ndiswrapper.

yum remove xorg-drv-nvidia kmod-nvidia ndiswrapper
yum update
yum install xorg-drv-nvidia kmod-nvidia ndiswrapper.

Podrążę trochę temat, może to nie błąd a feature 😉

Znalezione na wykopie:
błąd - feature

VMware Server 1.0.4 i kernel 2.6.23.1.49.

Dla potrzeb testów zainstalowałem vmware (wersja 1.0.4) na Fedorze 8.
Nie ma jeszcze w tej wersji odpowieniego modułu do kernela (vmmon), należy je skompilować.
Aby to zrobić, potrzebujemy patcha http://platan.vc.cvut.cz/ftp/pub/vmware/vmware-any-any-update114.tar.gz
Po tym wszystko już jest bezproblemowe 😉

Oczywiście nie ma wsparcia dla jakichkolwiek sensownych systemów obsługi dźwięku – alsa, oss, pulseaudio – przynajmniej mi nie udało się znaleźć takowego.

Fedora 8 (x86-64) vs Asus A6Km.

Nowa Fedora pobrana, zainstalowana, czas podzielić się problemami, na które można się natrafić.

  • Nadal ciągnie i zawiewa od dziury w biosie, której ASUS nie ma zamiaru poprawić (ostatnia wersja biosu to 300, błąd nadal istnieje), niestety, wersja kernela zastosowana w Fedorze nie jest odpowiednio spatchowana, trzeba naprawić tablice DSDT, link do instrukcji: www.cpqlinux.com/acpi-howto.html Inne rozwiązania: wyłączać przed uruchomieniem komputera wszystkie urządzenia USB.
  • brak stablilnego sterownika do kamery
  • pokręcone SELinux – póki co nie mam pojęcia dlaczego blokuje on aż tyle rzeczy, ale popracuję nad tym
  • nadal nie ma domyślnie zainstalowanego pluginu presto dla yum’a (ciągle jest w wersji beta), jego instalacja nie jest problemem – yum install yum-presto, konfiguracja repozytoriów: https://hosted.fedoraproject.org/projects/presto/, ale zwykły użytkownik może nigdy nie dowiedzieć się że istnieje takie narzędzie

Z dobrych rzeczy:

  • Pulseaudio – gra i śmiga (audacious, mplayer, flash), konfiguracja: http://www.pulseaudio.org/wiki/PerfectSetup
  • karta sieciowa (bezprzewodowa) – sterowniki są w jądrze, bcm43xx zmieniło się w b43, iwlist, iwconfig działają bez zarzutu, niestety, NetworkManager sobie nie radzi :/
  • nvidia jak to zwykle, działa bez zarzutu, w dodatku w trybie TwinView

Więcej grzechów nie pamiętam, cała reszta wyjdzie w praniu… (jeszcze nie przetestowałem kart mmc/sd, pcimcia)…

Oszczędnością i pracą…

Jedną z ciekawych nowości, które mają pojawić się w nowej Fedorze – 8, a czego mi brakowało w Fedorze 7, jest plugin do yum’a – Presto (odpowiednik deltarpm dla OpenSUSE).
Pozwala on ściągać deltaRPMy, czyli podczas aktualizacji ściąga tylko różnice pomiędzy pakietami, oczywiście w miarę możliwości.

Podczas aktualizacji systemu po półtorej miesiąca przerwy, można się załamać patrząc na łączną wielkość wszystkich pakietów (ponad 700MB w moim przypadku).
Przy aktualizacji z użyciem pluginu Presto, rozmiar znacznie się zmniejszył, do 132MB, co oznacza skuteczność rzędu 80%!

Pomimo ostrzeżeń, że jest to wersja nadal testowa, do tej pory nie miałem żadnego przykrego problemu z tym pluginem, więc mogę go z pełnym przekonaniem polecić innym użytkownikom Fedory w wersji 7.

Więcej na ten temat: https://hosted.fedoraproject.org/projects/presto/wiki/WikiStart