Błąd Po Update

[tofik]

po aktualizacji yumem do kernela 2.6.27.15-170.2.24.fc10 system na tym jądrze sie nie odpala wyskakuje komunikat

Unable to access resume device (/dev/dm-1) mount: could not find filesystem '/dev/root'

a aktualizacja nie zgłaszała błędów

pytanie co zrobić aby to naprawić czy po prostu czekać na nowy kernel

pozdrawiam

[exbros]

U mnie problem po ostatnim update nie wystapil, ale zdaje sie ze problem nie jest nowy i jest znany.

Zagladaj na ta strone, a moze wkrotce cos sie pojawi: https://bugzilla.redhat.com/show_bug.cgi?id=475266

[tofik]

Ok dzieki za info więc czekam

[Joker]

Siema,

miałem taki sam problem po aktualizacji i wynikał on ze źle skonfigurowanego pliku /etc/fstab.

Ten plik używany jest do ustalania katalogu root-a, punktów montowania itp. Prawdopodobnie masz zainstalowane stery do karty graficznej lub inne elementy systemu, które wymagają ponownego utworzenia obrazu initrd-2.6.27.15-170.2.24.fc10.img zaraz po instalacji nowego kernel-a. Program który tworzy ten obraz używa właśnie pliku fstab i to powoduje błąd(przynajmniej u mnie tak było ).

 

Rozwiązanie jest bardzo proste, wystarczy poprawić fstab i ponownie zbudować initrd-2.6.27.15-170.2.24.fc10.img

 

Niżej jest pokazane jak to zrobić:

 

Odszukujesz plik fstab:

su -

cd /etc/

ls -all |grep 'fstab'

Jeżeli pojawi się tylko jeden plik to sprawa będzie trochę trudniejsza, ponieważ będzie to oznaczać, że program który zmodyfikował ci fstab nie zrobił kopi zapasowej lub też problem nie leży tutaj.

 

Przyjmijmy na razie, że jednak masz jakiś plik w rodzaju fstab(-backup, -ntfs-config-save, lub coś w tym stylu). Otwierasz go w dowolnym notatniku:

gedit fstab-my-backup

Teraz robisz kopie zapasową "oryginalnego" fstab:

cp fstab fstab-backup-ZONK

Otwierasz fstab(np. gedit fstab) i szukasz wpisów, które jako <file system> mają podane /dev/dm-0 /dev/dm-1 itp. to są błędne wpisy. Porównaj te wpisy z drugim otwartym plikem, powinny tam być prawidłowe wpisy dotyczące <file system>, poniżej przykład:

1.Oryginalny błędny fstab

# <file system> <mount point> <type> <options> <dump> <pass>

sysfs /sys sysfs defaults 0 0

proc /proc proc defaults 0 0

/dev/dm-0 / ext3 defaults 1 1

/dev/dm-1 swap swap defaults 0 0

2.fstab-...(kopia zapasowa)

# <file system> <mount point> <type> <options> <dump> <pass>

sysfs /sys sysfs defaults 0 0

proc /proc proc defaults 0 0

/dev/VolGroup00/LogVol00 / ext3 defaults 1 1

/dev/VolGroup00/LogVol01 swap swap defaults 0 0

Jak widać <file system> różnią się w tych dwóch plikach. Teraz wystarczy podmienić wartości dm-* odpowiednimi z drugiego pliku, a następnie zapisać plik fstab i wywołać następujące polecenie co utworzy i nadpisze obraz initrd.

mkinitrd -f -v /boot/initrd-2.6.27.15-170.2.24.fc10.i686.img 2.6.27.15-170.2.24.fc10.i686

lub

mkinitrd -v /boot/initrd-`uname -r`.img `uname -r`

lub

mkinitrd -f -v /boot/initrd-*.img *

 

Jeżeli nie masz kopi zapasowej pliku fstab(zrobionej przez jakiś program który źle go nadpisał) musisz przy użyciu konsoli zorientować się jaki system plików jest powiązany z jakim punktem montowania. Na forum jest na pewno mnóstwo postów, które opisują jak to zrobić, więc nie będę się tutaj powtarzał (Jeżeli masz Logiczną partycje to pamiętaj o lvm ).

[@WalDo]

su -

cd /etc/

ls -all |grep 'fstab'

Zapewniam, że podobny efekt uzyskasz podając polecenie

