Aktualizacja Ubuntu 7.04 (Feisty Fawn) do Ubuntu 7.10 (Gutsy Gibbon)

Ubuntu przebojem wdarło się na rynek darmowych systemów operacyjnych niemal równo trzy lata temu, bo 20 października 2004 roku (wersja 4.10). Prawdziwy boom, jeśli można to tak ująć, miał jednak miejsce w momencie wydania wersji 6.06 LTS (Dapper Drake), czyli zgodnie z nazewnictwem Ubuntu w czerwcu 2006 roku. Od tego czasu Ubuntu zaklepało sobie już na stałe miejsce na podium przeznaczonym dla najpopularniejszych dystrybucji Linuksa, szczególnie wśród desktopów. Półroczny cykl wydawniczy nowych wersji Ubuntu jest jak do tej pory solidnie dotrzymywany, z jednym wyjątkiem - wersja 6.06 miała dwa miesiące poślizgu, co jednak można tłumaczyć tym, że była to wersja specjalna, tzw. LTS czyli Long Time Support, bardziej dopieszczona i z wydłużoną gwarancją dostarczania poprawek technicznych aż do 36 miesięcy (60 dla serwerów), w stosunku do standardowych 18. Kolejna wersja LTS planowana jest na kwiecień 2008 roku. Tymczasem jednak otrzymaliśmy zapowiadaną “zwykłą” wersję 7.10, ochrzczoną nazwą Gutsy Gibbon, co w wolnym tłumaczeniu przyjęło się jako Gibki Gibon.

Zawsze w takich momentach użytkownicy poprzedniej wersji (w tym wypadku 7.04 - Rozbrykanego Jelonka) muszą zadać sobie pytanie czy warto przeprowadzać aktualizację. W przypadku Ubuntu odpowiedź jak do tej pory zwykle jest podobna - poza nielicznym przypadkami zdecydowanie warto, bo zyskujemy nowsze, ulepszone oprogramowanie, a także gwarancję, że w razie wystąpienia problemu znajdziemy dla niego rozwiązanie w sieci szybciej, niż gdybyśmy ciągle używali starszej wersji systemu. Oczywiście nie ma się co śpieszyć i nie trzeba dokonywać aktualizacji od razu. Można z powodzeniem odczekać kilka dni, tygodni, a nawet miesięcy. Należy jednak pamiętać, że najprotsze (czyt. sprawiające najmniej problemów) aktualizacje Ubuntu to regularne aktualizacje z wersji na wersję, dlatego jeśli nie mamy ku temu bardzo istotnego powodu, nie warto zwlekać z aktualizacją dłużej niż do czasu wyjścia kolejnej wersji systemu.

Pełną listę nowości w Ubuntu (i Kubuntu) 7.10 można znaleźć na oficjalnych stronach systemu:
- http://www.ubuntu.com/getubuntu/releasenotes/710tour
- http://kubuntu.org/announcements/7.10-release.php

W sieci, czy to na oficjalnych stronach Ubuntu czy też na różnej maści forach, można znaleźć liczne instrukcje i porady odnośnie aktualizacji systemu. Metod jest co najmniej kilka, można sobie i poklikać i popisać, ale efekt końcowy zawsze powinien być podobny. Niestety, w trakcie aktualizacji często pojawiają się mniej lub bardziej istotne problemy, z którymi należy sobie za wczasu poradzić, jeśli nie chcemy, aby system po restarcie już nie wstał. Mniej doświadczeni użytkownicy, obawiając się własnie tego typu komplikacji, często decydują się na całkowitą reinstalację systemu. Cóż, można i tak. W ten sposób jednak niczego się nie nauczymy, a czas poświęcony na ponowna konfigurację programów i systemu z pewnością mógłby zostać lepiej spożytkowany. Szczególnie, jeśli ta historia ma się powtarzać co pół roku…

