Nowe posty

Autor Wątek: Dziwny problem z udev  (Przeczytany 5059 razy)

adkrz

  • Gość
Dziwny problem z udev
« dnia: 2009-02-05, 16:22:27 »
Witam. Mam Debiana Etch (jądro 2.6.18-6-686 z paczki, zaktualizowane). Od jakiegoś czasu (prawdopodobnie od jakiegoś upgrade'u) mam dziwny problem z systemem. Mianowicie raz na jakies 2-3 uruchomienia systemu udev odmawia posłuszeństwa. Daję komunikaty startowe:
Begin: Running /scripts/init-bottom...
kill: Could not kill pid '1049': No such process
Done
udevd[386]: udev_rules_init: could not read '/etc/udev/rules.d/z60_xserver-xorg-input-wacom.rules': No such file or directory
udevd[386]: udev_rules_init: could not read '/etc/udev/rules.d/z99_hal.rules': No such file or directory
[b]//tych błędów czasem jest więcej, spisałem te co były podczas ostatniego uruchomienia[/b]
INIT: version 2.86 booting
Setting hostname to 'linux' ... done
* .udev/ already exists on the static /dev!
Starting the hotplug events dispatcher: udevdudevd[1270]: init_udevd_socket: bind failed: Address already in use
error initializing udevd socket
failed!
* Files under mount point '/dev/pts' will be hidden.

[b]Uruchamianie swapa, zegara etc - bez przeszkód[/b]

Will now check all file systems.
Failed to open the device '/dev/hdb1': No such file or directory
[b]//dodam, ze hdb1 znajduje się fizycznie na drugim dysku w stosunku do systemu (system jest na hda)[/b]
(... komunikaty od fsck...)
fsck died with exit status 8
* File system check failed
(...)
Give root password for maintenance
(or type Control-D to continue):
Jeżeli będę kontynuował rozruch, system zawiesi się na logo nVidia.
Jeżeli widzę te komunikaty na początku, od razu wciskam reset, zawsze po zresetowaniu system odpala.
Nie jestem w stanie określić, czy jakaś konkretna czynność powoduje ten błąd - po prostu czasem sie włączy normalnie, czasem wywala takie komunikaty.
Próbowałem oczywiście przeinstalować kernel, udev'a, hal, initramfs-tools... i dalej nic. Proszę o porady....

arctgx

  • Gość
Dziwny problem z udev
« Odpowiedź #1 dnia: 2009-02-05, 17:40:51 »
Miałem taki jakiś miesiąc temu w swoim Debianie, ale po ingerencji w skrypty startowe na rzecz skrócenia startu. Nie wiem dlaczego, ale problem ustępował, kiedy z linii komend jądra wyłączałem bootchartd jako pierwszy (pomiarowy) proces (init). Wyłączenie CONCURRENCY=startpar (zamiast tego "none", w /etc/default/rcS) nic nie dało. A równoległe uruchamianie usług było pierwszym podejrzanym, a to dlatego że pewne usługi mogły korzystać z plików, których UDEV nie zdążył utworzyć. Nie jestem jednak pewien czy Debian na tym etapie w ogóle stosuje startpar do trybu single, a na szybko nie znalazłem informacji.

Byłem w sytuacji o tyle gorszej, że /usr czy /tmp mam na osobnych partycjach.

Nie przypominam sobie, kiedy i w jaki sposób problem zniknął. Dość często aktualizowałem jądra z kernel.org.

adkrz

  • Gość
Dziwny problem z udev
« Odpowiedź #2 dnia: 2009-02-05, 19:02:09 »
Hmmm. Tylko że tutaj błędy udev'a zaczynają się jeszcze przed wczytaniem się procesu init, a więc przed skryptami włączającymi usługi. Mam standardowego init'a, nie korzystam z bootchartd. Owszem, bawiłem się równoległym uruchamianiem procesów, ale to dopiero na późniejszym etapie rozruchu.
Jak już pisałem, czasem się pojawia więcej błędów z gatunku "no such file or directory". Teraz przy uruchomieniu miałem na przykład brak takich plików:
025_logitechmouse.rules
50-udev.rules
60-persistent-input.rules
60-persistent-storage.rules
60-vboxdrv.rules
70-persistent-cd.rules
80-drivers.rules
95-late.rules
libnjb.rules
z60_alsa_utils.rules
libsane.rules
...
Oczywiście po pierwszym resecie wszystko działa a pliki są na swoim miejscu.

arctgx

  • Gość
Dziwny problem z udev
« Odpowiedź #3 dnia: 2009-02-06, 01:51:53 »
Jeśli nie widać plików urządzeń, które miał stworzyć UDEV, to jeszcze normalna sprawa. Dlaczego jednak nie widać plików z regułami, które są dostępne w głównym systemie plików, jeśli system został prawidłowo zamknięty?

Dwa lata temu używałem testowej wersji Debiana (testową był chyba właśnie etch) i zdarzyła mi sie sytuacja ze znikającymi binarkami Xorg. Pod ręką musiałem mieć paczki debianowe dla ich przywracania... Zbudowałem system plików od nowa, przywróciłem kopie z archiwum tar i problem zniknął. Czy z jakiegoś powodu musisz używać etch zamiast zaktualizować do np. lenny?

adkrz

  • Gość
Dziwny problem z udev
« Odpowiedź #4 dnia: 2009-02-07, 16:37:42 »
W sumie to przy Etchu trzyma mnie tylko sesja i potrzeba posiadania sprawnego komputera ;) Może to nawet i dobra okazja do wielkiej aktualki jeśli nie ma lepszych pomysłów...

arctgx

  • Gość
Dziwny problem z udev
« Odpowiedź #5 dnia: 2009-02-07, 18:30:31 »
Zawsze możesz użyć jakiegoś Debiana w wersji Live, choćby niezłego Knoppiksa lub nie sprawdzonego przez mnie Debiana Live z np. http://live.debian.net/debian-cd/5.0_beta2/i386/iso-cd/ (zamrażany do wersji stabilnej Lenny).

Aktualizację możesz wypróbować na działającym systemie przy założeniu, że nie będziesz budował od nowa systemu plików. A zbudować by warto.

Przy okazji: ostatnio wypróbowałem EXT 4 (tworzenie na Fedorze 10 Live, jądro z kernel.org) - nieporównywalnie szybciej wykonywane jest pełne sprawdzanie systemów plików po nieprawidłowym ich odłączeniu. Standardowo jednak Lenny tego nie oferuje.