Poprzednia strona
Spis
Kolejna strona

Montowanie i oznaczenia urządzeń blokowych

Trochę teorii

Nazwa "urządzenia blokowe" jest umowna i oznacza zwykle urządzenia z którymi komunikacja odbywa się za pomocą pakietów danych nazywanych blokami. Urządzenie blokowe komunikuje się z komputerem najczęściej z użyciem buforów i umożliwia swobodny dostęp do przestrzeni adresowej. Warunki te spełniają dyski twarde, CD-ROM-y, pamięci flash...

Po co motować urządzenia?

W Windows po włożeniu nośnika (płyty do napędu, pendrive do USB, ...) po chwili pojawia się możliwość korzystania z jego zawartości – w Linuksie też, z tym że jak ze wszystkim, nie jest to takie oczywiste. Po dodaniu nowego nośnika nie ma udostępnionej możliwości korzystania z niego (bo niby dlaczego miałaby być?), ta możliwość pojawia się dopiero po zamontowaniu tego nośnika. Montowanie polega na wskazaniu katalogu, w którym ma się pojawić zawartość nośnika. W trakcie montowania można określić różne opcje opcje, na przykład dla pendrive'a będziemy chcieli prawdopodobnie mieć możliwość zapisu.

W dzisiejszych czasach prawie nikt już nie montuje nośników z konsoli. Po prostu wkłada się pendrive'a czy płytę do napędu, pojawia się ikonka na pulpicie i działa. Kiedyś nie było tak dobrze.

W dalszym ciągu możemy mieć jednak do czynienia z sytuacją gdy automatyczne montowanie zawiedzie. Warto też znać oznaczenia linuksowych urządzeń, aby umieć je podać jako argument dla różnych programów działających niskopoziomowo. Następna w kolejności strona wykorzystuje przedstawioną tu wiedzę do wyświetlania partycji na dysku i ich formatowania.

To wszystko brzmi strasznie, ale sprowadza się do zapamiętania bardzo prostego wzoru, który nawet humaniście nie sprawi problemu.

Oznaczenia urządzeń

Może zamiast teoretyzować zobaczmy jak to wygląda w praktyce:

  /dev/sda - primary master
  /dev/sdb - primary slave
  /dev/sdc - secondary master
  /dev/sdd - secondary slave

(w starszych systemach odpowienio /dev/hda, /dev/hdb, /dev/hdc, /dev/hdd)

  /dev/sr0 - pierwszy nośnik wymienny SATA lub USB
  /dev/sr1 - drugi magazyn wymienny SATA lub USB
  ...
  /dev/sr9 - dziesiąty magazyn wymienny SATA lub USB
  ...

(w starszych systemach odpowiednio /dev/sda, /dev/sdb, /dev/sdj)

Oznaczenia primary/secondary master/slave zależą oczywiście od fizycznego ustawienia zworek w na dyskach / napędach (dotyczy tych podłączanych przez gniazda IDE), można je odczytać także na ekranach startowych BIOS-u, takich jak te.

Zamiast zgadywać nazwy urządzeń można wyświetlić sobie zawartość /etc/fstab, dyski twarde zobaczyć testdiskiem, a napędy znaleźć w dmesg lub K3B. Zwykle jednak w komputerze nie ma urządzeń nadających się do montowania w większej ilości niż 6-7, więc jesteśmy w stanie ich nazwę utworzyć sobie w pamięci.

A co z numerkami? Spotkałeś się zapewne z zapisami takimi jak /dev/hda5. Najprościej posiłkować się obrazkiem, który był już umieszczony we wcześniejszym dziale:

Podział na partycję rozszerzoną i dysk logiczny

Kolejne numerki oznaczają kolejne partycje.

Weźmy jakieś praktyczne zastosowanie dla tej wiedzy, oprócz zabawy z partycjami. Kupiłeś sobie nagrywarkę na SATA, która otrzymuje nieznaną w starym KDE nazwę urządzenia (/dev/sr0). Należałoby więc we własnym zakresie utworzyć skrót na pulpicie:

Utwórz nowe -> Dowiązanie do urządzenia -> Nagrywarka CD

Wybieramy odpowiednie urządzenie na zakładce Urządzenie

Montowanie