Z tego powodu poniżej postanowiliśmy zaprezentować przykładowy przebieg aktualizacji systemu przeprowadzanej z wykorzystaniem internetu i konsoli - dzięki temu proces wygląda identycznie bez względu na to, czy aktualizację przeprowadza użytkownik Ubuntu, Kubuntu czy może Xubuntu itd. Staraliśmy się poruszyć wybrane problemy, na które można napotkać w trakcie aktualizacji systemu i podać przykładowe metody ich rozwiązania, niekoniecznie zawsze najlepsze, ale na pewno najprostsze i przede wszystkim - efektywne.

Przed aktualizacją

  • Zaktualizujmy obecną wersję systemu w dowolny wybrany sposób.
  • Przygotujmy sobie płytę LiveCD z dowolną dystrybucją. Sprawdźmy czy system nam z niej startuje i czy potrafimy dostać się za jej pomocą do naszych danych (w szczególności jeśli używamy szyfrowania). W razie ewentualnych poważnych problemów to może być nasza podstawowa deska ratunku. Zawsze też warto wykonać kopię najważniejszych danych.

  • Zarezerwujmy sobie odpowiednią ilość miejsca na dysku systemowym / (oraz /var i innych partycjach systemowych jeśli takowe posiadamy). Pakiety pobierane z sieci system umieszcza w /var/cache/apt/archives, dlatego jeśli na dysku mamy tylko ~1 GB wolnego miejsca, a system poinformuje, że chce pobrać 750 MB danych, które po instalacji zajmą 500 MB więcej niż obecnie, a tymczasem nasz katalog /var jest na tej samej partycji co główny system plików /, to koniecznie samodzielnie musimy zadbać o to, aby przed przystąpieniem do aktualizacji wygospodarować więcej miejsca. Problem z brakiem miejsca w trakcie aktualizacji systemu to jeden z najmniej przyjemnych problemów, jeśli więc można go z góry uniknąć to zdecydowanie należy to uczynić. Co można zrobić?

    1. Przede wszystkim usunąć z archiwum zbędne pakiety. Można tego dokonać prostym poleceniem (z konsoli):

    sudo apt-get clean

    2. Jeśli nadal nie ma wystarczającej ilości miejsca to przeanalizujmy zainstalowane programy i zastanówmy się, co moglibyśmy tymczasowo odinstalować. Przykładowo na czas aktualizacji systemu można bez większych problemów odinstalować pakiet OpenOffice, dzięki czemu zyskamy nawet kilkaset MB wolnego miejsca na dysku, a także sprawimy, że aktualizator będzie musiał pobrać z sieci nawet kilkaset MB mniej danych (nowa wersja OO). Oczywiście po aktualizacji systemu znowu zrobimy sudo apt-get clean i zainstalujemy sobie OpenOffice od nowa. Można to traktować jako aktualizację “na raty”, przydatną gdy mamy mało miejsca na dysku.

    3. Jeśli nie możemy lub nie chcemy niczego odinstalowywać, a mamy dużo wolnego miejsca np. na partycji z katalogiem domowym, to możemy to miejsce wykorzystać. Wystarczy, że ustawimy, aby /var/cache/apt/archives tymczasowo (lub na stałe - bez znaczenia) prowadziło do /home/user/archives. Wystarczy przekopiować zawartość /var/cache/apt/archives do utworzonego katalogu archives w swoim katalogu domowym, a następnie wykonać:

    sudo rm -r /var/cache/apt/archives
    sudo ln -s /home/user/archives /var/cache/apt/archives

    Dzięki tej sztuczce dane pobierane przez aktualizatora będą składowane na innej partycji, przez co ~1 GB wolnego miejsca w / całkowicie nam wystarczy nawet wtedy, gdy ściągnięte zostanie 2 GB danych, jeśli tylko po aktualizacji system będzie potrzebował mniej nowego wolnego miejsca niż ten posiadany ~1 GB.

    4. Jeśli żadna z powyższych metod w naszym przypadku się nie sprawdza, a miejca wymaganego do aktualizacji nadal brakuje, wówczas zdecydowanie powinniśmy przemyśleć powiększenie partycji systemowej (lub ewentualnie aktualizację systemu z płyty CD/DVD).

  • Zarezerwujmy sobie odpowiednią ilość czasu. W zależności od tego ile danych będzie trzeba pobrać z sieci (w opisywanym przypadku było to przeszło 2 GB) i prędkości naszego łącza, samo ściąganie danych może potrwać kilka(naście) godzin, a aktualizacja pakietów wraz z rozwiązywaniem ewentualnych problemów drugie tyle. Oczywiście w przypadku mniej obładowanych systemów niż opisywany, szybkich łącz i braku dodatkowych problemów cały proces można zamknąć w jednej-dwóch godzinach. Lepiej jednak nie zostać zaskoczonym pilną robotą do wykonania w momencie, gdy aktualizacja będzie ciągle w trakcie.

