Dawno, naprawdę dawno temu… Kiedy nie było jeszcze problemu internetowych wojen między zwolennikami Linuksa i Windowsa… Z tej przyczyny rzecz jasna, że oba systemy jeszcze nie istniały. No i nie było internetu. Tak czy owak, całe lata temu, pewien filozof powiedział mniej więcej tak: „kiedy człek prawdziwie boży spędza noc w karczmie – staje się ona jego klasztorną celą, kiedy pijak zamieszka w klasztorze – staje się on jego karczmą”.

Zachęcam do zastanowienia się nad powyższym, ten artykuł jest jednak „o komputerach”, a nie o filozofii. Z drugiej strony, nie mogłem sobie odmówić przytoczenia tego stwierdzenia, gdyż jak ulał pasuje do zwięzłego zdefiniowania problematyki użycia pamięci USB jako nośnika dla dystrybucji typu LiveCD.

SLAX na pamięci USB

Kiedy piszę ten artykuł, w sklepie niedaleko miejsca w którym przebywam, bez żadnych problemów można kupić pamięć USB o pojemności 16 GB (pamięć zwaną również: PenDrive, USB Flash Drive, Flash Disk, FlashDrive, Finger Disk, Massive Storage Device, Flash Memory Stick Pen Drive – wiadomo już chyba, o co chodzi?). Oczywiście komfort ma swoją cenę. Cenę, której nie ma sensu wymieniać, gdyż jeśli chodzi o to medium – zmienia się ona szybciej, niż moda na określony kolor damskich pantofelków. O ile jednak przyjemność posiadania pamięci o wspomnianej pojemności wymaga (na razie) sporych nakładów finansowych, o tyle zakup układu o pojemności 1 GB nie stanowi dużego obciążenia, nawet dla osób nie posiadających stałego źródła dochodów (czyli, na przykład, biednej braci studenckiej). Układ taki wystarcza w zupełności jako nośnik dla lekkiej dystrybucji Linuksa zostawiając sporo miejsca na dane.

Bez zbędnego kluczenia przejdźmy do konkretów: jak uruchomić SLAX-a 6.0 (RC 6) z pamięci USB? To proste. Należy zrobić, co następuje:

W środowisku DOS/Windows:

1. Skopiować na nośnik USB całą zawartość płyty. Zakładam tutaj, że posiadamy sformatowany uprzednio nośnik (najlepiej użyć systemu plików z rodziny FAT, np. FAT32).
2. Z owego nośnika uruchomić skrypt bootinst.bat znajdujący się w katalogu boot, jako parametr podając oznaczenie literowe tego nośnika. Na przykład, jeżeli nasza pamięć USB figuruje w okienku „Mój Komputer” pod literą E:, w „czarnym okienku” wiersza polecenia, należy wykonać:
   E:>boot\bootinst.bat E:
3. Gotowe. Mamy przygotowany nośnik.

W środowisku Linux:

1. Skopiować na nośnik USB całą zawartość płyty. Zakładam tutaj, że posiadamy sformatowany i zamontowany uprzednio nośnik (najlepiej użyć systemu plików z rodziny FAT, np. FAT32).
2. Z owego nośnika uruchomić skrypt bootinst.sh znajdujący się w katalogu boot. Czyli, na przykład, jeśli nasza pamięć USB zamontowana jest w /mnt/usb:
   # cd /mnt/usb/boot
   # ./bootinst.sh
3. Gotowe. Mamy przygotowany nośnik.

W wersji SLAX-a 5.1.8.1 mamy do dyspozycji analogiczny skrypt: make_disk.bat (lub make_disk.sh - dla Linuksa), z tą różnicą, iż znajduje się on w katalogu głównym płyty i sam kopiuje pliki na wskazaną pamięć USB lub dysk twardy.

Proste? Proste, ale proszę BARDZO uważać! Podczas wykonywania skryptu bootinst do sektora rozruchowego pamięci USB wgrywany jest odpowiedni program ładujący (wyjaśnienie poniżej). Jeśli skrypt ten zostanie wykonany dla innego dysku – nadpisze program, który już znajduje się w jego sektorze ładującym. Znaczy to mniej więcej tyle, że wywołanie skryptu dla dysku C: spowoduje, iż nie będzie możliwe uruchomienie systemu Windows! Analogicznie, jeśli przykładowo /dev/sdb oznacza akurat dysk Serial ATA – możemy nie uruchomić Linuksa!

Jeżeli wszystko poszło pomyślnie, możemy teraz uruchomić system z pamięci USB (o ile, rzecz jasna, nasza płyta główna daje taką możliwość). A teraz najważniejsze pytanie:

