(Uszkodzony) FireWire kontratakuje

Po przejściach z instalacją Liona opisanych tutaj dwa duże update'y (10.7.1 i 10.7.2) nie sprawiły mojemu MacBookowi żadnych problemów. Jednak po zainstalowaniu wersji 10.7.3 system przestał się uruchamiać, prezentując znane i nieszczególnie lubiane objawy niekończącego się oczekiwania na inicjalizację FireWire. Możliwe, że sam sobie strzeliłem w kolano, ponieważ po przeczytaniu o problemach z tą aktualizacją nie instalowałem jej przyrostowo (przez System Update), ale ściągnąłem pełną wersję (Combo). Problemów opisywanych na forach nie doświadczyłem, ale najwyraźniej system został przywrócony do stanu fabrycznego. Na szczęście tym razem sprawę udało się załatwić w kilka minut: wystarczyło zabootować system w single user mode (naciskając command-s podczas uruchamiania komputera), zamontować dysk z możliwością zapisu (/sbin/fsck -y, /sbin/mount -wu /) a następnie skasować moduł IOFireWireFamily (rm -rf /System/Library/Extensions/IOFireWireFamily.kext). Voilà! Do następnego razu.

• tekst o problemach po instalacji Mac OS X 10.7.3

[aktualizacja 2012.10.13]

Po zainstalowaniu wersji 10.7.4 jest ok, w 10.7.5 problem znowu się pojawia. Na szczęście powyższy sposób nadal jest skuteczny.

Czytaj dalej

Instalacja Liona z uszkodzonym FireWire

Nie pamiętam czy już się chwaliłem, ale popsułem w MacBooku port FireWire. Sam jego brak nie jest zbyt bolesny (właściwie go nie używałem), ale ma przykry skutek uboczny: przy starcie i przy wybudzaniu systemu jądro, próbuje zainicjować port i zatrzymuje się na tym etapie na prawie 10 minut. Skutecznym sposobem na powrót do normalnego stanu okazało się usunięcie modułów odpowiedzialnych za FireWire, tutaj jest opisane co i jak trzeba zrobić.

Wszystko działało bez problemów do momentu kiedy postanowiłem zrobić upgrade do Mac OSa 10.7. Po ściągnięciu nowego systemu z App Store instalator uruchomił się bez problemu, ale po restarcie system nie wstał ani po dwóch minutach, ani po dziesięciu ani po godzinie. Nie było co prawda ewidentnych dowodów na to, że winny jest FireWire ale objawy były na tyle podobne że wstępnie przyjąłem taką wersję. Google nie znajduje wiele na temat "instalacja Liona z uszkodzonym FireWire", ale trafił się jeden post potwierdzający moje przypuszczenia. Opisana w nim metoda ma dwie wady: wymaga drugiego komputera z działającym Lionem (ok, mam iMaka) i powoduje nadpisanie całej zawartości dysku docelowego komputera (na co zdecydowanie nie mogłem się zgodzić). Nie pozostało nic innego jak znalezienie sposobu na przygotowanie jakiegoś medium instalacyjnego i jądra zmodyfikowanie tak, aby nie zawierało obsługi FireWire. Drobiazg.

W pierwszym odruchu pomyślałem o zrobieniu instalacyjnego DVD, ale zreflektowałem się że MacBook równie dobrze wystartuje z napędu podłączonego przez USB, a zawartość pendrive'a będzie można modyfikować jeżeli coś się nie uda przy pierwszym podejściu. Poniższy opis to wersja ostateczna, bez niezwykle fascynujących nieudanych prób. Here we go.

1. Instalator Liona to najzwyklejsza aplikacja Mac OSowa i po ściągnięciu z App Store trafia do folderu Applications. Klikamy prawym przyciskiem myszy na ikonce Install Mac OS X Lion i wybieramy z menu kontekstowego Show Package Contents. Następnie otwieramy folder Contents i znajdujący się w nim SharedSupport, powinniśmy zobaczyć tam obraz dysku InstallESD.dmg - to właściwy instalator. Gdyby chodziło jedynie o przygotowanie medium instalacyjnego to wystarczyłoby zapisać ten obraz dysku na pendrive'a, ale ponieważ chcemy usunąć obsługę FireWire trzeba będzie trochę więcej wysiłku.

2. Najpierw przygotujemy miejsce do zapisania instalatora. Uruchamiamy systemową aplikację Disk Utility i podłączamy do komputera pendrive. Instalator ma rozmiar 3.8 GB, więc teoretycznie wystarczy napęd 4 GB, ja dla pewności użyłem 8 GB. Zaznaczamy pendrive'a na liście po lewej, potem klikamy zakładkę Partition, wybieramy układ z jedną partycją, format Mac OS X Extended (Journaled) i klikamy Apply.