Aktualizacja

Proponowana metoda aktualizacji wykorzystuje konsolę, ale nie oznacza to, że w czasie pobierania danych, a nawet aktualizacji systemu, nie będzie można z niego w ogóle korzystać. Wręcz przeciwnie, do ostatniej chwili przed restartem można z powodzeniem z systemu korzystać (w opisywanym przypadku nagrywane były płyty, surfowano po sieci i słuchano muzyki), oczywiście należy się liczyć z ewentualną podatnością na jakieś problemy, ale nie powinno wydarzyć się nic strasznego. Nie demonizujmy - to tylko aktualizacja ;).

Operację rozpoczniemy od wykonania sobie kopii aktualnego pliku z listą repozytoriów systemu:

sudo cp /etc/apt/sources.list /etc/apt/sources.list.704

Następnie edytujemy z pomocą dowolnego edytora (może być graficzny, np, gedit, kate, etc.) zawartość tego pliku. Kasujemy całą aktualną zawartość i pusty plik uzupełniamy listą podstawowych repozytoriów dla wersji 7.10 (lista uzupełniona kilkoma dodatkowymi bezpiecznymi repozytoriami - za forum.ubuntu.pl, zawsze warto zerknąć na listę aktualnych repozytoriów jeśli mamy wątpliwości):

sudo vim /etc/apt/sources.list

deb http://archive.ubuntu.com/ubuntu gutsy main restricted universe multiverse
deb-src http://archive.ubuntu.com/ubuntu gutsy main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu gutsy-updates main restricted universe multiverse
deb-src http://archive.ubuntu.com/ubuntu gutsy-updates main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu gutsy-security main restricted universe multiverse
deb-src http://security.ubuntu.com/ubuntu gutsy-security main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu gutsy-backports main restricted universe multiverse
deb-src http://archive.ubuntu.com/ubuntu gutsy-backports main restricted universe multiverse
deb http://archive.canonical.com/ubuntu/ gutsy partner
deb http://packages.medibuntu.org/ gutsy free non-free
deb http://wine.budgetdedicated.com/apt gutsy main

Teraz pozostaje przystąpić do dzieła. Zaczynamy od:

sudo apt-get update

Powinno to potrwać góra kilka minut, aż system pobierze listy nowych pakietów z serwerów. Jeśli na tym etapie wystąpi jakiś problem to tylko związany z niemożnością połączenia się z którymś z serwerów (problem na łączach lub problem z serwerem), ewentualnie może wystąpić również ostrzeżenie, że dane repozytorium nie mogło zostać zweryfikowane (GPG warning/error, aczkolwiek z powyższą listą nie powinno być takich problemów).

Pora na wydanie polecenia głównego:

sudo apt-get dist-upgrade