SLAX

Co uzyskaliśmy?

Odpowiedź brzmi: LiveCD – bez CD. Podobnie jak wspomniany na wstępie „prawdziwie święty człowiek” nie przestaje być święty w obcym dla siebie miejscu, tak dystrybucja LiveCD nie zmieni swoich własności po skopiowaniu na pamięć USB. Liczy się dusza – chciało by się rzec. W poprzednim artykule SLAX 6.0… jak to działa? wspomniałem, że pliki dystrybucji SLAX przechowywane są w pliko-partycjach, i że użyto tutaj systemu plików SquashFS. Systemu tylko do odczytu – przypominam. Trzydziestomegabajtowa pliko-partycja, która ze swojej natury nie posiada funkcjonalności zapisu, nie posiada jej bez względu na to, czy fizycznie jest położona na płycie CD, talerzu twardego dysku, czy w elektronicznym układzie pamięci USB. I, tak czy siak, zajmuje trzydzieści megabajtów. Konkludując: katalog /home, zawierający pliki użytkownika, nadal nie nadaje się do trwałego zapisu danych.

Osobnym tematem jest to, że mimo, iż dysponujemy nośnikiem, który dopuszcza zapis, nadal nie mamy do dyspozycji partycji wymiany. Można ją oczywiście „dorobić”, ale z drugiej strony… Piętą achillesową pamięci USB jest, jak wiadomo, kasowanie danych, a na partycji wymiany dane są zapisywane i kasowane częściej, niż często. Umówmy się, że jak na razie, partycja wymiany na pamięci USB nie jest najszczęśliwszym pomysłem.

Czy zatem użycie pamięci USB jako medium dla dystrybucji Live jest pozbawione sensu? Pomyślmy:

• Cały system pracuje nieporównywalnie szybciej.
• Dodawanie nowych modułów jest o wiele prostsze. Podczas ich pobierania, jako katalog docelowy, można przecież wskazać bezpośrednio slax/modules.
• O ile tylko nie zapomnimy, które katalogi nie są ulotne – możemy trwale zapisać wyniki swojej pracy. Możemy też, posługując się mechanizmem UnionFS/aufs, „dokleić” do systemu tylko do odczytu katalogi z pamięci USB dające możliwość zapisu. Potrzeba tylko pewnej wprawy w posługiwaniu się poleceniem mount.
• Mamy także możliwość trwałej i względnie łatwej modyfikacji zawartości poszczególnych modułów (dostępne są odpowiednie narzędzia). Nie napisałem przecież, że modyfikacja plików w /etc nie jest w ogóle możliwa. Jest po prostu utrudniona – zawartość skompresowanego modułu należy rozpakować, zmodyfikować odpowiednie pliki i na powrót je skompresować.

Nie można jednak zapominać, że jedyne co uzyskujemy, to polepszenie parametrów pracy, a nie jakaś nowa funkcjonalność. Analogiczne efekty dałby hiper-szybki napęd optyczny wraz z jakąś hipotetyczną, pojemną dyskietką, bądź pamięcią USB właśnie, którą przy pomocy mechanizmu UnionFS/aufs scalalibyśmy z systemem plików tylko do odczytu.

Teraz bardzo krótko na temat:

Jak to działa?

Jak wiadomo, pierwszym programem, który wykonuje się po naciśnięciu guzika zasilania w komputerze jest BIOS. Jednym z zadań BIOS-u jest wywołanie, zgodnie z zapisaną konfiguracją, programu ładującego system operacyjny. Program ten, zwany z angielska bootstrap (lub też bootloader albo bootstrap loader) zapisany jest w początkowym sektorze nośnika – tak zwanym Master Boot Record (MBR) lub Master Boot Block i zajmuje pierwsze 512 bajtów. Dokładniej, bootstrap zajmuje pierwsze 446 bajtów, dalej zaś zapisane są informacje o partycjach znajdujących się na dysku (tablica partycji). Oczywiście MBR, ani tym bardziej bootstrap, nie są widoczne podczas przeglądania zawartości żadnej partycji. Po prostu nie są częścią żadnej z nich a stanowią niejako instancję nadrzędną.

