Wskazówka: użyj etckeeperna starym systemie i na nowym systemie, a po zainstalowaniu wszystkich dodatkowych pakietów ( dselecti dpkg -l) zainstalowanych na starym systemie, scal zmiany w porównaniu do plików konfiguracyjnych dist w nowym systemie;) ...
0xC0000022L
Odpowiedzi:
4
Niestety, podobnie jak inne systemy operacyjne, nie ma „ścieżki aktualizacji”, która by to umożliwiała. Prawie na pewno będziesz musiał dokonać ponownej instalacji.
Jeśli chodzi o zachowanie danych, tworzenie kopii zapasowej katalogu domowego byłoby dobrym pomysłem wraz z innymi danymi i powinno być łatwo zaimportowane do nowej instalacji.
Zawsze wykonuj kopię zapasową danych przed próbą czegokolwiek!
Nie kopiowałbym tylko /etcw przypadku niewielkich różnic między wymaganiami konfiguracyjnymi dla 64-bitowych kompilacji pakietów, ale zrobienie kopii, a następnie przesłanie diffkopii do nowo zainstalowanego 64- bitowego systemu, ale działałoby. Szanse są takie, że liczba zmian nie jest ogromna, więc zrobienie tego i ręczne wprowadzenie wymaganych zmian nie będzie wielkim trudem.
Kopiowanie, /etcjak sugerujesz, powinno jednak działać OK - zrobiłbym to na dłuższą metę ze względu na paranoję. Kopiowanie /home, główny problem podczas migracji z jednej instalacji do drugiej, jest bardziej bezpieczne.
Jeśli chcesz przejść na wersję 64-bitową, aby skorzystać z większej ilości pamięci RAM, a nie dlatego, że potrzebujesz aplikacji 64-bitowych, możesz po prostu użyć 64-bitowego jądra z 32-bitową przestrzenią użytkownika. Debian faktycznie dostarcza pakiety jądra 64 w swoich repozytoriach i386, więc można to zrobić tak prosto, jak to aptitude install linux-image-2.6-amd64, ale Ubuntu niestety nie, więc musisz skompilować własne jądro, co może nie być warte czasu + kłopotanie, jeśli nie jesteś technicznie doświadczonych (tj. jest to proste, ale tylkojeśli wcześniej skompilowałeś własne jądro, możesz więc swobodnie korzystać z tego procesu). Jeśli uruchamiasz 64-bitowe jądro z 32-bitowym obszarem użytkownika, indywidualna aplikacja może nadal uzyskiwać dostęp tylko do ~ 3Gb najwyżej (w niektórych przypadkach tylko ~ 2 Gb), ale system jako całość (wszystkie procesy razem plus rzeczy jądra, takie jak Pamięć podręczna We / Wy i bufory) mogą zużywać tyle, ile masz. Każda maszyna wirtualna VMWare liczy się jako jedna aplikacja do tych celów - w ten sposób uruchamiam jednego z moich starszych hostów maszyn wirtualnych (maszyny wirtualne używają łącznie ~ 7 Gb z 64-bitowym jądrem, 32-bitową przestrzenią użytkownika i 32-bitowym VMWare), ponieważ było to szybsze niż pełne 64-bitowe uaktualnienie systemu operacyjnego hosta, kiedy uaktualniłem procesor maszyny do 64-bitowego zdolnego i dodałem dodatkową pamięć RAM - domyślam się, że podobne rozwiązania VM również działałyby w ten sam sposób.
Czy to nie to samo, co używanie jądra „linux-image-server” z włączonym PAE?
Kirill V. Lyadvinsky
Rozumiem, że procesory oparte na AMD64 / kompatybilne nie muszą przełączać się między trybami, aby uruchamiać razem kod 32-bitowy i 64-bitowy, więc nie ma tam dodatkowej nieefektywności i nie ma jiggery-pokery mapowania pamięci, których używa PAE albo (aplikacje 32-bitowe wydają się wykorzystywać tylko mniej niż 4 GB wirtualnej przestrzeni adresowej). Mogę się mylić, ale uważam, że mieszanie w ten sposób kodu 32- i 64-bitowego w celu uzyskania dodatkowej adresowalnej pamięci RAM jest mniej nieefektywne niż PAE.
David Spillett
6
Ponownie zainstalowałem komputer z wersji 32-bitowej 10.10 na 64-bitową 10.10 w zeszłym miesiącu, bez utraty danych. Jedyną sztuczką jest wybranie narzędzi zmiany rozmiaru dysku, a nie sformatowanie całego dysku podczas ponownej instalacji 64-bitowego systemu Ubuntu 10.10.
+1. Właściwie to też widziałem, jak to zrobiono (Debian i Ubuntu) i wydawało się, że działa bezbłędnie.
0xC0000022L,
0
Uruchamianie 32-bitowej przestrzeni użytkownika na 64-bitowym jądrze może powodować problemy, gdy tylko zaangażowane zostaną urządzenia systemowe. Na przykład użycie 32-bitowej biblioteki libalsa na 64-bitowym jądrze będzie prawie działać, ale będzie dość niewiarygodne i niestabilne, ponieważ struktury danych ioctl zdefiniowane w asound.h mają różne rozmiary i układy po skompilowaniu z architekturą 64-bitową i 32-bitową.
Tak więc użycie jackd -d alsa -X alsaraw (lub jego odpowiednika jackd2) przerwie się z nieudaną asercją podczas wywoływania 32-bitowego narzędzia w 64-bitowym jądrze. Standardowa obsługa dźwięku będzie o wiele mniej niezawodna, ponieważ liczby buforów są źle interpretowane.
Ogólnie rzecz biorąc, wszelkie struktury danych jądra muszą być zadeklarowane w taki sposób, aby ich rozmiary nie różniły się między jądrem 32- i 64-bitowym, lub kod 32-bitowy musi być inteligentny w używaniu różnych definicji struktur zgodnie z architekturą jądra.
Podsumowując, prawdopodobnie lepiej jest zainstalować ponownie od zera i przenieść katalog partycji domowej / katalogu.
Zostało to zadane (i udzielono odpowiedzi) ponad 7 lat temu. Czy możesz być trochę bardziej zrozumiały, jakie nowe informacje przynosisz? Zobacz Jak odpowiedzieć i wybrać się na naszą wycieczkę .
etckeeper
na starym systemie i na nowym systemie, a po zainstalowaniu wszystkich dodatkowych pakietów (dselect
idpkg -l
) zainstalowanych na starym systemie, scal zmiany w porównaniu do plików konfiguracyjnych dist w nowym systemie;) ...Odpowiedzi:
Niestety, podobnie jak inne systemy operacyjne, nie ma „ścieżki aktualizacji”, która by to umożliwiała. Prawie na pewno będziesz musiał dokonać ponownej instalacji.
Jeśli chodzi o zachowanie danych, tworzenie kopii zapasowej katalogu domowego byłoby dobrym pomysłem wraz z innymi danymi i powinno być łatwo zaimportowane do nowej instalacji.
Zawsze wykonuj kopię zapasową danych przed próbą czegokolwiek!
źródło
Nie kopiowałbym tylko
/etc
w przypadku niewielkich różnic między wymaganiami konfiguracyjnymi dla 64-bitowych kompilacji pakietów, ale zrobienie kopii, a następnie przesłaniediff
kopii do nowo zainstalowanego 64- bitowego systemu, ale działałoby. Szanse są takie, że liczba zmian nie jest ogromna, więc zrobienie tego i ręczne wprowadzenie wymaganych zmian nie będzie wielkim trudem.Kopiowanie,
/etc
jak sugerujesz, powinno jednak działać OK - zrobiłbym to na dłuższą metę ze względu na paranoję. Kopiowanie/home
, główny problem podczas migracji z jednej instalacji do drugiej, jest bardziej bezpieczne.Jeśli chcesz przejść na wersję 64-bitową, aby skorzystać z większej ilości pamięci RAM, a nie dlatego, że potrzebujesz aplikacji 64-bitowych, możesz po prostu użyć 64-bitowego jądra z 32-bitową przestrzenią użytkownika. Debian faktycznie dostarcza pakiety jądra 64 w swoich repozytoriach i386, więc można to zrobić tak prosto, jak to
aptitude install linux-image-2.6-amd64
, ale Ubuntu niestety nie, więc musisz skompilować własne jądro, co może nie być warte czasu + kłopotanie, jeśli nie jesteś technicznie doświadczonych (tj. jest to proste, ale tylkojeśli wcześniej skompilowałeś własne jądro, możesz więc swobodnie korzystać z tego procesu). Jeśli uruchamiasz 64-bitowe jądro z 32-bitowym obszarem użytkownika, indywidualna aplikacja może nadal uzyskiwać dostęp tylko do ~ 3Gb najwyżej (w niektórych przypadkach tylko ~ 2 Gb), ale system jako całość (wszystkie procesy razem plus rzeczy jądra, takie jak Pamięć podręczna We / Wy i bufory) mogą zużywać tyle, ile masz. Każda maszyna wirtualna VMWare liczy się jako jedna aplikacja do tych celów - w ten sposób uruchamiam jednego z moich starszych hostów maszyn wirtualnych (maszyny wirtualne używają łącznie ~ 7 Gb z 64-bitowym jądrem, 32-bitową przestrzenią użytkownika i 32-bitowym VMWare), ponieważ było to szybsze niż pełne 64-bitowe uaktualnienie systemu operacyjnego hosta, kiedy uaktualniłem procesor maszyny do 64-bitowego zdolnego i dodałem dodatkową pamięć RAM - domyślam się, że podobne rozwiązania VM również działałyby w ten sam sposób.źródło
Ponownie zainstalowałem komputer z wersji 32-bitowej 10.10 na 64-bitową 10.10 w zeszłym miesiącu, bez utraty danych. Jedyną sztuczką jest wybranie narzędzi zmiany rozmiaru dysku, a nie sformatowanie całego dysku podczas ponownej instalacji 64-bitowego systemu Ubuntu 10.10.
źródło
Uruchamianie 32-bitowej przestrzeni użytkownika na 64-bitowym jądrze może powodować problemy, gdy tylko zaangażowane zostaną urządzenia systemowe. Na przykład użycie 32-bitowej biblioteki libalsa na 64-bitowym jądrze będzie prawie działać, ale będzie dość niewiarygodne i niestabilne, ponieważ struktury danych ioctl zdefiniowane w asound.h mają różne rozmiary i układy po skompilowaniu z architekturą 64-bitową i 32-bitową.
Tak więc użycie jackd -d alsa -X alsaraw (lub jego odpowiednika jackd2) przerwie się z nieudaną asercją podczas wywoływania 32-bitowego narzędzia w 64-bitowym jądrze. Standardowa obsługa dźwięku będzie o wiele mniej niezawodna, ponieważ liczby buforów są źle interpretowane.
Ogólnie rzecz biorąc, wszelkie struktury danych jądra muszą być zadeklarowane w taki sposób, aby ich rozmiary nie różniły się między jądrem 32- i 64-bitowym, lub kod 32-bitowy musi być inteligentny w używaniu różnych definicji struktur zgodnie z architekturą jądra.
Podsumowując, prawdopodobnie lepiej jest zainstalować ponownie od zera i przenieść katalog partycji domowej / katalogu.
źródło