debian, linux, system

Podczas wszystkich działań używana będzie powłoka bash. Generalnie, przy innych powłokach, czynności będą wyglądać tak samo. Jeżeli jednak używamy innej powłoki, to należy wziąć pod uwagę na przykład różnice w sposobie ustawiania zmiennych środowiskowych (environment vairables).

W przykładach, gdzie występują polecenia wprowadzane do powłoki, będzie używana notacja, która sugeruje od razu, czy wykonujemy czynność jako root, czy jako zwykły user:

$export .....// polecenie wydane jako zwykły user.

#export .....// polecenie wydane jako root.

Dodatkowe komentarze do poszczególnych komend zaczynają się w tej samej linii i oddzielone są dwoma znakami '//' (tak jak w powyższym przykładzie).

Co się wydarzyło

Z powodu nagłego zaniku napięcia nastąpiło nagłe wyłączenie naszego komputerka. Niestety po ponownym włączeniu system już nie chciał się załadować. Podczas rozruchu, po wybraniu wariantu w menu LILO, pojawiał się komunikat:

kernel too big ...

Rozeznanie w sytuacji sprzed zaniku napięcia wykazało następujące czynności, które w konsekwencji doprowadziły do powyższych problemów.

Do komputera podłączonych było zdalnie, poprzez ssh, kilka grup przeprowadzających równocześnie konfigurację różnych usług. Jedna z nich zabrała się w tym celu do rekompilacji jądra aby nałożyć wymagane dodatkowe łaty. Wykonali co następuje:

