Upgrade Lenny do Squeeze – co poszło źle.

Ponieważ system po nieudanej aktualizacji już działa (w ogóle okazało się, że przyczyną „problemów z grubem” była w rzeczywistości najprawdopodobniej niedociśnięta taśma od stacji dysków) i mogę dostać się do swoich danych, to pora na konkrety i przestrogę.

Komunikat, który mówił o problemach z przejściem na dependency based boot przy upgrade z Lenny’ego do Sarge Squeeze i który może nie tyle zignorowałem, co chciałem zająć się nim po reboocie (bo zapisałem) wyglądał dokładnie tak:

Unable to migrate to dependency-based boot system

Tests have determined that problems in the boot system exist which prevent migration to
dependency-based boot sequencing:

insserv: warning: script 'K20atieventsd' missing LSB tags and overrides, insserv: warning: script
'atieventsd' missing LSB tags and overrides,

If the reported problem is a local modification, it needs to be fixed manually. If it's a bug in the
package, it should be reported to the BTS and fixed in the package. See
http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot for more information about how to fix the
problems preventing migration.

To reattempt the migration process after the problems have been fixed, run "dpkg-reconfigure sysv-rc".

Skrypt atieventsd pochodzi z flgrx, z którego nie korzystałem od migracji na Lenny’ego. Taka zemsta ATI/AMD zza grobu.

Ale co sobie powalczyłem, to powalczyłem (kolejne sprawności zdobyte: instalator nie jest taki świetny i ma głupie defaulty dla instalacji gruba – kto to widział, że przy instalacji wszystkiego na sdb i niczego na sda chce umieścić gruba na sda?; rescue mode daje radę). Okazało się, że CD-ROM też już nie działa – zasilacz od dawna był słaby i miał problemy z kręceniem dwoma dyskami, ale teraz doszło do tego, że i jednym nie kręci, jeśli CD-ROM jest podpięty. No chyba, że stacja dyskietek tak bruździła. Nie wiem, nie wnikam, działa – nie dotykam (ładne rymowane motto, swoją drogą).

UPDATE: Inna możliwa przyczyna, to własny – a nie dystrybucyjny – kernel. Dziś kolejna osoba miała problem ze swoim kernelem na Squeeze, identyczne objawy (pusty /dev), a na dystrybucyjnym działało OK. Instalacja linux-image-2.6-amd64 (lub linux-image-2.6-486 dla systemów 32-bitowych) przed rozpoczęciem upgrade’u do Squeeze wydaje się dobrym pomysłem. 😉 Zresztą jest to opisane w release notes procesu aktualizacji Lenny do Squeeze (wersja robocza; TBH nie czytałem przed aktualizacją – nie wiem czy był już dostępny – mea culpa).

Historia pewnego upgrade

Minęły prawie 2 lata odkąd zrobiłem upgrade tej maszynki do Lenny’ego. Stwierdziłem, że Squeeze, którego używam od dłuższego czasu jest dobry, przydałoby się parę nowych pakietów no i można przetestować jak ten upgrade wychodzi. KDE 3.5 też jakoś nie jest tym, co mi ostatnio pasuje (a pasuje mi LXDE), więc stwierdziłem, że parę dni wolnego to dobry moment, żeby zrobić upgrade.

Problem numer jeden, który uniemożliwił mi zalecaną wersję upgrade’u, to za mała ilość wolnego miejsca. 1 GB wolnego na /, po porządkach 1,3 GB. Zdecydowanie nie to, co tygrysy lubią najbardziej. Postanowiłem, że po prostu podmienię wpisy w sources.list z lenny na squeeze, zrobię wajig update; wajig upgrade a następnie wajig dist-upgrade. Wcześniej wywaliłem jeszcze javę i OpenOffice. Gołe dist-upgrade niestety nie mieściło się.

Update poszedł bez problemu, po nim kontrolny reboot. Wszystko ładnie działa. Pora zatem na dist-upgrade. Ten też w zasadzie przebiegł bezproblemowo. Jedyne co pojawiło się z dziwnych rzeczy, to ostrzeżenie, że nie może korzystać z dependency based boot, które skrypty przeszkadzają i gdzie szukać pomocy. Oczywiście zapisałem sobie te komunikaty, dałem OK. Update się zakończył, pora na reboot.

I tu zaczęły się schody. Przy próbie montowania /home z osobnej partycji, stwierdził, że /dev/hda3 nie istnieje i zaproponował uruchamianie w maintaince mode. Hm! Stwierdziłem, że pewnie kwestia kernela (mam własny), więc doinstaluję dystrybucyjny. Prawie się udało, niestety grub nie chciał się zaktualizować – brak dysków w /dev. Faktycznie ich nie było. Trochę powalczyłem ze skryptami startowymi, które były prawdziwą przyczyną zamieszania (bez większych sukcesów, namierzyłem jedynie nieuruchomiony hald) i stwierdziłem, że skoro / jest na osobnej partycji, to najszybciej będzie zainstalować system debootstrapem. Przy okazji zmigruję z ext3 na ext4.

