Mąż ma laptopa, a na laptopie miał Debiana. Debian był po różnych przejściach i kombinacjach, ale działał w zasadzie bez problemów. No... nie działała bezprzewodowa karta sieciowa i nie działał zintegrowany modem, ale oprócz tego problemów nie było. Nie mocno nas to zresztą bolało, bo mieliśmy internet w zwykłych kablach, który zwykle działał.
Pewnego pięknego dnia jeden nasz kolega, taki, co on wszystko z linii poleceń załatwi, dorwał się do tego laptopa i powiedział, że teraz to on uruchomi tą kartę sieciową. Wynik zabawy był taki, że karty sieciowej to on nie uruchomił, ale Debiana zamienił na coś w rodzaju Kubuntu. Przy okazji przestały działać niektóre drobiazgi, jak na przykład montowanie urządzeń za pomocą ikonki na pulpicie (dyski przestały być hd, stały się sd), trackpad dostał świra, ale to się po jakimś czasie opanowało i komputer działał od jakiegoś czasu w sposób dość kontrolowany.
Tak było aż do pewnego październikowego wieczoru 2007, kiedy to znudzony wyskakującymi informacjami o możliwych uaktualnieniach systemu, mąż kliknął zgodę na aktualizację i w ten sposób otworzył szeroko bramę do nowej przygody.
Po aktualizacji komputer został wyłączony, potem został włączony i zobaczyliśmy radosny komunikat:
BusyBox v1.1.3 (Debian 1:1.1.3_3 ubuntu2) Build-in shell (ash) /bin/sh: can't access tty: job control turned off (initramfs)
i w tej pozycji sobie wisiał. Nie bardzo umiałam się dogadać z tą powłoką ash. Wychodziło na to, że ma bardzo ograniczony zestaw komend i nic z niej nie umiałam rozsądnego uruchomić. Nie ma normalnego terminala bash-a, nie mówiąc już o jakichkolwiek okienkach.
Wychodzi na to, że kłopot i to do bardzo sprawnego rozwiązania:
jak to zwykle w takiej sytuacji bywa, kopie ważnych dokumentów były nieporobione, a mąż planował za
kilka dni wyjazd do pracy z tymże komputerem.
Google wyrzucił z siebie, że nasz problem nie był pierwszy, i chyba nie będziemy ostatni w tej kolejce...
Dlatego też postanowiłam napisać ten tekst, aby moim następcom było łatwiej sobie poradzić.
Mądrzejsi niż ja ludzie ustalili, że problem polega na wadliwej generacji systemu rozruchowego initramfs,
która jest spowodowana wadliwą konfiguracją pliku /etc/initramfs-tools/modules, a wszystko przy
okazji wymiany jądra na nowsze.
Po przeedytowaniu tegoż pliku powinno być możliwe ponowne utworzenie systemu initramfs, co
powinno rozwiązać problem.
Lamenty w internecie wskazywały na to, że jedynym gwarantowanym rozwiązaniem problemu jest
uaktualnienie do jeszcze nowszej wersji 7.10 zwanej gutsy gibbon, z kernelem 2.6.22-14,
która całkiem niedawno się ukazała.
Kombinacje z poprzednią wersją z kernelem 2.6.20-16 dawała nadzieję na rozwiązanie problemu,
ale bywały kombinacje sprzętowe, których właściciele tylko lamentowali o pomoc.
Tyle teoria - ale jak i co zrobić? Naprawić i przeinstalować system bez usuwania danych - to nie zdarza się codziennie i nie mam w tym zbyt dużej wprawy.
Najpierw sprawdzenie stanu dysku i partycji:
Windows się uruchamia prawidłowo, Knoppix się uruchamia i pokazuje wszystkie partycje i pliki, które
wyglądają na zupełnie w porządku.
Najpierw myślałam, że wykręcę się Knoppiksem:
Uruchomiłam Knoppiksa, uruchomiłam konsolę, zalogowałam się jako root, uruchomiłam Midnight
Commandera, przeedytowałam nim /etc/fstab, aby mieć dostęp do partycji linuksowej z prawem zapisu.
W linii
/dev/hda4 /mnt/hda4 ext3 noauto,users,exec 0 0zamieniłam "noauto,users,exec" na "noauto,users,exec,rw".
Potem, z tej samej konsoli roota zamontowałam partycję /hda4:
mount /dev/hda4
Sprawdziłam - rzeczywiście partycja była zamontowana w /mnt/hda4
Zgodnie z radą mądrego człowieka wpisałam do /mnt/hda4/etc/initramfs-tools/modules:
# List of modules that you want to include in your initramfs. # Syntax: module_name [args ...] # You must run update-initramfs(8) to effect this change. # Examples: # raid1 # sd_mod piix ide_generic ide_cd ide_disk # blacklist bad driver blacklist ata_piix # prevent unnecessary modules from being loaded (you don't need to do this) blacklist ata_generic blacklist libata blacklist scsi_mod
Niestety, samo
chroot /mnt/hda4 update-initramfs -u
nie przyniosło pożądanego efektu. Po restarcie znów mogłam podziwiać ten sam komunikat wiszącego komputera.
Chroot był potrzebny, aby komenda odniosła skutek dla systemu na dysku, a nie Knoppiksa uruchomionego z płyty.
Inni mądrzy ludzie proponowali w to miejsce (też po uprzedniej komendzie chroot /mnt/hda4):
mkinitramfs -o /boot/initrd.img-2.6.20-16-generic 2.6.20-16-generic
Niestety, wyszły z tego jakieś smętne komunikaty o braku czegoś-tam. Doszłam do wniosku, że więcej już za pomocą Knoppiksa nie zrobię. Widać jedno dziecko Debiana - Knoppix jest jednak inne, niż drugie - K/Ubuntu.
Teraz czasem myślę, że to mogło być wynikiem "uproszczonego" montowania dysku:
było:
mount /dev/hda4
raczej powinno być:
mount -t ext3 /dev/hda4 /media/hda4
Z powodów opisanych dalej w tym tekście.
Wtedy jednak doszłam do wniosku, że muszę sciagnąć płytę LiveCD najnowszego Kubuntu i spróbować z tej strony.
Były dostępne dwie wersje: "alternate" i "desktop". Najpierw spróbowałam "alternate", bo miałaby ona mieć więcej możliwości. Niestety, moje zrozumienie tych możliwości było ograniczone, dlatego spróbowałam, wersji "desktop". Początek był niezły: płyta się uruchomiła prawidłowo z okienkami, internet od razu zaskoczył. Według komputerowych mądrości to oznacza, że system ma szansę się zainstalować. Jednak potem okazało się, że to jednak nie jest podobne do Knoppiksa. Po pierwsze komenda w konsoli "mc" nie dawała żadnego efektu. Bez Midnight Commandera przecież jestem ślepa i głucha... Komenda z konsoli "sudo kate" wywaliła kilka errorów, ale uruchomiła kate z prawami roota. Dobry początek.
Na początek dostęp do dysku.
Otworzyć konsolę. Przejść do katalogu /mnt:
cd /mnt
Utworzyć katalog, do którego zamontuję remontowany system:
sudo mkdir ubu
Wymyśliłam nazwę "ubu" aby była krótka i kojarzyła się z Ubuntu, ale oczywiście nie ma obowiązku tego
powtarzać.
Pamiętałam, że Ubuntu wszystkie dyski nazywa "sd*", bez względu na to, czy są IDE, czy nie są. W świeżo
otworzonym kate z prawami roota poszukałam i otworzyłam /etc/fstab:
unionfs / unionfs rw 0 0 tempfs /tmp tmpfs rw 0 0 /dev/sda3 swap swap defaults 0 0 #dopisalam linie - u mnie Linux jest na partycji sda4 /dev/sda4 /mnt/ubu ext3 users,exec,noauto,rw 0 0
Niestety, płyta Kubuntu Desktop nie dawała tak wygodnej ściągi z dostępnych alternatyw, jak Knoppix. Dlatego chyba warto obejrzeć dysk najpierw pod Knoppiksem, aby się zorientować w jego podziałach.
Teraz montowanie partycji:
sudo mount -t ext3 /dev/sda4 /mnt/ubu
Z jakiegoś powodu tylko zamontowanie przez sudo i z pełną formułą daje możliwość skutecznego wykonania dalszych operacji. Pewnie jest dla tego jakieś racjonalne wytłumaczenie.
Następnie zmieniamy katalog główny:
sudo chroot /mnt/ubu
Mądrzy ludzie piszą, że już w tej sytuacji można spróbować wydać komendy:
apt-get update apt-get upgradeCo powinno rozwiązać część problemów. Naszych problemów to nie rozwiązało. Logiczne - akurat to uaktualnienie spowodowało problem. Kombinacje z:
Ale, sukcesem zakończyła się w końcu operacja regeneracji initramfs:
sudo mkinitramfs -o /boot/initrd.img-2.6.20-16-generic 2.6.20-16-generic
po uprzedniej zmianie katalogu głównego za pomocą "sudo chroot /mnt/ubu". To znaczy system już
startował, ale nie uruchamiały się okienka i zostawałam w terminalu.
Zostało do wykonania przeinstalowanie systemu - trzeba było zmienić adresy repozytoriów pakietów W /etc/apt/sources.list na dysku wpisałam zawartość /etc/apt/sources.list z płyty za pomocą Kate uruchomionego z konsoli komendą "sudo kate". Oczywiście, każda skuteczna metoda jest dozwolona.
A potem się zaczęło...
apt-get update apt-get upgrade
Wywaliło błędy... No, więc "apt-get install --fix-missing"... Wywaliło błędy... No, więc "apt-get install -f"... Wywaliło błędy... No, więc apt-get dist-upgrade i tak dalej... Trochę to potrwało... W sumie to był chyba gigabajt sciągniętych plików.
W sumie po kilku dniach nawet okienka się uruchamiały.
Potem zostało już dopisanie użytkownika do /etc/sudoers - nie rozumiem, dlaczego to miałoby być lepsze. Nie do końca rozumiałam, dlaczego pojawiło się dużo nowych programów, których przedtem nie było i które po prostu wywaliłam. Nie poskromiłam apletu z paska zadań KDE zmieniającego układ klawiatury w zależności od języka - przestał działać i nie bardzo wiem dlaczego.
Uff... długo to trwało... Pewnie z następnym komputerem byłoby szybciej, robiłabym mniej eksperymentów, które nie przynosiły efektu... Czy można się przed tym zabezpieczyć? Podobno w K/Ubuntu tak: nie należy zgadzać się na aktualizację jądra bez sprawdzenia z płytą LiveCD z planowaną wersją, czy się dobrze uruchamia, bo wtedy to oznacza, ze initramfs jest prawidłowo tworzony na akurat tym komputerze.
Ale tak naprawdę, czy można się przed wszystkim zabezpieczyć? Chyba nie... Chyba najlepszym zabezpieczeniem na wszelki wypadek jest drugi, sprawny komputer z aktualnymi kopiami ważnych plików. A przynajmniej kopie zapasowe na wszelki wypadek. No, i nie panikować, tylko spokojnie czytać, co inni na ten temat pisali w internecie.
Mam nadzieję, że to się komuś przyda, nawet, jeśli pisane trochę nieskładnie. W końcu nie jestem żadnym informatykiem, tylko życie mnie zmusiło do reanimacji jednego laptopa. Nie opisałam wszystkich eksperymentów zakończonych niepowodzeniem, które jednak u innych ludzi, na innym sprzęcie kończyły się pomyślnie.
Odnośniki do mądrzejszych tekstów - materiał do przemyśleń:
Laptop po tych operacjach działał jakoś, ale ciągnął się jak smród, łatwo się wieszał i to tak gruntownie, że tylko twardy restart działał. Przy poważnej pracy na większych plikach to było zdecydowanie nieprzyjemne.
Wywaliliśmy ileś śmiecia, kombinowaliśmy ze sterownikami karty graficznej, ale nic w zasadzie nie pomagało. Laptop z procesorem Intel 915 i 512MB RAM z Kubuntu działał gorzej niż nasza druga stacjonarna maszyna Pentium II 266MMX i 128 MB RAM ze stabilnym Debianem.
Kiedyś, po kilku miesiącach, w końcu się mi znudziły stwierdzenia, że coś z tym trzeba zrobić -
potanowiłam coś z tym zrobić. Żeby zidentyfikować procesy zjadające procesor i pamięć użyłam
na konsoli polecenie "top" i okazało się, że system nie ma pamięci swap, mimo, że partycja
swap miała 1 gigabajt.
Wniosek - zbliżamy się do przyczyny problemu.
Znalazłam internetową pomoc Ubuntu
na temat partycji lub pliku swap, wykonałam zalecane zabiegi magiczne i... nic, bez efektu.
Użyłam nawet nowego GParted LiveCD do wywalania, tworzenia i formatowania partycji swap i... nic.
swapon -a wywalał tylko błędy o brakach.
W końcu znalazłam rozwiązanie - nieracjonalne, ale działa. Niewykluczone, że przeformatowanie partycji swap też było pożyteczne.
K/Ubuntu traktuje formalnie dyski i partycje jako scsi i oznacza je jako sd*.
W katalogu /dev nie było urządzeń sd*, ale były hd*.
W pliku /etc/fstab partycje były oznaczone jako sd*.
System jakoś działał i programy jakoś działały, więc system sobie z tym jakoś radził. Jednak
swap nie działał, więc system sobie z tym nie radził.
Wykonałam eksperyment nieracjonalny: w pliku /etc/fstab zamieniłam oznaczenie urządzenia partycji swap z /dev/sda3 na /dev/hda3
I zaskoczyło!
swapon -a nie wywalił błędu.
Komenda free pokazała aktywną pamięć swap.
Kiedy to piszę, laptop jest używany już kilka godzin i jeszcze się nie zawiesił.
Niektórzy mówią, że jest to typowe połączenie teorii z praktyką:
działa, ale nie wiadomo dlaczego.
W styczniu 2008 instalowałam nowego, stabilnego Debiana Etch z płyty DVD z czasopisma Linux+. Ponieważ komputer docelowy był powolny i nie miał stacji DVD, dlatego wyjęłam docelowy dysk ze starego komputera i włożyłam go do znacznie szybszego, który na dodatek miał napęd DVD
A, że podpięłam go tak, że system go widział jako hdc, a nie hda - to nie problem. Potem myślałam, że trochę pogrzebię i sprawa się wyprostuje w drugim komputerze. W zasadzie to była prawda: wystarczyło zmienić wpisy w /boot/grub/menu.lst oraz /boot/grub/device.map i już system startował prawidłowo.
Potem zrobiłam "apt-get update", "apt-get upgrade" i system się zaktualizował bez kłopotów. Widać było, że pozostały jeszcze do zrobienia uaktualnienia jądra i kilku innych programów. Zrobiłam "apt-get dist-upgrade", po zakończeniu wyłączyłam komputer i następnego dnia, po włączeniu komputera zobaczyłam znajome:
/bin/sh: can't access tty: job control turned off (initramfs)
Zaczęłam trenować powyższe procedury, w różnych wariantach, przez wiele godzin, bez
powodzenia, aż nagle mnie oświeciło: przecież komputer wypisywał za każdym razem
kilka linii wyżej:
/dev/hdc1 not found
no więc jak miał startować? Nie wiem dlaczego /boot/grub/menu.lst miało przywrócone oryginalne
ustawienie dysku startowego z pierwotnej instalacji na innym komputerze. Zamiana "hdc" na "hda"
w tym pliku rozwiązała problemy.
Wniosek: należy czytać, co komputer wyświetla na ekranie. Być może te napisy mają sens...
Powodzenia :-)
Basia Głowacka 10.01.2008
e-mail:jastra@ jastra.com.pl
==============================
