Zwykle nie zwracamy uwagi na to jak formatujemy partycje w systemie linux i akceptujemy domyślne ustawienia jakie przyjęli sobie deweloperzy danej dystrybucji. Nie ma tutaj znaczenia czy instalujemy świeży system za pośrednictwem instalatora i przy jego pomocy kroimy dysk, czy też tworzymy partycje indywidualnie już z poziomu jakiegoś zainstalowanego systemu, bądź też płytki czy pendrive live. Domyślne ustawienia mają spełniać oczekiwania jak największej liczby odbiorców i nie zawsze nam one odpowiadają. W przypadku formatowania dysku, problematyczne może być rezerwowanie miejsca dla procesów użytkownika root.

Każdemu z nas zdarzyło się zostawić włączoną konsolę, na której byliśmy zalogowani jako administrator systemu root. Być może nie zdajemy sobie sprawy jak często potrafimy popełnić tego typu gafę. Jedną z metod obrony jest oczywiście wyłączenie konta root w systemie i korzystanie z sudo. Ja jednak wolę inne rozwiązanie, które zakłada ograniczenie czasu bezczynności, po którym to użytkownik zostanie automatycznie wylogowany.

Systemy plików stosuje się dla różnych nośników danych, takich jak dyski twarde, czy pendrive albo nawet płyty cd/dvd. Z formalnego punktu widzenia, system plików jest to metoda przechowywania danych i uzyskiwania do nich dostępu. Bez tego mechanizmu, informacje umieszczone na nośniku przypominały by jedynie ciąg bitów i nie wiedzielibyśmy gdzie zaczyna się jakiś plik i gdzie się on kończy. Czasami jednak zdarzają się błędy w systemie plików, które mogą doprowadzić do poważnych awarii systemu operacyjnego. Dlatego też linux co kilkanaście lub kilkadziesiąt uruchomień sprawdza stan systemu plików na każdej partycji i naprawia ewentualne błędy. W przypadku gdyby nie były one naprawiane, mogą pojawić się nowe błędy doprowadzając tym samym do całkowitej zapaści systemu.

Domyślnym bootloaderem w systemie linux jest grub i jako że to oprogramowanie jest ładowane do pamięci jako pierwsze, ma ono kluczowe zadanie w procesie startu systemu operacyjnego. Przy jego pomocy możemy także przekazać szereg parametrów dla modułów kernela, tym samym odpowiednio go konfigurując. Czasem z pewnych przyczyn, najczęściej gdy inny system nadpisze MBR, system operacyjny nie chce się podnieść i musimy przeinstalować bootloader, zakładając, że problem tkwi w nim.

W poprzednim wpisie poruszyłem temat konwersji tablicy partycji MS-DOS (MBR) na GPT. Jak można było zauważyć, ten proces nie był skomplikowany i niemalże automatyczny. Nie towarzyszyło mu także zjawisko utraty jakichkolwiek danych, jedynie w przypadku posiadania systemu operacyjnego, trzeba było przeinstalować bootloader. Nasuwa się zatem pytanie, czy również w tak prosty sposób można przerobić tablicę partycji GPT na MS-DOS? Jest to wykonalne z tym, że trzeba odpowiednio przygotować sobie do tego celu dysk.

Od jakiegoś czasu nosiłem się z zamiarem utworzenia na swoim dysku tablicy partycji GPT. Problem w tym, że tam jest wgranych sporo cennych danych i nie mam gdzie ich przenieść. Jedyne co mi wpadło do głowy to konwersja tablicy MS-DOS (zwanej też MBR) na GPT. Nie żebym jakoś tego potrzebował ale tak z ciekawości chciałem zobaczyć czy da się to zrobić w sposób łatwy i bezproblemowy. Z tego co wyczytałem na necie, to taka konwersja nie powinna sprawić problemów, zarówno przy przechodzeniu z MS-DOS na GPT jak i odwrotnie, choć w tym drugim przypadku trzeba się trochę bardziej wysilić.

Parę dni temu opisywałem jak udało mi się realokować uszkodzony sektor z dysku, który już przepracował dość długi okres czasu. Nie było to znowu jakoś specjalnie trudne, z tym, że cały problem dotyczył jakiegoś losowego sektora gdzieś w środku partycji. Jako, że domyślnym systemem plików na linuxie są te z rodziny ext (ext2, ext3, ext4) , oraz, że trzecia wersja tego systemu plików została wyposażona w dziennik (journal), to trzeba by się zastanowić, co w przypadku gdy taki uszkodzony sektor trafi się właśnie w dzienniku tego systemu plików?

Pisząc ostatni artykuł na temat udeva i montowania przy jego pomocy zaszyfrowanego kontenera, wpadł mi do głowy ciekawy pomysł na trzymanie pliku klucza (keyfile) w czymś co się potocznie nazywa "głębokim ukryciem". Z reguły ludzie nie chcą używać haseł do odblokowywania swoich systemów czy partycji i zamiast nich wolą stosować keyfile, czyli małe pliki, zwykle o rozmiarze paru KiB, które, jakby nie patrzeć, są dość unikatowe i odporne na ataki słownikowe czy inne formy przemocy. Jedyny problem z jakim człowiek musi się zmierzyć, to z zabezpieczeniem takiego keyfile i tutaj sprawa nie wygląda wcale dobrze. Takie pliki klucze są trzymane zwykle na tym samym urządzeniu, do których mają zapewniać bezpieczny dostęp, a nawet jeśli nie na tym samym, to w pobliżu takich urządzeń, dając nam tym samym jedynie fałszywe poczucie bezpieczeństwa.

Uszkodzone sektory w przypadku dysków HDD, to jak sama nazwa wskazuje, sektory, które z jakichś przyczyn nie działają tak jak powinny. Doprowadza to z reguły do niestabilności systemu operacyjnego objawiającej się jego zawieszaniem w momencie próby odczytu danych z takiego padniętego sektora. Przyczyny mogą być różne. Zwykle jest to jednak fizyczne uszkodzenie powierzchni nośnika, np w wyniku wstrząsu, czy też zwyczajne zmęczenie materiału. Jest wielce prawdopodobne, że nie jesteśmy w stanie nic poradzić w tego typu sytuacji, a ci bardziej zaawansowani użytkownicy zalecają jak najszybszą wymianę dysku, bo pierwszy bad sektor oznacza, że niedługo będzie ich więcej. Czasem jednak błędy odczytu mogą być programowe, tj. fizycznie każdy sektor jest w porządku ale z jakiegoś powodu system nie potrafi odczytać z nich danych. Przy odrobinie szczęścia jesteśmy w stanie odblokować taki sektor.

Udało mi się znaleźć trochę informacji ma temat parametru S.M.A.R.T 198 , tj. Offline Uncorrectable . Wychodzi na to, że część dysków nie resetuje go, nawet po pomyślnym przejściu testu offline. Za to demon smartd domyślnie ma ustawione informowanie o niezerowej wartości tego atrybutu w logu systemowym i prawdopodobnie chyba nie da się nic zrobić w tej sprawie ale można poinstruować smartd by wyrzucał komunikat tylko w przypadku gdy wartość tego atrybutu zostanie zwiększona w stosunku do wartości zapisanej przy poprzednim skanowaniu, czyli jeśli teraz mamy wartość, np. 2, to ostrzeżenie pojawi się gdy będzie tam widniało 3 i więcej.