1.Na istniejący w katalogu /usr/src kod jądra 2.4.28 nałożyli łatę (bez zrobienia kopii sprzed patch'owania).

2.Przeprowadzili ponowną rekompilację jądra.

3.Nie przeprowadzali rekompilacji modułów

4.Podmienili plik z bieżącym, prawidłowo działającym jądrem 2.4.28 na nowe (bez zrobienia kopii).

W tym momencie zaskoczył ich zanik napięcia !!!

Nie wykonali więc operacji #lilo.

Po ponownym uruchomieniu komputera LILO rozpoczął ładowanie jądra, ale stwierdził, że jego rozmiar nie pasuje do tego co ma zakodowane (rezultat fizycznej podmiany z pkt. 4), dlatego wyrzucił z siebie nie do końca jasny komunikat kernel too big...

Jak zawalczyliśmy o uratowanie systemu

W pierwszym oczywistym odruchu przeprowadzona została próba rozruchu systemu z jądrem v2.2.0. Niestety okazała się ona nie do końca udana. Owszem jądro zostało prawidłowo przez LILO załadowane ale potem to już była tylko seria porażek w postaci komunikatów, że nie da się zlokalizować podstawowych plików konfiguracyjnych. Wyglądało tak jakby poszczególne partycje na dysku odmówiły posłuszeństwa.

Odpowiedzią na ten stan rzeczy był system plików ext3, który został włączony na wszystkich partycjach oprócz '/' (na szczęście - see Stan początkowy, pkt 3). A niestety nasze jądro v2.2.0 nie obsługiwało go i dlatego przy starcie systemu nie było dostępu do takich ścieżek jak /usr, /var, ...

PROBA 1

Nie mieliśmy dyskietki startowej, tak więc odpaliliśmy komputer z płyty System Rescue CD-ROM (see: http://www.sysresccd.org/index.en.php). Bez problemu dostaliśmy się do partycji /dev/hda4 ('/') i zaczęliśmy próby z przywróceniem działającego jądra 2.4.28.

Niestety nie mieliśmy kopii działającego jądra (zostało nadpisane bez kopii), dlatego wszystkie nasze kombinacje z innymi wersjami, które znaleźliśmy na dysku spełzły na niczym. Za każdym razem LILO uparcie informowało, że kernel too big.... Pomimo tego, że podstawialiśmy mu pliki z działającymi poprzednio prawidłowo jądrami. Wyglądało tak jakby LILO zakodowało sobie informacje o tym konkretnym pliku z jądrem, którego akurat już nie mieliśmy (może po prostu LILO bada wyliczoną przez siebie sumę kontrolną pliku przed załadowaniem?). Wygląda na to, że posiada mechanizm mający uchronić przed brutalną podmianą pliku z jądrem.

W konsekwencji stanęliśmy przed problemem, że mamy działające jądra 2.4.28 ale aby LILO zechciało z któregoś z nich skorzystać, musimy odpalić magiczne #lilo (chodziaż wówczas to była po prostu ostatnia z naszych hipotez). I tu był problem. Nie bardzo wiedzieliśmy jak to zrobić skoro nie możemy normalnie odpalić systemu, a z kolei startując z płyty nie bardzo można było to zrobić (przynajmniej na ówczesny czas nie wiedzieliśmy, że można to zrobić również zdalnie).

Odpaliliśmy system (bez płyty) i wybierając jądro v2.2.0 weszliśmy do trybu single.

Boot: LinuxOLD single

lub

Boot: LinuxOLD S

Podziałało o tyle, że po podaniu hasła root'a mogliśmy wejść na partycję '/'. Niestety okazało się, że nie możemy znaleźć programu lilo, Aby obejść te braki zamknęliśmy system i ponownie odpaliliśmy z płyty System Rescure CDROM. Następnie skopiowaliśmy z płytowego systemu potrzebne pliki bezpośrednio na dysk twardy do roboczego katalogu. Przy okazji okazało się, że mieliśmy dostęp do oryginalnego pliku lilo (/sbin/lilo) ale ponieważ działaliśmy po omacku (nie mieliśmy which'a ani find'a - to wszystko jest w /usr/bin/), to tego nie zauważyliśmy.

Kończąc już, ponownie odpaliliśmy system, weszliśmy do LinuxOLD S i po podaniu hasła do root'a byliśmy ponownie na miejscu. Upewniliśmy się, że plik /etc/lilo.conf wskazuje na odpowiednie pliki z jądrami i wydaliśmy polecenie:

#lilo

Nadeszła chwila ostatecznej prawdy. Nie było przecież pewności, że podmienione jądro będzie dobrze działać. Zresetowaliśmy system...

...I DZIAŁA !!!

PROBA 2

Materiał teraz przedstawiany powstał na bazie prac wykonanych na eksperymentalnym stanowisku (z zainstalowanym tym samym systemem Linux Debian 3.0). Celem było sprawdzenie, czy można było ten problem rozwiązać inaczej, a w szczególności, czy można instalować zdalnie boot-loader LILO. Przeprowadzone próby wykazały, że jest to jak najbardziej możliwe. Dzięki temu możliwe jest uratowanie systemu również w sytuacji kiedy poprzednie konfiguracje nie działają w cale. W naszym przypadku było by tak gdyby partycja /dev/hda4 została również przerobiona na ext3 filesystem.

Poniższy opis zakłada, że w ogóle nie możemy odpalić żadnego starego jądra. Do systemu dostajemy się więc korzystając z płyty System Rescue CD-ROM.

Zaczynamy zabawę Na początek, po rozruchu z płyty, podmontowujemy partycję /dev/hda4 ('/'):

#mkdir /mnt/hdd

#mount /dev/hda4 /mnt/hdd

OK, teraz zacznijmy przygotowania do ponownego zainstalowania LILO. Przy czym będziemy potrzebowali specjalnie przygotowanego pliku lilo.conf

#cd /mnt/hdd/etc

#cp lilo.conf lilo.conf.remote//na podstawie już gotowego lilo.conf tworzymy kopię.

#vim lilo.conf.remote

Teraz wprowadzamy następujące zmiany

install=/boot/boot-menu.b --> install=/mnt/hdd/boot/boot-menu.b

map=/boot/map --> map=/mnt/hdd/boot/map

image=/boot/bzImage-2.4.28 --> image=/mnt/hdd/boot/bzImage-2.4.28

,czyli wszędzie gdzie jest odwołanie do oryginalnej lokalizacji (np. /boot/...) wprowadzamy przedrostek /mnt/hdd (np. /mnt/hdd/boot/...). Powód jest prosty, normalnie partycja /dev/hda4 montowała się jako root ('/') ale my podmontowaliśmy ją jako /mnt/hdd. W sumie jest to logiczne. Pamiętajmy tylko aby odpowiednio zmienić wszystkie ścieżki, a przede wszystkim wszystkie klauzule image=.... (lub zakomentujmy te których nie będziemy używać).

Jak widać pracujemy na oryginalnej partycji, nie wykorzystujemy do tego systemu z płyty.

I to w sumie koniec. Teraz wystarczy już tylko

#lilo -C /mnt/hdd/etc/lilo.conf.remote

(...)

Fatal: creat /boot/boot.0300: Read-only file system

Pojawiający się komunikat o błędzie wynika z tego, że lilo przed nadpisaniem MBR'a chce zrobić jego kopię. W naszym przypadku nie może tego jednak dokonać, ponieważ wystartowaliśmy z płyty i aktualny katalog /boot jest read-only. Dlatego musimy uzupełnić polecenie opcją -s, wskazując miejsce, w którym lilo ma zapisać kopię MBR'a.

#lilo -C /mnt/hdd/etc/lilo.conf.remote -s /mnt/hdd/boot

(...)

I na tym koniec. Restartujemy komputerek, wyjmujemy płytę i na powrót cieszymy się jak system startuje.

Plik /etc/lilo.conf.remote możemy sobie pozostawić, bo i tak przy normalnym wywołaniu #lilo parametry będą czytane z /etc/lilo.conf.

Zobacz także: http://www.storm.ca/~yan/Hard-Disk-Upgrade.html

http://www.telenovela-world.com/~spade/linux/howto/LILO-4.html

Podsumowanie / wnioski

Jak chodzi o administrację:

1.Potrzebna jest dyskietka startowa.

2.Najlepiej, przy większej liczbie osób mających dostęp do poziomu admina zrobić sobie dodatkową kopię, która pozwoli na powrót do działającego stanu.

Jak chodzi o rekompilację jądra:

1.Zawsze zrobić kopię całego /usr/src/linux-.... przed przystąpieniem do patch'owania (łatania) i kolejnej rekompilacji - wystarczy tar'em potraktować.

Pamiętać również o modułach w /lib/modules/x.y.z - przed wykonaniem #make modules_install trzeba również zrobić kopię.

2.Nigdy nie nadpisywać poprzednich, działających, plików z obrazami jądra. Zawsze w /etc/lilo.conf pozostawiać odwołania do poprzednich, działających obrazów (przed wprowadzeniem zmian zrobić kopię do np. /etc/lilo.conf.old).

Dodatek - przygotowanie dyskietki startowej

W podsumowaniu naszej akcji ratunkowej jest mowa o konieczności posiadania dyskietki startowej. Nie powinno więc zabraknąć wzmianki o tym jak do tego się zabrać.

Pobawimy się wiec teraz z dyskietką.

Na początek wypada przygotować samą dyskietkę:

#fdformat /dev/fd0u1440//formatowanie

(...)

Formating ...done

Verifying ...done

#mkfs.ext2 /dev/fd0//utworzenie ext2 filesystem

#mount -t ext2 /dev/fd0 /mnt//podmontowanie

OK, dyskietkę mamy przygotowaną.

Teraz wpakujemy na nią potrzebne materiały:

#cd /boot//ustawiamy się w miejscu, gdzie są potrzebne nam pliki

#cp -dp boot* /mnt

#cp -dp chain.b /mnt

#cp -dp map /mnt

#cp -dp os2_d.b /mnt

#cp -dp bzImage-2.4.28 /mnt //Nasze podstawowe, działające, jądro

OK, zawartość gotowa. Pozostaje jeszcze przygotować boot-sector dyskietki do startowania systemu:

#cd /etc

#cp lilo.conf lilo.conf.fdd //przygotowujemy osobną wersję dla FDD

#vim lilo.conf.fdd

Teraz wprowadzamy następujące zmiany

boot=/dev/... --> boot=/dev/fd0

install=/boot/boot-menu.b --> install=/mnt/boot-menu.b

map=/mnt/map

image=/mnt/bzImage-2.4.28

UWAGA!!!: zmieniamy tylko jedną klauzulę image=, tą która odwołuje się do jądra wgranego na dyskietkę. Pozostałe pozostawiamy niezmienione; możemy się ich całkiem pozbyć pozostawiając tylko te, które odnoszą się od innych systemów operacyjnych.

#lilo -C /etc/lilo.conf.fdd -s /mnt //wypełnienie boot-sectora

#umount/mnt

Na koniec pozostało nam tylko przeprowadzić próbę w real'u jak dyskietka się sprawdzi.

Zobacz także: http://www.storm.ca/~yan/Hard-Disk-Upgrade.html