Udev bosszankodas

Ugy latszik megint ujitottak a sracok. Mostanaban elkezdte minden Linux azt jatszani, hogy neha nem megy tovabb a boot a "Waiting to uevents to..." kezdetu sornal. Valami negyed ora utan mar hajlando tovabblepni (gondolom valami timeout jarhat le, talan korabban is, csak amikor ezt teszteltem, otthagytam).
Ha ujrainditom a gepet, akkor 50%-os esellyel tovabbmegy a boot.

Es nem egy Linux disztro csinalja, hanem tobb, ugyhogy ez valami gyokeres problema, jelenleg az openSUSE es az Arch Linux-rol biztosan tudom, hogy erintett. Es erdekes modon a 2.6-os kernelek is erintettek, annyi difivel, hogy ott kevesebbszer jon elo a problema. 3.x-es kernellel viszont gyakorlatilag minden masodik bootolas ilyen.

Mar nem tudok mire gondolni... mivel ez a ruhes udev nem irja ki, hol akadt el (azon a szinten meg syslog nincsen, a kernelbol pedig printk uzenet nem jon ki), igy otletem sincs, valojaban mi baja van. Az biztos, hogy nem a binaris nvidia driver, mert ha fenn van, ha nincs, a problema megvan.

Hozzászólások

Nekem is feltűnt. Nem lehet, hogy mégis valamilyen nvidia bug lesz? Nekem csak nvidia kártyával jön elő (Gf 9500GT, ubuntu 12.04). Az otthoni gépemmel nem fordult még elő (HD3870, szintén 12.04).

Hat nem tudom. Az az erdekes (de nem tudom, hogy relevans-e, vagy egyaltalan ez okozza-e), hogy amig nem rakom fel a zartforrasu nvidia drivert, addig minden fasza (legalabbis addig a 2-3 ujrainditasig, amig eljutok oda), utana viszont eloall ez a hiba. Akkor is, ha a vegen leszedem a drivert (jelenleg nouveau-val megy a lapos).
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

nekem "waiting for /dev to be fully populated ..." résznél akadt el anno ubi 10.04, mostanság meg mint 12, lmde és fedora 17 is ... igaz ati hd 3470 -es kari van a notiban, de ugyanúgy az atis driver telepítése után akadozott ... elvileg az acpi nem tetszett neki, BIOS -t visszatoltam alap beállításra és azóta nincs ilyen gondom (legalábbis mint 13 -al) :)

Jó ez a debian én mindég mondom. ;-)

Nem találkoztam még a hibával.
(2.6.32 alapú cucc)

udevd a daemon.log-ba naplózott utoljára, mikor frissítettem squeezere, hogy a SYSFS{} göncöket majd jövőbeli udev verzióban eltávolítják, és leszek szíves javítani.

Mióta ezt megcsináltam, azóta se pofázott még vissza.

Se a kasznin nem fordult még elő (nvidia bináris driver), se a néha erre járó csodainteles laptopon az említett jelenség.
mindkettő debian, mindkettő squeeze, mindkettő 2.6.32.y...

Nvidia driver 195.36.31

Az udev verzióra valami 164-3 -at ír. Tippre talán az lehet, hogy vagy a kernel túl új a disztróban levő udev verzióhoz, vagy fordítva :-)

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

Nem hiszem, ha tul uj lenne a kernel az udevhez, azt sztem megnyuglodne, illetve akkor minden boot nyugos lenne.

Egyebkent az opensuse 11.4 az kb. a mostani debiannal van egy verzion (squeeze), szoval - bar nem tudok fejbol pontos verziokat - nekem is problemamentesnek kellene legyen...

A SYSFS cuccokra en is emlekszem, azt mar javitottam is (az androidos telo usb cuccanak jogosultsaganak fixalasahoz van benn egy rule).

En eddig meg _soha_ nem talalkoztam ezzel a jelenseggel, meg ezen a laptopon se. Ez valami uj...

A tul meleg vidkartyat kizartam, mert hideginditasnal is nyuglodk neha (bar akkor ritkabban, de mivel eleve random jelenik meg a bug... nem tudom ez is mennyire relevans...)
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Egyebkent az opensuse 11.4 az kb. a mostani debiannal van egy verzion (squeeze), szoval - bar nem tudok fejbol pontos verziokat - nekem is problemamentesnek kellene legyen...

A)- Hát ha csak egy ideje jön elő, akkor valami frissítési mellékhatás lehet, ha nem frissült semmi ergo nincs szoftveres oka,
akkor csak hw lehet.../ vinyó ?, smartctl ? memtest ? venti (?) /

B)- Meg kell nézni mikor frissült a kernel, illetve az udev,
és mikor jelentkezett előszőr a probléma. Gondolom a kern.log ból simán kiderül mikor indítottad újra a gépet 20msp után :-),
valszeg az volt az első alkalom, aztán nyílván suse ban is van frissítési napló, mint debianban az aptitude.

