Haczyki przy upgrade do 64 bitów

Dekadę po wprowadzeniu architektury AMD64 przerobiłem w końcu ostatnią z moich maszyn na dystrybucję 64-bitową. Sprzęt był capable od dawna, ale jego wymiana odbyła się metodą transplantacji dysków ze starego komputera i nie było kiedy zmienić softu.

Procedura jest prosta. Instalujemy kernel 64 bitowy, uruchamiany z niego system z 32-bitowym userlandem i reinstalujemy wszystkie pakiety po kolei w wersjach x86_64. Userland 32 na jądrze 64 działa sprawnie nawet na x86, ale trzeba mieć na uwadze trzy drobiazgi:

Automount ma rozbieżne wielkości strukturki danych między 32 a 64 bity. Owocuje to zawieszeniem w czasie uruchamiania systemu 32 bit na jądrze 64 bit. Pamiętać należy o wyłączeniu automountów przed takim bootem.

RRD nie lubi baz stworzonych na innej architekturze. Tu warto zrobić rrdtool dump do xml na 32 bitach, a po upgradzie rrdtool restore.

PostgreSQL też nie lubi plików baz danych utworzonych na innej architekturze. Podobnie jak z RRD, najpierw pg_dumpall, a po upgradzie initdb i psql -f dump.sql.

Inny soft na razie problemów nie wykazuje. Zapomnienie o zrzutach może zawocować drapaniem się w głowę podczas poszukiwania jakieś jeszcze działającej 32 bitowej instalacji, żeby dokonać ich post factum. Ale na szczęście wystarcza pendrive USB z zainstalowaną 32 bitową instalacją i katalogi baz danych wyeksportowane przez NFS.

Archived comments:

Remigiusz 'lRem' Modrzejewski 2012-02-09 14:56:56

Tak właściwie, to po co to zrobiłeś?

Stanisław 'dozzie' Klekot 2012-02-09 16:27:24

Nie wiem jakie były faktyczne powody, ale jednym bardzo dobrym jest możliwość pozbycia się ostatniego hosta x86. Dla administratora to na przykład brak konieczności przygotowywania pakietów na jedną więcej architekturę.

zdz 2012-02-09 17:16:34

lrem: jak dozzie pisze, odstawało od reszty. I ma 8GB RAM, niedlugo moze 16, uzywanie PAE smierdzi troche.
Z dziwnych rzeczy, po upgradzie zaczela dzialac wetknieta kiedys karta TV na chipie bttv - pewnie wczesniej cos z przestrzenia adresowa nieteges było.

rozie 2012-02-09 18:43:50

Jeśli dobrze kojarzę skorzytsałeś z bardzo niezalecanej metody upgrade'u systemu (BTW jakie distro?). W sumie jakie zalety w stosunku do odpalenie z live i przywrócenie systemu z backupu?

zdz 2012-02-10 09:05:50

rozie: z zupelnie niezalecanej, chyba żadne distro nie wspiera zmiany architektury. Fedora na pewnie nie :).
Zalety takie, że ciągłość pracy (czyt. dostępu do internetu i rozrywki, w trakcie oglądałem film na rzeczonym komputerze).
Przywracanie z backupu wiąże się też z instalowaniem od nowa wszystkiego, co się przez prawie 3 lata (od http://enotty.pipebreaker.pl/2009/06/16/goodbye-foresight/) zbierało, a czego nie ma w domyślnej instalce. A dumpy np. RRD i tak trzeba by było zrobić (bo backupują się u mnie binarne bazy).
W skrócie: oszczędność czasu.

zdz 2012-02-19 19:00:10

Tak za 64 bitami jeszcze:
nasty FPU state corruption issue that happened only when the wireless stack used the AES-NI instructions from softirqs on 32-bit x86.

Moral of the story: don't use 32-bit kernels on modern CPU's that could do so much better.
z https://plus.google.com/109995262342451767357/posts/KGijJrUZQ7j

Pamiętam jakiś czas temu było też priviledge escalation, które działało na 32 bitach, a na 64 - z uwagi na organizację pamięci - nie działało.