System rozpocznie od wyświetlenia informacji, które pakiety zostaną usunięte, które zaktualizowane, które wstrzymane i jakie nowe pakiety zostaną zainstalowane. Lista będzie długa (bardzo), a na końcu znajdzie sie podsumowanie z informacją o objętości danych, które trzeba pobrać oraz informacją, o ile więcej miejsca będzie potrzebne na dysku po aktualizacji (patrz poruszony wyżej problem wolnego miejsca). Jeśli nie zauważyliśmy czegoś bardzo niepokojącego to zatwierdzamy operację wpisując Y lub T [ENTER] i idziemy na spacer, sięgamy po dobrą książkę, itd. - w każdym razie partyjka Quake’a na obciążonym łączu raczej odpada ;). Właściwy proces aktualizacji systemu rozpoczyna się gdy pobrane zostaną wszystkie pakiety. Od tego momentu system będzie kolejno zastępował stare wersje nowymi, rozwiązywał konflikty zależności i być może pytał nas o wiele rzeczy, gdy nie będzie pewien jak postąpić. To etap, który przeważnie wymaga obecności przy klawiaturze co kilka/kilkanaście minut, dlatego spacer odpada, ale książkę można dokończyć ;).

Skupmy się teraz na problemach, które mogą wystąpić. Naszym celem jest to, aby ponowione wykonanie polecenia sudo apt-get update && sudo apt-get dist-upgrade pokazało, że jest zero pakietów do aktualizacji, usunięcia i zatrzymanych. Dopiero wówczas będzie można uznać aktualizację za zakończoną.

  • Nowe pliki konfiguracyjne programów

    Nowe wersje programów często posiadają nowe opcje, pozbywają się starych lub zmieniają im nazwy na inne. W efekcie stary plik konfiguracyjny może nie być kombatybilny z nowa wersją oprogramowania. Ilekroć w trakcie aktualizacji system napotka na sytuację, w której powinien zastąpić stary plik konfiguracyjny nowym, wówczas wstrzyma proces aktualizacji, by zapytać użytkownika co z tym fantem zrobić. Użytkownik ma możliwość zaakceptowania zmiany, pozostawienia starego pliku, zobaczenia różnic między starym i nowym plikiem, a także przerwania w tym miejscu aktualizacji i wznowienia jej ręcznie po samodzielnym rozwiązaniu problemu. Nie ma jednej złotej zasady, która by w takich sytuacjach obowiązywała, jednak można podać trzy bardziej ogólne:

    1. Zawsze warto zobaczyć porównanie dwóch plików - może się bowiem okazać, że różnią się one tylko np. komentarzem lub jakąś mało istotną opcją. Wtedy nie ma sensu się długo zastanawiać i warto zatwierdzić instalację nowej wersji.

    2. Jeśli pierwszy raz widzimy na oczy dany plik konfiguracyjny to w 99 na 100 przypadków można przyjąć, że nic w nim nie zmienialiśmy i zastąpienie go nową wersją będzie bardziej wskazane niż zachowanie starej wersji. Jeśli mamy najmniejsze wątpliwości to zróbmy wpierw kopię aktualnego pliku i zanotujmy ten fakt. W razie kłopotów będziemy mogli wrócić do stanu wyjściowego.

    3. Jeśli modyfikowaliśmy plik, który teraz system chce nam nadpisać nową wersją, nie uwzględniającą tych modyfikacji, to nie mamy wyjścia - nie gódźmy się na to i zanotujmy to sobie. Nowa wersja pliku zostanie umieszczona obok naszej wersji i będzie miała w nazwie np. “dpkg-new” albo “dpkg-dist”. Będzie więc można łatwo porównać co nowego pojawiło się w nowej wersji lub przenieść swoje modyfikacje do niej bez zagłębiania się w szczegóły. Na szczęście w większości przypadków nowe wersje programów działają dobrze ze starymi plikami konfiguracyjnymi, bo nawet jeśli pojawiły się nowe opcje to ich wartości domyślne są dobrze wyważone i ich brak w pliku konfiguracyjnym niczego nie zmienia.

  • Konflikty zawartości pakietów

    Może się zdarzyć, że w trakcie aktualizacji systemu otrzymamy informację o niemożności aktualizacji jakiegoś pakietu, bo chciałby on nadpisać jakiś plik należący do innego pakietu. Dzieje się tak na przykład, jeśli w nowej wersji systemu jakieś pliki zostają przesunięte pomiędzy pakietami powiązanymi, np. jakiś plik z informacjami zostaje przesunięty z pakietu nazwaprogramu do pakietu nazwaprogramu-doc. W efekcie tego, gdy system najpierw do aktualizacji/instalacji wybierze pakiet nazwaprogramu-doc to wystąpi wspomniany konflikt. Co w takiej sytuacji robić?

    1. Przede wszystkim nie należy się tym zrażać - to nic groźnego, chociaż komunikaty zwracane przez system, a nawet przerwanie aktualizacji może tak wyglądać na pierwszy rzut oka. W pierwszej kolejności należy sprobować tego co sugeruje system, zazwyczaj jest to prośba o wywołanie poleceń:

    sudo apt-get -f dist-upgrade
    sudo apt-get autoremove

    Polecenia te powinny usunąć zbędne pakiety i/lub wymusić aktualizację, mimo napotkanych przeciwności losu.

    2. Jeśli nadal aktualizacja nie chce ruszyć z miejsca to można usunąć jeden z pakietów, który powoduje problem:

    sudo apt-get remove nazwapakietu

    Oczywiście później należy go z powrotem doinstalować (jeśli go potrzebujemy).

  • Pakiety wstrzymane

    Jeśli nasza aktualizacja nie chce ruszyć dalej, a wykonaliśmy już wszystkie opisane wyżej kroki, to istnieje duże prawdopodobieństwo, że jakieś pakiety zostały wstrzymane, czyli że system uznał, że nie może ich zaktualizować. Informacja ta powinna być widoczna po wywołaniu sudo apt-get dist-upgrade.

    Jeśli na liście tych pakietów nie widzimy nic, czego również sami nie chcielibyśmy z jakiegoś powodu aktualizować to najlepszym sposobem na ruszenie aktualizacji z miejsca jest wymuszenie aktualizacji tych wstrzymanych pakietów. Potrafi to wywołanie:

    sudo apt-get install pakiet1 pakiet2 pakiet3

    Oczywiście zamiast pakietX nalezy podać (najlepiej po prostu przekopiować) nazwy wybranych wstrzymanych pakietów. Jeśli install nie pomoże, to można spróbować remove (zapisując wcześniej, co zostanie usunięte, żeby móc później to doinstalować).

    Najczęściej tego typu problemy występują, gdy w poprzedniej wersji systemu korzystaliśmy z różnych nieoficjalnych repozytoriów, które na czas aktualizacji systemu musieliśmy z listy sources.list usunąć. Zazwyczaj nie jest to absolutnie nic groźnego (dla systemu), ewentualnie na chwilę pozbędziemy się jakiegoś programu.

    Dużo rzadziej problem wynika z faktu, że jakiś pakiet przejął po swoim poprzedniku pewne funkcje, ale poprzednik nadal istnieje i w efekcie system nie wie, czy ma pozostawić stary, już nieaktualizowany pakiet, czy też może zamienić go na jego nowszego odpowiednika. Wtedy takie wstrzymanie faktycznie ma czasami sens i użytkownik sam powinien podjąć decyzję.

  • Nowe pakiety w trakcie aktualizacji

    W trakcie aktualizacji systemu, jeśli ta trwa dosyć długo (np. kilkanaście godzin), mogą pojawić sie w repozytoriach nowsze wersje pakietów w stosunku do tych, które zostały już pobrane. Dlatego jeśli instalacja zostanie zakończona/przerwana to warto przed odległymi czasowo wywołaniami dist-upgrade uruchomić także ponownie update. Czasami (bardzo rzadko) zdarza się, szczególnie gdy nowa wersja systemu jest bardzo świeża, że zostanie wychwycony przez użytkowników jakiś błąd i natychmiast poprawka znajdzie się w repozytoriach. Szkoda by było, gdybyśmy się na nią nie załapali i zrestartowali w międzyczasie system.

  • Restarty usług

    Aktualizacja niektórych usług, np. serwerów WWW czy FTP najczęściej wymaga ich restartu. System z pewnością o to zapyta. Dla uniknięcia ewentualnych problemów powinniśmy się zgodzić, chyba że z jakichś ważnych powodów nie możemy tego zrobić. Wówczas pozostaje restart razem z całością systemu (lub własnoręczny później). Warto tutaj wspomnieć o dwóch szczególnych usługach:

    1, Aktualizacja serwera sshd i związany z tym jej restart nie przerywa bieżących połączeń. To dosyć istotne z punktu widzenia osób, które aktualizację przeprowadzają zdalnie i obawiają się, że z jakiegoś powodu nie mogłyby się ponownie połączyć.

    2. Restart usług xdm/kdm/gdm nie jest możliwy, jeśli nie wyłączymy wcześniej trybu graficznego. Na szczęście nie jest też niezbędny, by tryb graficzny działał nam poprawnie aż do restartu systemu.