C) BIOS nem valószínű, akkor már korábban is problémázott volna,
hacsak nem frissítetted/állítgattad mostanában.

Egyebkent az opensuse 11.4 az kb. a mostani debiannal van egy verzion (squeeze), szoval - bar nem tudok fejbol pontos verziokat - nekem is problemamentesnek kellene legyen...

Tipp gyári kernel 2.6.32 gondolom,
ha újabb akkor opensuse 11.4 + debian kernel vagy (grsec/vanilla) 2.6.32.y...

bar akkor ritkabban, de mivel eleve random jelenik meg a bug... nem tudom ez is mennyire relevans...)

D) Én valami olyasmire tippelek, hogy egyes eszközök betöltődési sorrendje nem felel meg az udevnek,
valamiféle időzítési gebasz, lehet hogy hiányol valami kernel modult (?), vagy valami egyebet,
tippre azzal lehet gondja amit a 15 perc molyolás után végre betölt, elindít/macerál elsőnek (?).

E) Régebben rémlik valami 2.6.huszonvalamennyinél,
hogy nem volt mindegy melyik usb drivert töltötte be előszőr,
ehci, vagy uhci/ohci... (!), ha nem volt jó a sorrend,
akkor nyavalygott a kernel mindenféle warningokkal.
néha eltalálta a sorrendet saját erőből, néha nem,
aztán eluntam és már az initramfs-ben elrendeztem,
hogy micsináljon.
Akkor volt olyan bug is, hogyha volt bent cd/dvd bootoláskor,
akkor nem detektálta megfelelően a cd/dvd
sebességét...Sz'al ezzel csak arra utalok,
hogy voltak már hasonló bugok, meg lesznek is,
amíg ez a fejlesztési modell marad. :-D

Ha ez van, azon segíthetsz egy initramfs kernellel segíthetsz (?) azzal a bootolási eszközmodul betöltés elég jól bolygatható,
csak meg kell találni a nyűgös modult.
Hálózat (?) DHCP-re vár (?) NFS mount (?)

U.I: udev.conf-ban tudsz beállítani naplózási mélységet, hátha kiderül valami...:

udev_log="debug"...

mondjuk összehasonlítani egy jó bootolás+leállás
és egy ezt követő hibás indulást.
Hátha a rossz bootolás előtt valami hibásan, rosszul áll le, akár ez is kiderülhet...

U.I 2: (tegyél fel egy debian squezet, és problem solved :-D
/ na jó csak vicc volt /
--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

"Gondolom a kern.log ból simán kiderül mikor indítottad újra a gépet 20msp után"

Sajnos ez nem ilyen egyszeru. A syslog akkor meg nem bootol fel, az kozvetlen ez utan jonne.

Kozben rajottem, h tudok nezni verzioszamot: 2.6.37.6-0.11-default az opensuse 11.4, de Arch Linux-szal is bugos, az meg valami 3.4.x

Az udev logoltatast koszi, nagyon remelem, hogy nem syslogba logol.

Halozat sztem nem, mert wifi olyankor meg ugye nem, a halokartyan meg eleve nincs link, szoval ott mar joval hamarabb meghalna.

Tenyleg az a gondom, hogy a kernel cmdline-ban nincs bene a quiet, megse kapok logokat a kepernyore. Legalabbis a 3.x-nel.

Azt jutott kozben eszembe, hogy leirom: amikor elkezdi "populalni" a cuccokat, akkor latom, hogy teker a winyon. Amikor jo a boot, akkor egesz sokaig teker, es amikor tovabblep, akkor tovabb tekeri a winyot (tehat nincs hosszu szunet a winyoled villogasaban). Amikor szar a boot, akkor tekeri a winyot, majd leall, es utana mar nem is nyul hozza.

Ami erdekes meg: Ctrl-C-vel leloheto mindket Linux alatt a stuff, olyankor ugyan nincs hostnev meg /home, meg a / is read-only de ezek mind javithato problemak.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Ami erdekes meg: Ctrl-C-vel leloheto mindket Linux alatt a stuff, olyankor ugyan nincs hostnev meg /home, meg a / is read-only de ezek mind javithato problemak.

Hát akkor meg tökegyszerű, csinálsz valami írható göncöt és
dmesg > szarfosgenya.log
lsmod >> szarfosgenya.log

aztán kész, majd csak kiderül valami.

Amelyik eszköznek a cucca ezután töltődik/töltődne be, az a bűnös (!)

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

Nekem egy laptop csinálja ugyanezt ha rá van dugva egy usb-s egér.
Ha kihúzom akkor azonnal tovább megy, ill. ha nincs rádugva, akkor elő sem jön a probléma.
Ubuntu 12.04 van rajta.