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.

Popularne posty z tego bloga

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…

Ostatnia deska ratunku - uruchomienie linuksa z prawami administratora

Kiedyś już pisałem o tym, że warto sobie za wczasu zrobić ratunkowe koło. Niemniej jednak zwykle Polak mądr po szkodzie. Często czytam, że "po aktualizacji system mi się nie uruchamia". Ów system najczęściej jest utożsamiany ze środowiskiem graficznym. No, to nie do końca "system się nie uruchamia", ten najczęściej się uruchomił, jednakże z jakiegoś powodu nie uruchamia się tryb graficzny. Nawet jednak w takiej sytuacji i również wówczas, gdy nie zadbaliśmy wcześniej o ustawienie sobie pozycji recovery w GRUB będziemy mogli uruchomić "sesję ratunkową", która da nam dostęp do trybu konsolowego na prawach administratora. Wówczas już można zrobić z systemem wszystko co niezbędne. Wystarczy bowiem do linii startowej w GRUB dodać polecenie: systemd.unit=rescue.target i system uruchomi się grzecznie prosząc o podanie hasła administratora. Z sesji tej wychodzimy wpisując: exit i nastąpi dalsze podnoszenie systemu już ze środowiskiem. Pamiętać jednak musimy, że…

Paczki deb i rpm w Archu

Co jakiś czas pojawiają się pośród użytkowników Archa, czy Manjaro rozpaczliwe głosy związane z próbą zainstalowania paczek pochodzących z najpopularniejszych dystrybucji, a w zasadzie paczek oferowanych w formacie deb lub rpm. Najczęściej głosy te pochodzą od bardzo świeżych użytkowników naszej dystrybucji. Co gorsza dotyczą one często sterowników, albo aplikacji, które i tak są oferowane w AUR albo w jakchś repozytoriach.
Ze względu na dostępność w repozytoriach Archa dpkg oraz rpm w ślad za takim "lamentem" idzie cudowna podpowiedź: zainstaluj sobie dpkg/rpm i za pomocą tego menedżera zainstaluj paczkę w systemie.
Czy coś takiego ma szansę powodzenia? Oczywiście. Menedżer paczek jest wszak aplikacją wyspecjalizowaną w m.in. ich instalacji.
I wszystko wydaje się wspaniałe.
STOP.
Niestety nic nie jest wspaniałe. Nie tak się to robi i tak instalacji aplikacji pakowanych dla obcych dystrybucji się nie robi. Kiedy o tym pisałem, spotykałem się z najpopularniejszym pytaniem sze…