Tak na marginesie – skąd nazwa bootstrap (ang. „sznurówka”)? Dawno temu (ale już po sformułowaniu cytowanego na początku stwierdzenia filozofa), komputery były trochę bardziej prymitywne niż dziś. Każde z urządzeń posiadało oczywiście odpowiedni program obsługi i ogólnie wszystko działało, ale początek pracy był problematyczny. Na starcie systemu komputer był ślepy i głuchy, gdyż odpowiednie programy obsługi trzeba było właśnie załadować. Rozwiązano to bardzo prosto. Gdzieś na gwoździu w pomieszczeniu komputera, (a do małych ono nie należało), wisiał długi pasek papieru z naniesionym kodem rozruchowym. Pasek ów trzeba było ręcznie przeciągnąć przez odpowiedni czytnik, który przekazywał zapisany nań program i umożliwiał dalsze, automatyczne już, wykonywanie komend. Ten długi, wąski pasek nazywano właśnie bootstrap (nie, nie wiem tego z autopsji – jestem jednak ciut młodszy).

Obecnie mamy nowoczesny BIOS i nikt nie musi męczyć się osobiście. Sama nazwa programu ładującego przyjęła się jednak na stałe. Oczywiście zawartość MBR można sobie obejrzeć. W Linuksie można skorzystać z polecenia ‘dd’. Przykładowo:

# dd if=/dev/hda of=mbr.bin bs=512 count=1

Polecenie pobiera z urządzenia, którego właściwym interfejsem jest plik hda pierwszy 512-bajtowy blok i zapisuje go do pliku mbr.bin Proszę bardzo uważać i pod żadnym pozorem nic nie pomylić, to znaczy nie zapisać zawartości MBR!

Z kronikarskiego obowiązku trzeba jeszcze zaznaczyć, że częstokroć sam malutki programik w sektorze MBR to nie wszystko. W przypadku nowoczesnych implementacji, takich jak LILO, GRUB, NTOS Loader, SILO czy BTX częścią programu są pliki położone w katalogu głównym pierwszej partycji, lub innym określonym miejscu, na przykład w katalogu /boot systemu Linux. Oprogramowanie takie pozwala, jak wiadomo, na wybór ładowanego systemu operacyjnego i co za tym idzie posiada, przynajmniej potencjalnie, rozbudowane pliki konfiguracyjne.

Wracając do tematu, czyli dystrybucji na nośniku USB - zaryzykuję stwierdzenie, że każdą w zasadzie dystrybucję LiveCD można po przekopiowaniu na pamięć USB uruchomić. Dystrybucja taka jest do tego przystosowana, że się tak wyrażę – z definicji, i zadziała. Pod jednym warunkiem. Tym czego brakuje po przekopiowaniu plików na pamięć USB, jest właśnie właściwy program ładujący, którego oczywiście nie ma na nowo zakupionym urządzeniu USB. Wyjścia są trzy:

Pierwsze: twórca dystrybucji sam dostarcza program do wgrania odpowiedniego kodu bootstrap do MBR pamięci USB. Tak zrobił Tomas Mateicek w przypadku SLAX-a. Tak też wygląda sprawa w przypadku np. MCNLive.

Drugie: twórca gdzieś w dokumentacji opisuje, jaki program zastosował. Tak postąpili autorzy Knopperdisk. Do pobrania udostępniono zawartość katalogu głównego pamięci USB, oraz opisano, skąd pobrać odpowiedni program ładujący i jak go zainstalować.

Trzecie: trzeba po prostu samemu „zgadnąć”, jaki program zastosowano. Dla nośników wymiennych stosuje się zazwyczaj „lekki” program ładujący wchodzący w skład pakietu SYSLINUX autorstwa H.P. Anvina. Zawiera on kilka programów rozruchowych, służących do uruchamiania jądra Linux. SYSLINUX uruchomiony z parametrem odpowiedniego dysku umożliwia zainstalowanie programu w jego sektorze rozruchowym.

Jak mniemam, najbardziej pożądaną jest droga gotowych rozwiązań. Przyjrzyjmy się konkretnym dystrybucjom.

Jak to rozwiązali inni?

Myślę, iż najlepszym rozwiązaniem dla początkującego użytkownika jest MCNLive. Ta holenderska dystrybucja bazuje na Mandrivie i przystosowana jest przede wszystkim do pracy na nośnikach USB. Po uruchomieniu z płyty (bądź z maszyny wirtualnej) mamy gotowe rozwiązania do zainstalowania dystrybucji na pamięci USB, trwałego zapisu danych czy zarządzania oprogramowaniem. Warto podkreślić, że MCNLive korzysta (a jakże) z opisywanych w poprzednim artykule modułów SquashFS oraz UnionFS. Ten ostatni „potrafi” automatycznie „zorganizować” trwały zapis danych dla systemu uruchamianego z pamięci USB.

