Przejdź do głównej zawartości

Zrób sobie koło ratunkowe

Pamiętam czasy, kiedy obok systemu w komputerze, wiele osób miało dyskietkę ratunkową. Kiedy coś się podziało z systemem, umożliwiała jakiś dostęp do komputera, możliwość naprawy systemu. Zamierzchłe czasy. Im bliżej czasów współczesnych, tym bardziej wielu użytkowników wyzbyło się tej zaradności, która niegdyś powodowała, że system po prostu działał. Teraz system ma działać. Nie ważne co z nim zrobię, do jakiego stanu doprowadzę - on ma działać. Przewidzieć niemal każdą destrukcję, jaką jestem w stanie mu zaserwować - i tak ma działać. Jeśli nie działa, to winna jest zawsze jakaś osoba trzecia. W systemach, które oparte są w dużej mierze na współdziałaniu społeczności, które tworzą różnego rodzaju formuły społecznościowych porad, w takich systuacjach najczęściej pojawia się żądanie takich osób wobec społeczności, by naprawić im to, co sami najczęściej sami zepsuli. Nie mam nic przeciwko temu, bowiem co do zasady, m.in. na tym opiera się istnienie owych społecznościowych systemów. Każdy jednak musi się uzbroić w pewne instrumenty, które umożliwią naprawę systemu samemu.
Poniżej staram się przedstawić kilka podstawowych zasad, które to ułatwią. Pomijam te oczywiste, jak tworzenie kopii zapasowej. Tekst ten jest pisany przez użytkownika systemu Arch Linux, używającego otwartych sterowników oraz GRUB2. I z tego punktu widzenia będzie on pisany. Poniższe porady zatem mogą, ale nie muszą się przydać innym osobom.

1. Zabezpieczmy sobie drugi kernel
Przyznam, że sławetny "kernel panic", użytkując linuksa od bardzo wielu już lat widziałem bodaj dwa razy. Raz, gdy wadliwie skompilowałem sobie kernel. Niemniej jednak nie można usypiać. Zawsze zatem w systemie mam dwa kernele (o ile jakiegoś nie testuję). W przypadku stosowania wolnych sterowników graficznych, większego problemu nie ma. W przypadku zamkniętych, najczęściej konieczne będzie by ów dodatkowy kernel był w tej samej, działającej wersji, albowiem najczęściej moduły dostarczane przez paczki tych sterowników umożliwiają ich instalowanie wyłącznie w kernelu określonej wersji. Zainstalujmy zatem sobie oprócz tego, który używamy na co dzień, jakiś jeszcze jeden. Nie znam programu startowego linuksa, który nie umożliwiłby uruchomienie systemu z innego kernela. Instalując nową wersję kernela, jeśli coś pójdzie nie po naszej myśli i po restarcie spotka nas przykra niespodzianka, najczęściej będziemy mogli wystartować system z drugiego kernela, spróbować dojść do tego co spowodowało destrukcję, naprawić... Przede wszystkim jednak - system zasadniczo będzie nadawał się do pracy.

2. Zabezpieczmy sobie dostęp do systemu w trybie ratunkowym
Niektóre systemy są tak skonfigurowane, że domyślnie w GRUB powstaje pozycja "recovery" ("tryb ratunkowy" itp.). Niekiedy się przydaje. Domyślnie w Arch Linuksie takiej pozycji nie ma (nie będę tu tłumaczyć dlaczego). Nie ma jednak najmniejszego problemu by ją dodać. Po co taka pozycja, jeśli zastosowaliśmy się do poprzedniej rady i do komputera dostęp możemy mieć? Otóż niekiedy umożliwi naprawienie systemu działającego na określonym kernelu. Niekiedy przecież wadliwie zainstaluje się jakieś środowisko, źle wgrają Xy. Sam kernel działać będzie poprawnie. Interwencji wymagać będzie inny element systemu.
Osoby korzystające z GRUB2 zrobią to edytując plik:
/etc/default/grub
Przypominam, że edycję musimy przeprowadzić z uprawnieniami administratora systemu.
W powyższym pliku odszukujemy linię o treści:
GRUB_DISABLE_RECOVERY=true
i zmieniamy ją na:
GRUB_DISABLE_RECOVERY=false
Teraz należy jeszcze utworzyć nowy skrypt GRUB2:
grub-mkconfig -o /boot/grub/grub.cfg
Od tej chwili pośród opcji startowych systemu pojawi się pozycja "recovery", z której będziemy mogli korzystać, gdy będziemy zmuszeni wejść do systemu w celu jego naprawy.
UWAGA: Skorzystanie z powyższej pozycji da nieograniczone możliwości dostępu do systemu, albowiem otrzymamy go na prawach administratora.
Konieczne jest zatem, aby doskonale wiedzieć co się w tym momencie robi. Jeśli nie ma się pewności, to najlepiej od razu przejść na uprawnienia zwykłego użytkownika:
su <nazwa_użytkownika>
3. Naucz się korzystać z chroot
Chroot to narzędzie umożliwiające dostęp z jednego działającego linuksa do drugiego i umożliwiające wykonywanie na nim czynności (w konsoli). Czynności te wykonywane będą bezpośrednio na tym systemie i z użyciem jego instalacji.
By nie przedłużać tego wpisu odeślę do poświęconego tej komendzie, tu jedynie wspomnę, że zawsze warto mieć gotowy dysk ratunkowy.