3. Montujemy obraz InstallESD.dmg dwuklikając na nim w Finderze i wracamy do Disk Utility. Klikamy pendrivie i wybieramy zakładkę Restore. Klikamy przycisk Image... (znajdujący się obok pola tekstowego Source), wybieramy z listy napędów Mac OS X Install ESD, naciskamy command-shift-. (co spowoduje wyświetlenie ukrytych plików) i wybieramy obraz BaseSystem.dmg. Do pola Destination przeciągamy utworzoną w poprzednim kroku partycję (u mnie nazywała się ona "Untitled 1") i klikamy przycisk Restore. Po potwierdzeniu rozpocznie się zapis, powinien potrwać kilka minut. Jeżeli pendrive nie zostanie automatycznie zamontowany robimy to sami klikając ikonkę Mount w Disk Utility.

4. Now for the tricky part. Uruchamiamy Terminal i wpisujemy kolejno komendy:

cp "/Volumes/Mac OS X Install ESD/mach_kernel" "/Volumes/Mac OS X Base System/mach_kernel"

rm "/Volumes/Mac OS X Base System/System/Installation/Packages"

cp -R "/Volumes/Mac OS X Install ESD/Packages" "/Volumes/Mac OS X Base System/System/Installation/Packages"

rm -r "/Volumes/Mac OS X Base System/System/Library/Extensions/IOFireWire*"

Gdyby system czepiał się o brak odpowiednich uprawnień, to każde z powyższych poleceń można
uruchomić jako administrator (tzn. "sudo cp ...", "sudo rm ..." itd.).

Z tak przygotowanego pendrive'a można wystartować instalację wciskając klawisz alt podczas uruchamiania komputera (Plan zadziałał, plan zadziałał! Jestem genialny! Jestem wybrańcem!). Powinny się wyświetlić ikonki wszystkich bootowalnych napędów, wśród nich Mac OS X Base System - po dwukliknięciu na nim już bez problemu uruchamia się instalator Liona.

Czytaj dalej

Utterly Bastard Groovy

Zapragnąłem ostatnio znaleźć logo The Sisters of Mercy w wersji wektorowej - moja Sistersowa koszulka lata świetności ma za sobą i przydałoby się zamówić kolejną. Z Google Images trafiłem do serwisu seeklogo.com w którym są dwie wersje rzeczonego logo, ale ani jedna ani druga tak do końca mi nie pasowała. Zdecydowałem się na tę i po znalezieniu stosownej czcionki (Caslon Antique) oraz godzinie dłubania w Inkscape powstało dzieło, którym chciałbym się podzielić ze światem.

Wersja wektorowa jest tutaj.

Czytaj dalej

Czytaj dalej

Jeszcze raz Groovy i Spring

Jakiś czas temu miałem problem z dynamiczną rekompilacją komponentów Spring napisanych w Groovy. Wtedy przyczyną był błąd w samym Groovy, szczegóły opisałem tutaj. Po aktualizacji Groovy wszystko było ok, ale niedawno stwierdziłem że mechanizm dynamicznego przeładowywania znowu przestał działać. Ponieważ w międzyczasie wykonałem spory refactoring aplikacji, to nie bardzo wiedziałem gdzie zacząć szukać sprawcy. Uznałem, że tym razem to nie Groovy - skoro raz zrobili błąd i go poprawili, to szansa na to że znowu się pojawił jest niewielka. Po włączeniu logów na poziomie DEBUG stwierdziłem, że Spring też jest niewinny - gdy plik źródłowy Groovy był zmieniany, w logach pojawiał się spodziewany komunikat: Target refreshed successfully ... czyli skrypt był ładowany od nowa. Pomimo tego w aplikacji dalej używana była pierwotna wersja. Nie będę zanudzał Czytelnika szczegółowym opisem trudności i niebezpieczeństw, którym musiałem stawić czoła aby odkryć istotę problemu i przejdę od razu do clou tego posta. Tym razem bruździł Tomcat, a dokładnie jego ClassLoader.

Jeżeli skrypt zostanie umieszczony w aplikacji webowej w katalogu WEB-INF/classes i będziemy się do niego odwoływać w Springu tak:

<lang:defaults refresh-check-delay="1000"/>
<lang:groovy id="myBean" source="classpath:Bean.groovy"/>

... to po pierwszym wczytaniu Tomcat umieści plik Bean.groovy w cache i do restartu go nie ruszy. Co ciekawe Spring potrafi zauważyć zmianę daty ostatniej modyfikacji pliku i próbuje go ponownie wczytać, ale ClassLoader cały czas zwraca pierwotnie wczytaną wersję. Wystarczy przenieść plik do WEB-INF i zmienić wpis w konfiguracji na:

<lang:defaults refresh-check-delay="1000"/>
<lang:groovy id="myBean" source="/WEB-INF/Bean.groovy"/>

... by wszystko wróciło do normy. Spring wczytuje wtedy plik za pośrednictwem ServletContextu a nie ClassLoadera i dostaje zaktualizowaną wersję. Howgh.

Czytaj dalej