Uruchamiasz Linuksa w środowisku tekstowym, chcesz włączyć X, jednak zapomniałeś go zainstalować. Wkładasz płytę instalacyjną z pakietami i... nic. No przecież ktoś ją musi zamontować.

Użytkownik nie ma prawa do montowania, dlatego przeloguj się na roota. Następnie poszukaj gdzie ta płyta jest:

blueice root {/home/mk} #dmesg |grep DVD hda: LITE-ON DVDRW SHW-1635S, ATAPI CD/DVD-ROM drive ata2.00: ATAPI: PIONEER DVD-RW DVR-212, 1.28, max UDMA/66 scsi 1:0:0:0: CD-ROM PIONEER DVD-RW DVR-212 1.28 PQ: 0 ANSI: 5 hda: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache

Jest pod hda. Czas poszukać jakiegoś punktu montowania, czyli miejsca gdzie obraz płyty zostanie "odbity" i użytkownik będzie mógł z niego korzystać. Może to być zupełnie dowolne miejsce, ale zwyczajowo przyjmuje się, że płyty montujemy w jakimś podkatalogu /mnt lub /media:

blueice root {/home/mk} #cd /mnt blueice root {/mnt} #ls 1/ cdrom/ floppy/ hd/

Zamontujmy płytkę pod cdrom. W razie braku odpowieniej pozycji możemy zawsze ją utworzyć: mkdir /mnt/cdrom

blueice root {/mnt} # mount /dev/hda /mnt/cdrom/ mount: block device /dev/hda is write-protected, mounting read-only Płyta pojawiła się w żądanym katalogu. Sprawdźmy to: blueice root {/mnt} # cd cdrom/ blueice root {/mnt/cdrom} # ls COPYRIGHT.TXT KateOS_EULA VERSION disks dvd repo FILES.MD5 README boot doc kate GPG_KEY RELEASE_NOTES commonlicenses dosutils logos Po użyciu odmontowujemy nośnik. Ponieważ nasza konsola znajduje się w katalogu płyty ( {/mnt/cdrom}), odmontowanie się nie powiedzie (używane urządzenia nie mogą być odmontowane). Wchodzimy w katalog wyżej, opuszczając katalog płyty: blueice root {/mnt/cdrom} # cd ../ Teraz możemy odmontować: blueice root {/mnt} # umount /dev/hda Sprawdzamy, czy zawartość płyty zniknęła: blueice root {/mnt} # cd cdrom/ blueice root {/mnt/cdrom} # ls blueice root {/mnt/cdrom} # Dla większego efektu możemy kazać systemowi otworzyć tackę: blueice root {/mnt/cdrom} # eject /dev/hda bziuuum ;)
warning.pngUwaga na pendrajwy! – gdyż tam dostęp do nośnika uzyskujemy najczęściej przez odwołanie się do pierwszej partycji: /dev/sdb1. Na dodatek o ile odmontowanie płyty po użyciu jest mało istotne, o tyle pendrive wyciągnięty bez odmontowania może utracić dane, gdyż Linux stosuje tu bufory przyspieszające zapis. W Windows XP SP1 (dopiero!) wprowadzono aplet "bezpieczne usuwanie sprzętu", który jest odpowiednikiem odmontowania w Linuksie.

Jak dzisiaj wygląda automatyczne montowanie?

W nowoczesnych dystrybucjach linuksowych obowiązuje pewien standard obsługi urządzeń. Zobaczmy jak on wygląda na przykładzie włożenia pendrive'a do gniazda USB:

lub

Za Wiki Archlinuksa

Automatyczne montowanie po włożeniu nośnika jest niekoniecznie dobrym pomysłem, kwestię montowania i odmontowywania lepiej zostawić środowisku graficznemu, które dzięki ww. demonom nie powinno mieć z tym problemu.

Sam pomysł montowania wynika oczywiście z tego, że Linux niczego nie robi sam bez wyraźnego polecenia. Montowanie z roota to efekt jak zwykle przesadnej dbałości o bezpieczeństwo. Zobaczmy jednak w /etc/fstab taki wpis:

urządzenie	punkt montowania    system plików	opcje		dump	fsck
/dev/sdb	/media/pendrive 	auto	rw,noauto,user,sync	 0	 0

