Category: Hosting

Ubuntu i “No init found. Try passing init= bootarg”

Nieprawidłowe wyłączanie komputera może być dość dramatyczne w skutkach. Część z was wie, że jestem właścicielem małego serwera (który tak naprawdę jest zwykłym komputerem ;) ), na którym wykonuję testy aplikacji oraz stawiam wersje developerskie (alfy, bety, itd). Oczywiście robię mu regularne backupy, jednak sami dobrze wiecie, że "pad" jakiegokolwiek komputera to po prostu masa pracy z postawieniem go na nowo. W przypadku serwerka dochodzi konfiguracja na nowo, itd.

Wczoraj w skutek nagłego spadku zasilania - zresetował mi się wspomniany wyżej serwer i niestety... już nie wstał. Dostawałem za to piękną wiadomość:

mount: mounting /dev/disk/uuid/***************************** on /root
failed: Invalid argument
mount: mounting /sys on /root/sys failed: No such file or directory
mount: mounting /dev on /root/dev failed: No such file or directory
mount: mounting /sys on /root/sys failed: No such file or directory
mount: mounting /proc on /root/proc failed: No such file or directory
Target file system doesn't have /sbin/init
No init found. Try passing init= bootarg

Busybox v1.13.3 (Ubuntu 1:1.13.3-1ubuntu7) built-in shell (ash)
Enter 'help' for a list of built-in commands
(initramfs) _

Co się stało? Po prostu "padła" jedna z partycji. Naprawa tego typu problemów nie jest trudna (o ile wysypała się partycja a nie np. padł dysk). Musimy mieć bootowalną wersję Linuksa (na pendrivie lub na płycie CD). Odpalamy takie Live CD a następnie przechodzimy do terminala. Wpisujemy komendę:

sudo fdisk -l 

aby dowiedzieć się jakie partycje mamy na dysku i mamy (przykładowo):

Dysk /dev/sda: 80.0 GB, bajtów: 80026361856
głowic: 255, sektorów/ścieżkę: 63, cylindrów: 9729
Jednostka = cylindrów, czyli 16065 * 512 = 8225280 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512
Identyfikator dysku: 0x85f285f2

Urządzenie Rozruch   Początek      Koniec   Bloków   ID  System
/dev/sda1               1         125     1004031   82  Linux swap
/dev/sda2   *         126        1993    14999552   83  Linux
/dev/sda3            1993        3860    14999552   83  Linux
/dev/sda4            3860        9730    47145985    5  Rozszerzona
/dev/sda5            3860        5728    14998528   83  Linux
/dev/sda6            5728        9730    32146432   83  Linux

Następnie uruchamiamy program fsck na każdej z partycji (tak dla pewności), wykonując następujące polecenie:

# Zmieniamy kolejno na #sda1, sda2, sda3, itd
sudo fsck /dev/sda2

Po tym zabiegu restartujemy serwer i cieszymy się działającym systemem. Następnie zamawiamy UPSa aby taka sytuacja więcej się nie zdarzyła.

Dla pewności, możemy wymusić autouruchomienie fsck przy starcie systemu, wpisując:

sudo touch /forcefsck

Utworzoenie pliku forcefsck w głównym katalogu - spowoduje, że system wstając wykryje go i wykona jeszcze raz testy na partycjach. Po tych operacjach wszystko powinno wrócić do normy.

Odpalanie wielu serwerów z pomocą jednego polecenia

Trafiają się nam projekty, w których wymagane jest uruchamianie kilku (kilkunastu) usług zanim będziemy mogli pracować. Odpalanie tego (i zarządzanie) w kilku oknach jest delikatnie mówiąc niewygodne.

Aby sobie to ułatwić, wystarczy napisać prosty skrypt w Bashu, który dane serwery będzie odpalał bezpośrednio w screenie. Ostatni z odpalanych serwerów pozostawimy "na wierzchu", dopisując kod który w momencie naciśnięcia na nim Ctrl+C (zamknij), wyłączy wszystkie pozostałe serwery. W ten sposób będziemy mogli łatwo i wygodnie zarządzać uruchamianiem i zamykaniem całego projektu. Dodamy sobie także alias tak, aby móc wygodnie wywoływać nasz skrypt.

Załóżmy, że nasz projekt nazywa się Kotowari. Wszystkie tworzone (później) screeny będą zawierać w sobie tę nazwę. Dzięki temu, będziemy mogli je zabić pozostawiając inne pracujące screeny (nie związane z projektem). Zdefiniujemy sobie także pułapkę na Ctrl+C:

trap close_screens INT

function close_screens() {
	kill -9 `ps aux  | awk '/Kotowari/{print $2}'`
	screen -wipe
}

Teraz pora na odpalanie kolejnych serwerów. Serwery które odpalamy przez init.d lub takie które nie potrzebują do pracy konsoli (nie "zostają" w niej), możemy odpalać bezpośrednio czyli:

sudo /etc/init.d/apache2 start;
sudo /etc/init.d/mysql start;

Warto zwrócic uwagę, że nie zostaną one zabite podczas zamykania projektu. Dlaczego to tak zostawiam? Tego typu procesy i tak zazwyczaj chodzą niezależnie od danego projektu i są współdzielone (zazwyczaj są też włączane przy boocie systemu - próbujemy je włączyć tak dla pewności). Oczywiście nic nie stoi na przeszkodzie aby je zamykać w napisanej powyżej funkcji close_screens().

Teraz pora na procesy dedykowane naszej aplikacji i zamknięcie całości:

screen -d -S "Kotowari Proc 1" -m "/sciezka/do/naszego/procesu1"
screen -d -S "Kotowari Proc 2" -m "/sciezka/do/naszego/procesu2"

"/sciezka/do/naszego/procesu3"

close_screens

Ostatni proces nie jest uruchamiany w screenie, ponieważ on ma nam zostać "na" konsoli. Jego zamknięcie zainicjuje funkcję close_screens która zamknie resztę z procesów ukrytych w screenach.

Jeszcze tylko alias:

alias nasz_projekt="/sciezka/do/naszego/skryptu.sh"

Całość:

trap close_screens INT

function close_screens() {
	kill -9 `ps aux  | awk '/Kotowari/{print $2}'`
	screen -wipe
}

sudo /etc/init.d/apache2 start;
sudo /etc/init.d/mysql start;

screen -d -S "Kotowari Proc 1" -m "/sciezka/do/naszego/procesu1"
screen -d -S "Kotowari Proc 2" -m "/sciezka/do/naszego/procesu2"

"/sciezka/do/naszego/procesu3"

close_screens

Copyright © 2025 Closer to Code

Theme by Anders NorenUp ↑