4. Downgrade
Zdarza się niekiedy, że zaktualizowane aplikacje nie działają tak jak powinny, podczas gdy ich starsze wersje działały prawidłowo. Nie zawsze mamy na tyle czasu, by dociekać co jest przyczyną wadliwego działania i próbować to naprawić, czy też czekać na poprawioną wersję w repozytorium. Pomocne może okazać się narzędzie downgrade lub downgrader. Umożliwi nam ono cofnięcie wersji zainstalowanego pakietu a także ewentualne zablokowanie aktualizacji tak cofniętej paczki.
Pamiętajmy również, że jeśli nie czyściliśmy cache pacmana, to znajdziemy tam także starsze wersje paczek. Ich instalację możemy przeprowadzić wydając polecenie:
pacman -U /var/cache/pacman/pkg/nazwa_paczki
5. Repozytorium Seblu
Pamiętajmy również o istnieniu repozytorium ALA w seblu.net. To archiwum m.in. paczek jakie dla Archa były robione od sierpnia 2013 r. W razie zaistnienia potrzeby prosto możemy stamtąd zainstalować pojedynczą paczkę, a nawet uruchomić sobie Archa z repozytorium na określoną datę.

6. Nauczmy się... podstawowych poleceń
Nie wymaga to komentarza. Tu jednak chciałbym przypomnieć o jednym tylko poleceniu pacmana. Zdarza się, że w naszym systemie zainstalujemy paczki nowsze niż są w repozytorium (z AUR, z repozytorium nieoficjalnego, budując we własnym zakresie). Jeśli zaobserwujemy, że system nie działa jak powinien, nie uruchamiają się jakieś programy, być może warto będzie sięgnąć po polecenie, które umożliwi nam dokonanie aktualizacji wraz z ewentualnym cofnięciem paczek zainstalowanych lokalnie do wersji obecnych na serwerze. W takim przypadku powinniśmy wydać polecenie:
pacman -Syyuu

Wiem, że to wierzchołek góry lodowej, niemniej jednak mam nadzieję, że będzie pomocny. Nie wykluczam, że kiedyś jeszcze powrócę do tego tematu, a o chroocie czytajcie niebawem.

Komentarze

Popularne posty z tego bloga

Na prostej drodze do wysypania Manjaro

Do napisania dzisiejszego wpisu zainspirował mnie jeden z wątków na forum manjaro.pl. Otóż jeden z użytkowników Manjaro chciał zainstalować spotify, którego PKGBUILD dostępny jest w AUR. Akurat ta paczka powstaje przez przebudowanie udostępnianej przez Spotify paczki deb na paczkę Archa. Niestety od pewnego czasu spotify z udostępnionego PKGBUILDu gdyż wersja to 1.0.92.x, która nie jest już dłużej udostępniana przez Spotify. Obecnie udostępniane są 3 paczki, przy czym dla wspieranej architektury w Archu to wyłącznie 1.0.80.x oraz najnowsza 1.0.94.x. Instalacja zatem z takiego PKGBUILDu nie ma najmniejszych szans powodzenia.
Autor wątku chce zaktualizować paczkę, stąd też domniemuję, że jakąś wersję spotify ma.
Inny forumowicz poleca zatem... dodanie repozytorium nexus do systemu (uwaga - poleca dodanie repozytorium budowanego dla Archa do Manjaro!!!), albowiem w tym repozytorium jest najnowsza wersja spotify.
Autor zastanawia się jednak, czy jest to bezpieczne i dochodzi do wniosku, ż…

Plasma i Strażnik Krypt

W czasach, gdy nasza prywatność jest wystawiana na ciężką próbę, jeden z deweloperów KDE postanowił dodać do Plasmy możliwość dość łatwej obsługi szyfrowanych, wirtualnych "katalogów" - krypt, jak je nazywa. Sam projekt nazywa się plasma-vault i po około 3 miesiącach rozwijania pojawiła się w repozytorium unstable KDE najpierw jego wersja 5.9.95, a obecnie 5.9.96. Jak wskazuje numer wersji (choć ten został nadany nie przez opiekuna, ale przez wszędobylskiego Jonathana Riddella), aplikacja była planowana jako część Plasma 5.10. Tak się jednak z jakichś przyczyn nie stało. Obecnie jest ona planowana, jako część nadchodzącego wydania 5.11. Sam program w Archu dostępny jest w AUR. Buduje się całkiem żwawo i działa na tyle, by można zaryzykować jeśli nie używanie, to przynajmniej sprawdzenie działania i zgłoszenie ewentualnych błędów deweloperom. Pamiętajcie by czytać to co po pacman pisze przy instalacji. Program do prawidłowej funkcjonalności potrzebuje bądź encfs bądź cryfs. …

MEGA a sprawa Arch Linux

Mniejsza o to, czy MEGA to popularny, czy godny zaufania itd. itp. dostarczyciel przestrzeni w chmurze. Fakt, że po moich doświadczeniach z dropboksem nie chcę mieć więcej z nim nic wspólnego. Może zatem MEGA, do którego mam dostęp niemal od samego początku? Miłym dodatkiem do MEGA może okazać się uruchomione repozytorium oferujące sam program synchronizujący (megasync) oraz dodatki dla trzech, chyba najpopularniejszych, menedżerów plików: Dolphin, Nautilus i Thunar, umożliwiające synchronizację z plików z ich poziomu. Jest to o tyle miłe, że do tej pory musieliśmy kompilować te programy z AUR, a nadto w przypadku megasync wersja oferowana w repozytorium jest nowsza, zaś dolphin-megasync obecnie w ogóle się nie kompiluje. Chcąc dodać repozytorium MEGA do pacmana, edytujemy plik /etc/pacman.conf i gdzieś na końcu listy dodajemy: [DEB_Arch_Extra]SigLevel = Optional TrustAllServer = https://mega.nz/linux/MEGAsync/Arch_Extra/x86_64/ Nadto musimy jeszcze dodać klucz: gpg --receive-keys BF…