Najważniejsza jest tu linijka opcje. Jak widać utworzyliśmy sobie wpis dla pendrive'a z opcją montowania w trybie do odczytu i zapisu (rw - read write), który nie będzie montowany automatycznie (ale można to przecież zmienić jak ktoś lubi), który może być montowany przez zwykłego użytkownika (user), i który będzie zapisywany synchronicznie, czyli bez opóźnienia. W przypadku opcji async dane zostaną zapisane dopiero jakiś czas po żądaniu ich zapisania. Zwiększa to szybkość i trwałość nośnika kosztem bezpieczeństwa (jeśli ktoś na przykad zapomni odmontować przed wyjęciem, dane nie zostaną zapisane).

Każde mądrzejsze środowisko graficzne potrafi, korzystając z takiego wpisu, wyświetlić ikonkę pendrive'a i go zamontować przy pierwszej próbie użycia. Poprawnie skonfigurowane demony HAL i D-bus zastępują wpisy dla nośników wymiennych z pliku /etc/fstab. Przy użyciu demonów (a nie wpisów w /etc/fstab), aby dodać niestandardowe opcje montowania należy ustawić je odpowiednio w środowisku graficznym[1].

HAL, D-Bus i PolicyKit – jak się ich pozbyć? (apologia)

(Poniższy tekst wbrew nagłówkowi nie zawiera instrukcji jak pozbyć się HAL-a, D-Busa i PolicyKita)

Na trio HAL, D-Bus i PolicyKit pojawiają się często narzekania z powodu wad w samych założeniach (choćby skomplikowana konfiguracja przez pliki XML, dziwne komunikaty), niepoprawnej domyślnej konfiguracji w niektórych tak zwanych "przyjaznych" dystrybucjach oraz niepoprawnej implementacji funkcjonalności w środowiskach graficznych. W przeciwieństwie do większości linuksowych demonów, HAL, D-Bus i PolicyKit przeznaczone są do integracji ze środowiskiem graficznym (projekt freedesktop), a ich przewagą nad starymi rozwiązaniami jest brak sztywno określonej bazy podłączanych urządzeń (w opozycji do statycznej zawartości /etc/fstab czy devfs zastąpionego przez udev). Teoretycznie od jakiegoś czasu do komputera z Linuksem można podłączać "pod prądem" klawiatury, ekrany, touchpady i inne urządzenia, które będą natychmiast obsługiwane. PolicyKit może zastąpić wszelkie pytania o hasło roota, umożliwiając wygodną pracę zgodnie z nadanymi przez administratora wcześniej uprawnieniami (np. konfiguracja sieci, usypianie systemu, instalowanie oprogramowania).

Ta technologia naprawdę jest przyszłością i już w tej chwili sprawdza się dobrze w popularnych zastosowaniach pod porządnymi dystrybucjami. Dziś nikt normalny nie instaluje devfs, tylko udeva, który jest przecież trudniejszy w konfiguracji. Za jakiś czas podobnie będzie wyglądała sprawa z HAL-em, D-Busem i PolicyKitem. Integracja ze środowiskami graficznymi czyni usunięcie tych demonów dosyć karkołomnym zadaniem. Zamiast miotać się z nimi, lepiej zainstalować ich najnowsze wersje i sprawdzić swoje uprawnienia w graficznej nakładce na PolicyKit (w KDE znajduje się ona w Centrum sterowania). Najczęściej zmienianą opcją jest umożliwienie montowania pendrive'ów, które nie wiedzieć czemu jest zablokowane. I tylko tyle, w typowych zastosowaniach nie ma w ogóle potrzeby edytować konfiguracji HAL-a czy D-Busa przez pliki tekstowe w /etc. Nie sugeruj się podpowiedziami na jakimś forum – to ma działać od razu. W systemach typu KISS o ile chcemy mieć obsługę dynamicznie podłączanych klawiatur, trzeba przekopiować jeden plik konfiguracyjny, definiujący układ językowy klawiatury.

Poprzednia strona
Spis
Kolejna strona
hacker emblem

© Marcin Kocur (marcin2006 AT gmail COM), licencja: Creative Commons 3.0 Uznanie autorstwa-Użycie niekomercyjne-Na tych samych warunkach

Valid HTML 4.01 StrictPoprawny CSS!