Boot once w GRUB

Czasami jest potrzeba, żeby uruchomić maszynę z danym kernelem, ale tylko raz. W przypadku niepowodzenia chcemy mieć uruchamiany z powrotem stary, sprawdzony kernel. Zwykle taka potrzeba pojawia się, gdy testujemy nowy kernel i nie mamy fizycznego (lub zbliżonego) dostępu do maszyny, a np. mamy pod ręką kogoś, kto w razie problemów niekoniecznie pomoże z debugiem, ale chociaż wciśnie reset. Dziś pojawiła się u mnie taka potrzeba, za sprawą dedyka pod Piwika i chęci zmiany kernela z nieco starego z OVH na dystrybucyjny.

Okazało się, że wypadłem z tematu. Ostatni raz miałem potrzebę jednorazowego uruchomienia kernela chyba w okolicach LILO jako używanego bootloadera. Nie pamiętam jak to dokładnie w LILO wyglądało, ale mam wrażenie, że było proste, intuicyjne (w końcu jeden konfig) i – przede wszystkim – dobrze udokumentowane.

Poszukałem chwilę i znalazłem polecenie grub-reboot, któremu jako parametr podaje się numer wpisu w /boot/grub/grub.cfg i które ma powodować jednokrotne uruchomienie kernela o podanym wpisie. Ucieszyłem się, że pomyśleli o mnie i tak prosto. Maszynka niekrytyczna, kernel dystrybucyjny, więc raczej wstanie, wydałem więc stosowne polecenie, następnie reboot i… system wstał! Ze starym kernelem.

Nawet niezbyt się zirytowałem. Po prostu odpaliłem testowego kompa w domu i zacząłem się bawić. Ustawiam numer wpisu, który ma się włączyć, reboot i… to samo. Dłuższa chwila szukania i znalazłem opis na niezawodnym wiki Arch Linux:

This requires GRUB_DEFAULT=saved in /etc/default/grub (and then regenerating grub.cfg) or, in case of hand-made grub.cfg, the line set default=”${saved_entry}”.

Jak na lata doświadczeń przystało, wyboru kernela nie pozostawiam przypadkowi i w moim /etc/default/grub były ustawione na sztywno numery kerneli do uruchomienia. Zmieniam na powyższe na testowej maszynie w domu, grub-reboot potem reboot i… wstał! Z nowym kernelem. Świat wydaje się piękny, więc reboot, by wrócić na stary kernel i… tak dobrze nie ma. Uruchamia się za każdym razem z nowym.

Nawet niezbyt się zirytowałem, po prostu rebootnąłem zdalną maszynkę na nowy kernel. Skoro dystrybucyjny to raczej wstanie. Stosowne zmiany, reboot i… maszynka wstała, z nowym kernelem, wszystko wydaje się działać. Misja zakończona, cel osiągnięty.

I tu byłby koniec wpisu, ale w międzyczasie zacząłem rozmowę na ten temat na kanale IRC #debian (@freenode). Tam dowiedziałem się o /boot/grub/grubenv i o tym, że może (będzie) się tak dziać, jeśli nie jest ustawione prev_saved_entry. I faktycznie, nie było. I dowiedziałem się, że można to ustawić wydając polecenie grub-reboot więcej, niż raz.

Czyli, żeby zrobić boot once dla GRUBa, trzeba kolejno:

  • ustawić GRUB_DEFAULT=saved w /etc/default/grub
  • grub-reboot <wpis, gdzie ma być default>
  • grub-reboot
  • sprawdzić /boot/grub/grubenv na wszelki wypadek
  • reboot

I pomyśleć, że przy LILO była to szybka edycja konfiga plus lilo dla wprowadzenia zmian w życie… Znaczny postęp poczyniliśmy! 😉

Skoro już wpis na tematy linuksowe… Archa nie próbowałem, ale ludzie (w tym jeden DD) chwalą. Bardzo dobra dokumentacja. Poza tym, jest taka inicjatywa jak debianfork.org. I cieszę się, że jest. Bo skoro Debian może mieć więcej niż jedną architekturę, więcej niż jeden kernel (tak kFreeBSD), to czemu nie miałby móc mieć różnych, równorzędnych demonów do startu usług?

Bananian, czyli Linux dla Banana Pi

O Banana Pi pisałem już jakiś czas temu. Jeszcze wcześniej narzekałem na Raspbiana, że dziwne opcje ma, że bloat… Cóż, posiadacze Raspberry Pi nie mają specjalnie wyboru, natomiast w przypadku Banana Pi nie ma przeciwskazań, by korzystać z normalnej architektury armhf w Debianie. No dobrze, jest jeden wyjątek, czyli kernel…

Niedawno, po dłuższej, bo blisko dwumiesięcznej przerwie zajrzałem na forum producenta Banana Pi, a tam rzuciła mi się w oczy informacja o wydaniu dystrybucji Linuksa dla Banana Pi o nazwie Bananian. Wesoła nazwa, pomyślałem i stwierdziłem, że może faktycznie na popularności Raspberry Pi przesadnie bazują, skoro nawet Raspbiana przechrzcili… Potem wszedłem na stronkę dystrybucji, doczytałem i… jestem bardzo zaskoczony i zadowolony. Tak naprawdę autorzy poszli w tę stronę, w którą sam planowałem iść.

Czym jest Bananian? Bananian nie ma wiele wspólnego z Raspbianem, poza nazwą. To minimalna wersja (base system, zero raspbianowego bloatu!) Debiana, tuningowana pod Banana Pi (głównie kernel, plus skrypty pomocnicze). Dla pakietów (poza kernelem) korzysta z wyłącznie oficjalnych repozytoriów Debiana, czyli koniec z opóźnieniami w aktualizacjach pakietów (także security). Tuning polega na poprawieniu wydajności i bezpieczeństwa. Normalny swap (niestety włączony domyślnie), bez cudacznych skryptów. Tuning SSH pod kątem zwiększenia bezpieczeństwa zgodnie z wytycznymi z bettercrypto.org. Więcej o zmianach, ficzerach itd. na stronce.

Do tego obraz jest bardzo mały (spakowany poniżej 230 MB, po rozpakowaniu wchodzi na kartę 2GB), a developerzy sprawili na mnie znacznie lepsze wrażenie, niż ci od Raspbiana (bardziej przyjaźni i otwarci na propozycje/wiedzę).  Załapałem się na wydanie nowej wersji i nawet jakieś zgłoszone bugi na forum zostały naprawione (lub dodane do bugtrackera). Zdecydowanie Bananian mi się podoba. Taki minimalny (stronka też). 🙂

UPDATE: Projekt został zakończony, Bananian nie jest już rozwijany.

Smssender 0.9

Odezwał się użytkownik (ha! ktoś jednak tego używa! ;-)), że Mobitex przestał działać i zwraca status 104. Z racji niezbyt wczesnej pory lub po prostu zmęczenia[1], poszukałem pomocy nie u tego dostawcy, co trzeba. Ale albo statusy są zbieżne, albo dobry człowiek sprawdził we właściwej dokumentacji. Status 104, czyli brak zdefiniowanego From. Faktycznie, nie obsługiwałem tego. Tzn. była sobie zmienna w skrypcie, którą można było w skrypcie wyedytować. Niezbyt to piękne, więc w wersji 0.9 dodałem obsługę From w pliku konfiguracyjnym.

[1] Ślady zmęczenia widoczne w githubie, tak to jest jak się siada wieczorem do skryptu nietykanego od ponad roku.