Po aktualizacji

Gdy para sudo apt-get update && sudo apt-get dist-upgrade nie pokazuje już niczego oczekującego na aktualizację wówczas możemy przyjąć, że czas na restart systemu. W trakcie restartu zwróćmy uwagę, czy na liście wyboru jądra (kernel) widocznej przy starcie systemu pojawiła się nam jakaś nowa pozycja.

W uproszczeniu możliwości po restarcie są trzy:
1. System oraz środowisko graficzne uruchamiają się bez problemów.
2. System się uruchamia (pojawia się ekran logowania w trybie tekstowym), ale środowisko graficzne nie.
3. System się nie uruchamia (kernel panic lub coś podobnego).

Ad.1.
W pierwszym przypadku należy sobie przede wszystkim pogratulować :). W dalszej kolejności - i dotyczy to również pozostałych przypadków - wypada doinstalować oprogramowanie, które ewentualnie na czas aktualizacji z różnych powodów odinstalowaliśmy, następnie sprawdzić czy wszystko najważniejsze działa.

Ad.2.
Druga możliwość najczęściej wynika albo z błędu w środowisku graficznym (bardzo rzadko, ale historia zna takie przypadki), albo z konieczności ręcznej reinstalacji binarnego sterownika graficznego, np. użytkownicy kart firmy NVIDIA bardzo często instalują sterowniki pobrane wprost ze strony nvidia.com - po każdej aktualizacji systemu, w szczególności gdy zmienia się jądro, należy te sterowniki zreinstalować. Aby się upewnić, że właśnie w tym jest problem, najlepiej zerknąć w log serwera Xorg, można również spróbować uruchomić system z poprzedniego jądra (najpewniej będzie to trzecia pozycja w początkowym menu), dla którego sterowniki nadal powinny być w systemie zainstalowane.

