Przy okazji aktualizacji systemu z wersji Kubuntu 9.04 do 9.10 przytrafił mi się jak do tej pory największy problem, który skutkował reinstalacją systemu i zmianą konfiguracji sprzętowej komputera. Okazało się, że najnowsze wersje jądra (2.6.31-14, 2.6.31-16) nie potrafią prawidłowo obsługiwać chipsetu HPT370/372.

Zapraszam do lektury!

Mój komputer stacjonarny posiada nieco nietypową architekturę. W obszarze pamięci masowej przedstawia się następująco:

 

Płyta główna, wbudowany kontroler IDE:

kanał IDE1 -> master: nagrywarka DVD nr 1; slave: brak urządzenia
kanał IDE2 -> master: nagrywarka DVD nr 2; slave: brak urządzenia

 

Płyta główna, wbudowany kontroler HPT370:

kanał IDE3 -> master: twardy dysk z partycją systemową (/), partycją /boot, slave: brak urządzenia

kanał IDE4 -> master: brak urządzenia; slave: brak urządzenia

 

Magistrala PCI, kontroler SATA:

SATA1 -> pierwszy twardy dysk macierzy RAID 1

SATA2 -> drugi twardy dysk macierzy RAID 1

 

Pomysł był następujący:

  • jedno urządzenie PATA (IDE) na kanał; wszystkie urządzenia pracują jako master
  • dwie nagrywarki DVD, by maksymalnie przyspieszyć przegrywanie w trybie 'w locie'
  • dysk z systemem operacyjnym w osobnym, wyjmowalnym dysku; w razie awarii wymiana dysku z systemem
  • wszystkie istotne dane mają być przechowywane na programowej (software'owej) macierzy RAID 1 (tryb mirror); w celu dodatkowego zwiększenia elastyczności wykorzystano mechanizm LVM (ang. Logical Volume Manager), który pozwala na przykład na zmianę rozmiaru partycji i organizacji partycji bez utraty danych

 

Do realizacji pomysłu posłużyła mi płyta główna Abit SA6R oparta na chipsecie i815EP wyposażona w dodatkowy chipset IDE (PATA) firmy HighPoint Technologies, HPT370/372, wersja BIOS v2.35. Z do dzisiaj dla mnie niezrozumiałych przyczyn dodatkowy chipset IDE (PATA), a być może BIOS go obsługujący posiada pewne ograniczenia:

  • nie są obsługiwane napędy CD-ROM / DVD
  • system może zostać zabootowany albo poprzez ten kontroler, albo poprzez SATA, przy czym nie bardzo wiadomo, jak ustawić bootowanie poprzez SATA

Pomimo tych ograniczeń wszystko było fajnie i nawet działało do chwili, gdy nie postawiłem dokonać ręcznej aktualizacji dystrybucji Kubuntu. Co prawda płyta główna jest już leciwa i posiada poważne ograniczenia, jak na przykład maksymalna ilość pamięci, którą potrafi obsłużyć, to tylko 512 MB RAM, to znakomicie nadaje się do eksperymentów oraz jako podstawa zapasowego komputera. Z racji wyprowadzonej magistrali PCI służy mi za stację dokującą. W złączach PCI umieściłem kilka kart rozszerzeń z rzadziej wykorzystywanymi interfejsami, jak chociażby FireWire.

Podczas aktualizacji postanowiłem zmienić środowisko graficzne i przejść z KDE na XFCE, czyli zmienić Kubuntu na Xubuntu.

Pliki się zaktualizowały, ale system przestał się uruchamiać. GRUB (wersja '1') wyświetlał niepokojący komunikat 'Error 15', czyli nie mógł odnaleźć pliku z jądrem. Na kłopoty z GRUB-em piosenka... Oczywiście, ale oprócz tego bootowalna płyta cd z dystrybucją SuperGrub. Pozwala ona ręcznie przejść przez proces uruchamiania. Rzeczywiście byłem w stanie doprowadzić do załadowania jądra, jednak proces uruchamiania komputera był przerywany następującymi komunikatami:

Gave up waiting for root device. Common problems:
- Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough?)
- Check root= (did the system wait for the right device?)
- Missing modules (cat /proc/modules; ls /dev)

ALERT! /dev/hd0,2 does not exist. Dropping to a shell!

 

Sprawdziłem wszystkie z przedstawionych podpowiedzi. Nic mi nie pasowało, pomimo że podpowiedź przecież była widoczna na ekranie. Dopiero poszukiwania przeprowadzone z pomocą wujka Google'a pozwoliły mi odnaleźć prawdopodobną przyczynę. Otóż coś zmieniło się w jądrze. Nowe wersje jądra nie potrafią prawidłowo obsłużyć chipsetu HPT370/372. By się o tym upewnić nagrałem na płyty CD obrazy jeszcze dwóch dystrybucji: nowej dystrybucji Xubuntu w wersji 9.10 (Karmic Koala) oraz dystrybucji ratunkowej 'System Rescue CD x86' w wersji 1.3.3. Do podejrzanego kontrolera podłączyłem czysty twardy dysk bez żadnych danych. Uruchomiłem komputer z płyty Xubuntu. Okazało się, że ta płyta nie widzi dysku dołączonego do kontrolera HPT370/372. Następnie uruchomiłem ponownie komputer i tym razem uruchomiłem system z płyty 'System Rescue CD x86'. Tym razem dysk był widoczny...

 

Swoimi problemami podzieliłem się na polskim forum ubuntu: http://forum.ubuntu.pl/showthread.php?t=99427

 

Postanowiłem również wypełnić zgłoszenie problemu (ang. bug report) poprzez usługę Launchpad: https://bugs.launchpad.net/ubuntu/+bug/502269/?loggingout=1

 

Póki co obszedłem problem zmieniając konfigurację urządzeń na następującą:

 

Płyta główna, wbudowany kontroler IDE:

kanał IDE1 -> master: twardy dysk z partycją systemową (/), partycją /boot; slave: brak urządzenia
kanał IDE2 -> master: nagrywarka DVD nr 1; slave: brak urządzenia

 

Płyta główna, wbudowany kontroler HPT370:

kanał IDE3 -> wyłączony w BIOS, brak urządzenia

kanał IDE4 -> wyłączony w BIOS, brak urządzenia

 

Magistrala PCI, kontroler SATA:

SATA1 -> pierwszy twardy dysk macierzy RAID 1

SATA2 -> drugi twardy dysk macierzy RAID 1

 

Do przedstawionej sytuacji znakomicie pasuje słowo regres. Coś, czyli obsługa dysków PATA dołączonych do kontrolera HPT370/372, działała w poprzednich wersjach jądra, ale niestety przestała działać. Szkoda. Ja się przez to do Linuxa nie zraziłem, ale jest to jedno z tych zdarzeń, które karze się głębiej zastanowić nad ideą aktualizacji systemu, jeżeli nie nad ludzkością ;-)
Dodaj komentarz