ls -l /etc/*fstab*

 

Przed jakimkolwiek ruchem na initrd należy bezwzględnie zrobić kopię starego.

 

mkinitrd -f -v /boot/initrd-2.6.27.15-170.2.24.fc10.i686.img 2.6.27.15-170.2.24.fc10.i686

A co jeśli kolega tofik ma inną wersję jądra (np.dla systemu 64-bitowego lub po prostu nowszą 2.6.27.15-170.2.35)?. Jedyną poprawną metodą jest

mkinitrd -v /boot/initrd-`uname -r`.img `uname -r`

ktora podstawi poprawnie wersję aktualnie wykorzystywanego kernela. Nawet w tym przypadku należy zachować pewną ostrożność i zwrócić uwagę na kierunek apostrofów (tzw. odwrócone apostrofy) - najczęściej znak ten znajduje się na lewo od klawisza "!/1".

 

tofik - sądzę, że jeśli nie było problemów z poprzednią wersją to spokojnie możesz z niej korzystać i czekać na poprawkę. Chyba, że lubisz eksperymenty z odrobiną adrenaliny. BTW jak już wspomniałem pojawiła się ciut świeższa wersja 2.6.27.15-170.2.35, więc moze poprawiło się coś?

[Joker]

Trochę namieszałem z tym initrd

 

A co jeśli kolega tofik ma inną wersję jądra (np.dla systemu 64-bitowego lub po prostu nowszą 2.6.27.15-170.2.35)?. Jedyną poprawną metodą jest

mkinitrd -v /boot/initrd-`uname -r`.img `uname -r`

Jeżeli odpalisz to polecenie z wartościami `uname -r` to poda ci ono wartości obecnego kernel-a, a z tego co napisał tofik wynika, że ma on jakiś działający kernel, a ten nowszy nie chce się uruchomić(tak jak to było u mnie). Jak on to uruchomi to zrobi sobie nowy obraz i nadpisze stary poprawny dla kernel-a na którym to robi. Najlepiej jest sprawdzić w pliku "/boot" jakie masz już obrazy i tym się kierując stworzyć nowy.

 

Przepis jak to zrobić:

1. Sprawdzasz całą nazwę kernel-a, który się nie uruchamia (np. 2.6.27.19-170.2.35.fc10.i686)

2. Odpalasz system ze starego, działającego kernel-a i w konsoli wpisujesz:

uname -r

To jest wersja initrd, którego nie powinieneś nadpisać.

3. Sprawdzasz jakie masz już obrazy initrd

ls /boot |grep 'initrd'

Powinno ci wyskoczyć coś w tym stylu:

initrd-2.6.27.12-170.2.5.fc10.i686.img

initrd-2.6.27.15-170.2.24.fc10.i686.img

initrd-2.6.27.19-170.2.35.fc10.i686.img

4. Jeżeli znajdziesz nazwę obrazu zgodną z punktem 1 to możesz teraz skopiować całą nazwę(ale bez .img ) tego obrazu i zrobić jego kopię

cp initrd-[nazwa obrazu].img initrd-[nazwa obrazu].img-backup

5. Teraz wystarczy zbudować i nadpisać stary obraz

mkinitrd -f -v /boot/initrd-[nazwa obrazu].img [nazwa obrazu]

 

Pamiętaj żeby przed tym wszystkim zmienić plik fstab. Jeżeli to nie pomoże lub nie masz żadnych obrazów initrd to znaczy, że jednak jest coś nie tak z tym nowszym kernel-em albo po prostu coś w konfiguracji gruba jest źle ustawione

 

W moim przypadku plik fstab zmieniło mi narzędzie do konfiguracji partycji NTFS, jeżeli masz je też zainstalowane to jest duże prawdopodobieństwo, że też ci coś namieszało i jedynym sposobem żeby to odwrócić jest ręczna zmiana fstab. Nowy kernel nic tutaj nie pomoże :/

[tofik]

Witajcie ponownie otóż już wszystko działa rzeczywiście wystarczyło poprawić plik fstab oraz wywalić niedziałający plik obrazu z /boot i ponownie wygenerować nowy

Tak tylko informacyjnie piszę że aktualizacja z jądra tego co w temacie do nowszego zaczęla ciągnąć ten bład i system nie wstawał ten sam błąd powstawał na nowym jądrze

I mam jeszcze takie pytanie z ciekawość skoro tak jak napisał Joker użyłem narzędzia do konfiguracji partycji ntfs ale to bylo tylko raz i to dawno temu zaraz po instalacji fedory na świeżo i potem go nie użyłem ani razu to dlaczego po którejś aktualizacji zadziało się coś takiego

 

pozdrawiam wszystkich

Edytowane Marzec 4, 2009 przez WalDo
j → J - taki szacunek dla nicka usera ;)