Warning: Undefined variable $line_numbers in /usr/home/okiemadmina/public_html/wp-content/plugins/wp-code-highlight/wp-code-highlight.php on line 69
Warning: Undefined variable $line_numbers in /usr/home/okiemadmina/public_html/wp-content/plugins/wp-code-highlight/wp-code-highlight.php on line 69
Warning: Undefined variable $line_numbers in /usr/home/okiemadmina/public_html/wp-content/plugins/wp-code-highlight/wp-code-highlight.php on line 69
Piątek – trzynastego… W zasadzie taki mógłby być tytuł tego wpisu. Kurier dwa razy z rzędu wywrócił się z paczkami, żonie urwał się front od zmywarki, a kolega odbierając auto po wymianie płynów nie odjechał już z warsztatu, bo strzelił mu pasek rozrządu… Oczywiście natłok piątkowo-trzynastkowych zdarzeń nie mógł też ominąć przynajmniej jednego z serwerów, o czym w ten wyjątkowy piątkowy wieczór jak zwykle poinformował mnie system monitoringu. Po krótkich oględzinach stwierdzam: ping jest, usługi – w tym SSH – nie działają. Szczęśliwie dostępna jest zdalna konsola. Odpalam, loguje… jest – mam ekran i klawiaturę. Login, hasło, szczęśliwie powitał mnie bash. No to sprawdzamy: dmesg -> zwis. Druga konsola: ps auxw -> zwis. Następna konsola: vmstat -z -> zwis. Niema innej opcji, trzeba restartować. Mija kilkanaście sekund. W międzyczasie szybkie sprawdzenie na ile aktualna jest kopia zapasowa. Konkluzja: Nie jest źle. Wracamy do pacjenta, który już powinien być uruchomiony, a tu przykra niespodzianka wprost z bootloadera:
FreeBSD/x86 boot Default: zroot:/boot/kernel/kernel boot: ZFS: i/o error - all block copies unavailable
Przyznać muszę, że gdy pierwszy raz zobaczyłem ten błąd byłem równie zaskoczony co poważnie zmartwiony. Z pomocą szczątkowych – dostępnych na wtedy – informacji na szczęście udało mi się postawić diagnozę i znaleźć rozwiązanie problemu, którym na łamach niniejszego bloga chce się z Tobą podzielić. Jeżeli aktualnie problem dotknął Ciebie, to wiem, że chciałbyś jak najszybciej przywrócić serwer do działania. Bez zbędnego przedłużania wykonaj następujące kroki:
Krok 1: Pobierz aktualną wersję mfsBSD z http://mfsbsd.vx.sk/
Opcjonalnie możesz też wykorzystać po prostu tryb Fixit z oficjalnej dystrybucji, ale posługiwanie się mfsBSD jest moim zdaniem wygodniejsze i szybsze.
Krok 2: Zabootuj system z płytki i zaloguj się.
W przypadku mfsBSD dla root’a hasłem jest mfsroot
Krok 3: Wykonaj magiczne polecenia
UWAGA: W moim przypadku nazwa puli ZFS to zroot
# kldload opensolaris # kldload zfs # zpool import -R /zroot zroot # zfs set mountpoint=/ zroot # cd /zroot
Krok 4: Zwalniamy na dysku nieco miejsca (najlepiej żebyśmy mieli przynajmniej 20GB wolnej przestrzeni)
Krok 5: Jeszcze szczypta magii:
# cd /zroot # cp -a boot boot2 # mv boot_20151113 # mv boot2 boot # cd / # zfs set mountpoint=legacy zroot # zpool set bootfs=zroot zroot # zpool export zroot # reboot
Krok 6: Bootujemy z dysku i trzymamy kciuki… 🙂
Pomogło? Bardzo się cieszę. Ale co właściwie się stało i czemu powyższe polecenia załatwiają temat?
Problemem jest fragmentacja plików w katalogu /boot przy małej ilości miejsca na dysku. Nie wiedząc czemu system nie potrafi wtedy zabootować wyrzucając błąd jak powyżej (lub podobny). Po zwolnieniu miejsca i wykonaniu kopii katalogu /boot do /boot2 otrzymujemy już niepofragmentowaną kopię. Przez „mv” przypisujemy ją z powrotem pod starą nazwę i w ten sposób rozwiązujemy problem.
Jeżeli niniejszy wpis Ci pomógł, zostaw komentarz. Ciekawy jestem jak często ten problem jeszcze się zdarza.