Tylko jak uruchomić debootstrap, jeśli USB jest nieczynne (dziękujemy padniętym kondensatorom na płycie), a live nie ma? Przełożę dysk! Tak też zrobiłem. Niedługo później system był zainstalowany. Teoretycznie, bo aktualnie przy wejściu do gruba wykonuje malowniczy reboot.

Właśnie ściągam płytę instalacyjną. Mam nadzieję, że nagrywarka i czytnik są sprawne i że po zainstalowaniu instalatorem będzie się bootował.

Podsumowując: mam dość upgrade’ów, a konkretnie żonglowania sprzętem, na dłuższy czas, a już na pewno nie na sprzęcie, gdzie w prosty sposób nie można odpalić live. Najlepiej z USB.

Super Cebula czyli łamanie GPL po polsku.

Sprawa została opisana m. in. na osnews i w sumie ten wpis miał być jednym z komentarzy, ale z różnych względów lepiej jak zostanie tutaj (a trackbacka się nie dorobili). Na wstępie disclaimer: nie uruchamiałem gry, więc będę opierał się na dostępnych screenshotach, video i lekko spekulował.

Przede wszystkim mam wątpliwości, czy w ogóle kiedykolwiek doszło do złamania GPL, a przynajmniej w tym obszarze, który zarzuca się autorom gry Super Cebula (dead link). Jak znam życie, to zmianie uległy jedynie grafiki (nie podejrzewam autorów o umiejętność zmiany czegokolwiek w kodzie, skoro mieli problem ze 100% czystym użyciem licencji GPL, zrobieniem spolszczenia itd., sorry). Co oznacza, że (interaktywna) informacja o licencji była dostępna w identyczny sposób, jak w oryginale (chyba, że dany fragment lub plik do którego się odnosi został wycięty, o co jak pisałem nie podejrzewam autorów).

Licencja GPL (nie mówię o jej pochodnych), a przynajmniej niektóre jej wersje, nie zabrania linkowania do niewolnych bibliotek czy mediów. Dlatego nawet jeśli oryginalne grafiki są na GPL (która nawiasem średnio się nadaje do licencjonowania czegoś innego niż kod źródłowy/tekst), to można je bezkarnie zmienić.

Faktem jest, że wygląda, że pierwotnie zabrakło informacji o źródle. Piszę wygląda, bo nie mam pewności, czy link do strony domowej, skąd można pobrać kod nie pojawia się w samej grze. Ale tak naprawdę jeśli chodzi o ducha GPL to jest zachowany – nikt nie będzie miał problemu ze zrobieniem własnego klona gry, choćby o nazwie Super Kaczka (Super Che, Super whatever). Jedyne co musi mieć, to parę grafik.

Faktem jest też, że na uwagi zareagowali szybko i prawidłowo (oby wszyscy łamiący GPL tak reagowali…).

Gorzej, że gra nadal przedstawia się ona jako Super Tux – widoczne na video ok. 3. sekundy:

Nie powinno to mieć miejsca – twórcy Super Tux wypuścili normalną grę dla dzieci, a nie agitkę o dyskusyjnych walorach estetycznych. I to jest tak naprawdę jedyne łamanie GPL, o którym można mówić, a chyba na które nikt nie zwrócił uwagi. W sumie nawet nie tylko GPL, tylko być może naruszenie osobistych praw autorskich – całkiem jakbym wziął kawałek jakiegoś zespołu (na wolnej licencji), zmienił tekst, podłożył mój lichy wokal i rozprowadzał to dalej pod ich nazwą. Ciekawe, czy to też poprawią, biorąc pod uwagę istniejące dokonania, może być z tym problem…

Wygląda, że niechcący zafundowano kandydatowi PO lepszą reklamę, niż sztab zakładał tworząc samą grę. Swoją drogą mam mieszane uczucia co do samego pomysłu – z jednej strony jest ciekawy, z drugiej – komu by się chciało łazić głową jakiegoś faceta? I kto jest adresatem gry? Bo chyba dzieci nie będą grały w nędzną agitkę i podniecały się wskoczeniem na PiS…

Jeśli chodzi o świadomość nt. GPL w społeczeństwie, to nie sądzę by sprawa coś zmieniła. Sporo w tym winy samej GPL (v. 2.0), która ma sporo alternatyw i nie jest prosta i jednoznaczna.

BTW na której wersji licencji GPL jest Super Cebula i Super Tux z którego korzystali? Przyjąłem, że 2.0, ale jeśli nie, to może być weselej…