Ad.3.
Trzeci przypadek to najgorszy scenariusz, który jednak niekoniecznie musi oznaczać coś bardzo groźnego. Przede wszystkim należy również spróbować uruchomić system z poprzedniego jądra (jeśli jądro się zmieniło). Jeśli system się uruchomi to już wiadomo, gdzie należy szukać przyczyny. Jeśli również się nie uruchomi - no cóż, mamy pecha. Możliwości takiego stanu rzeczy jest wiele, dlatego jeśli sami nie potrafimy sobie w takiej sytuacji poradzić, a bardzo zależy nam na uruchomieniu systemu - wzywamy znajomego, który się zna lepiej i być może będzie mógł szybko pomoć. Ewentualnie szukamy w sieci (google.pl, forum.ubuntu.pl) rozwiązania dla konkretnego zaistniałego problemu (koniecznie najpierw szukając w bazie postów już napisanych, a dopiero potem zadając pytanie w nowym temacie, podając dokładny opis sytuacji wraz z komunikatami błędów).

Wróćmy jednak do sytuacji, w której system uruchomił się z poprzedniego jądra. Tego typu przypadki bardzo często występowały w przypadku aktualizacji Ubuntu z wersji 6.10 do 7.04, głównie z powodu zmiany nazewnictwa urządzeń, np. twardych dysków. Zmiana polegała na zamianie /dev/hdX na /dev/sdX również dla dysków ATA (wcześniej sdX występowało w przypadku dysków SATA i SCSI). W efekcie wiele systemów nie potrafiło się uruchomić, bo nie potrafiło zlokalizować danych… Najczęściej wystarczyła poprawka w /etc/fstab i zmiana hd na sd. Tym razem wiele osób może się poczuć podobnie zaskoczonych, ponieważ w niektórych przypadkach prawidłowymi nazwami urządzeń stają się… /dev/mapper/sdX zamiast /dev/sdX. Co więcej, urządzenia /dev/sdX nadal będą widoczne i to może wiele osób zmylić, bo nie będzie się ich dało zamontować, ani wykorzystać w inny sposób.