Na szczególną uwagę zasługuje także jedna bardzo przydatna opcja. Otóż zauważmy, iż nie wszystkie płyty główne dają możliwość startu systemu z pamięci USB. Jesteśmy wtedy skazani na dość wolne nośniki optyczne, chyba, że… Zastosujemy rozwiązanie hybrydowe. Instalujemy system na pamięci USB, ale sam jego start realizujemy przy pomocy płyty. W bootloaderze dystrybucji MCNLive przygotowano bowiem i taką opcję. Pamiętajmy jednak, że jest ona skonfigurowana wyłącznie dla MCNLive. SLAX-a czy DSL tu nie uruchomimy.

MCNLive

Pentoo – coś dla wymagających. Sugerując się brzmieniem nazwy można wysnuć poprawny w tym przypadku wniosek, że ta szwajcarska dystrybucja oparta jest o Gentoo. Zawiera ona sporo „brzydkiego” oprogramowania, takiego jak skanery portów, oprogramowanie do łamania zabezpieczeń, czy testowania sieci. Przydatne, pod warunkiem, że zdajemy sobie sprawę z tego co robimy (reguła ta jest z resztą dość ogólna i dotyczy wszystkich tego typu – często nieinformatycznych narzędzi, takich jak noże, strzelby, kije baseballowe itp). Drugą ciekawostką jest to, iż Pentoo używa środowiska Enlightenment – naprawdę wartego obejrzenia.

Pentoo

Knopperdisk – holenderska dystrybucja, tak jak poprzednia oparta na Gentoo. Przytaczam ten przykład nie dlatego, że jest ona jakoś szczególnie prosta w instalacji. Przeciwnie – doskonale ilustruje, jak cały proces wygląda „od kuchni”. Po skopiowaniu zawartości pobranego ze strony domowej dystrybucji archiwum mamy na nośniku następujące pliki:

boot.msg initrd kdisk.sqsh kernel syslinux.cfg

Zwróćmy uwagę na plik kdisk – pliko-partycję SquashFS, oraz szczególnie, na plik konfiguracji syslinux. Samo skopiowanie plików na nośnik nie sprawi bowiem, że można z niego uruchomić system. Należy jeszcze, pobrawszy ze strony kernel.org program syslinux, wgrać przy jego pomocy odpowiedni program do sektora rozruchowego pamięci USB.

Dwie uniwersalne myśli na koniec

Truizmem jest stwierdzenie, że technika prze do przodu w takim tempie, iż ten artykuł lada chwila się zdezaktualizuje. Chciałbym więc zakończyć kilkoma zdaniami o „ponadczasowym” charakterze.

Przede wszystkim – każdy program, już od momentu jego projektowania, jest tworzony w określonym celu i z przeznaczeniem do pracy w określonych warunkach. Sama zmiana nośnika dla dystrybucji GNU/Linux, która miała pracować jako LiveCD, nigdy nie wprowadzi jakiejś nowej funkcjonalności. Może, owszem, spowodować, że system będzie działał szybciej (bądź wolniej), ale SquashFS – system plików tylko do odczytu, systemem tylko do odczytu pozostanie, bez względu na nośnik. Sama zmiana sprzętu to jeszcze nie wszystko. Podobnie jak aplikacja, zaimplementowana dla „zwykłego” procesora, nie zacznie działać szczególnie szybciej na procesorze o stu rdzeniach. Jeśli nawet – nie o liczbę rdzeni tu chodzi.

Po drugie – zawsze najlepszym rozwiązaniem jest rozwiązanie standardowe. Przed napisaniem tego tekstu, poprosiłem siedemnastu moich znajomych o sprawdzenie, czy ich komputery są w stanie uruchomić system z pamięci USB. Bez aktualizacji oprogramowania BIOS-u rzecz jasna. Ogólnie – na 25 komputerów, system z pamięci USB da się uruchomić na 17. A napędy CD mają wszystkie. Wolne, ale działające. Czy trzeba to komentować? Wprawdzie rozwiązania techniczne pozbawione części mechanicznych to przyszłość, ale sądzę, że w niedługim czasie system na tego typu pamięciach będziemy instalowali tak, jak to dziś robimy na „zwykłym” twardym dysku. Teraz jednak, aby uzyskać rozwiązanie uniwersalne, należy przykładowo – na pamięci USB umieścić „właściwy” system a na płycie CD nagrać odpowiednio przygotowany dysk startowy, co udało mi się niedawno zrobić i dla SLAX-a. Ale to już inna historia.

Literatura:

• Strona domowa projektu SYSLINUX
• Strona domowa dystrybucji SLAX
• FTP dystrybucji SLAX
• Strona domowa dystrybucji MCNLive
• Strona domowa dystrybucji Knopperdisk
• Strona domowa dystrybucji Pentoo