Przykładowo, jeśli ktoś wykorzystuje szyfrowanie to może ujrzeć coś takiego:

$ sudo cryptsetup luksOpen /dev/sdc1 sdc1
Enter LUKS passphrase:
Failed to setup dm-crypt key mapping.
Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/sdc1 contains
at least 258 sectors.
Failed to read from key storage
Command failed: No key available with this passphrase.

Szukanie przyczyny braku wsparcia dla aes-cbc-essiv:sha256 w jądrze lub wśród załadowanych modułów okazuje się całkowicie mylnym tropem, winna jest wyłącznie zmiana nazewnictwa urządzeń. Wystarczy zmienić w wywołaniu cryptsetup /dev/sdc1 na /dev/mapper/sdc1 i spróbować ponownie, aby uzyskać dostęp do swoich danych.

Na tego typu problemy najlepsza jest płyta LiveCD z dowolną dystrybucją, dzięki której dostaniemy się do plików /etc/fstab czy /etc/crypttab i dokonamy odpowiednich modyfikacji.

Po udanej aktualizacji możemy jeszcze dla pewności wpisać:

$ cat /etc/issue
Ubuntu 7.10 \n \l

Powodzenia!



3 Responses to “Aktualizacja Ubuntu 7.04 (Feisty Fawn) do Ubuntu 7.10 (Gutsy Gibbon)”

  1. November 12th, 2007 | 2:59 am

    Cryptsetup w Ubuntu 7.10 czasami sie wywala

    Tutaj jest link:
    https://bugs.launchpad.net/ubuntu/gutsy/+source/cryptsetup/+bug/132373

  2. November 28th, 2007 | 3:30 pm

    Ja tez mialem przykra zmylke z zamiana dyskow (/dev/sda2 na /dev/mapper/sda2).
    A odkrylem to, bo przestala montowac mi sie partycha NFTS:

    $ sudo mount /dev/sda2 /mnt/windows/
    fusermount: mount failed: Device or resource busy
    FUSE mount point creation failed
    Unmounting /dev/sda2 ()

    Dziala mi to:
    $ sudo mount /dev/mapper/sda2 /mnt/windows/

    Odpowiednia poprawke nanioslem do /etc/fstab

  3. Łukasz Wędrocha
    December 27th, 2007 | 3:19 pm

    Po czasie dowiedziałem się, że za te zamieszanie z /dev/mapper odpowiedzialny jest EVMS. Wystarczy go usunąć i wszystko powinno wrócić do normy:

    sudo apt-get remove evms

    Oczywiście jeśli ktoś tego używa powinien najpierw przemyśleć sprawę ;).

Skomentuj...

You must be logged in to post a comment.

The accumulation of points and extra discounts makes favorable re-order in Canadian drug pharmacy "'&$ drug list and permanent system of discounts for buyers.