Portál AbcLinuxu, 5. května 2025 19:43
2.6.18-0.2-default), že celý proces zatuhne a nezbyde než natvrdo comp (Thinkpad T60) vypnout a znova nastartovat - přičemž někdy klapne hned druhý pokus, jindy třeba 5x za sebou smůla...
Stává se to náhodně, ať je comp připojení do sítě anebo sólo (nevysledoval jsem žádnou pravidelnost), ale ve stále stejném místě: poslední funkční výpis bootovacího procesu bývá
udev on /dev type tmpfs (rw)
a v případě, že bootování pokračuje dobře, následuje
loop: loaded (max 8 devices)
V logu bootování nenajdu samozřejmě nic (protože se tam dostanu pouze když vše proběhne v pořádku).
Našel jsem náhodně rozházené podobné zprávy o tuhnutí openSUSE v různých konfiguracích a za různých podmínek, ale ani jedna se neshodovala (a řešení jsem nenašel snad nikde).
Jde o poměrně čerstvou instalaci z openSUSE DVD a plně aktualizovanou z oficiálních repozitářů - mám dojem, že se tento problém začal objevovat až po aktualizaci, ale vzhledem ke krátkosti vlastní instalace to nemusí nic znamenat, protože jsem relativně velmi málo rebootoval.
Ještě přidám, že na /home je šifrovaný souborový systém a že jsem se nehrabal ani v jádře, ani v konfiguračních souborech.
Uvítám jakýkoliv nápad či návrh řešení, případné další potřebné informace rád dodám. Díky.
PS. A to jsem si openSUSE vybral v bláhové naději, že se podobných překvapení v podobě zásadní nefunkčnosti systému nedočkám... nechutně padající Kontact v důležitých okamžicích se mi sice asi podařilo vyřešit jedním zápisem do kontactrc a na podobné "maličkosti" jsem připraven, ale je to opravdu trapné, když potřebujete zapnout comp a tolik opěvovaný Linux ne a ne naběhnout. V takovém případě musím prchat k Vistám, které jsem původně chtěl dočista odmazat. Tak nějak si ale najednou netroufám... a ani někomu předvádět výhody Linuxu 
Možná hloupost ale jsi si jistý že je RAM-ka a disk OK? Sám provozuju openSUSE 10.2 x64 na notebooku HP nx6125 (Turion/ATI) a problémy nemám
Možná hloupost ale jsi si jistý že je RAM-ka a disk OK? Sám provozuju openSUSE 10.2 x64 na notebooku HP nx6125 (Turion/ATI) a problémy nemámNe, to si jistý nejsem. Snad o víkendu najdu čas to otestovat (hlavně vybrat nějaké nástroje). Je mi jasné, že openSUSE na spoustě notebooků (i T60) běží bez problémů a že to pravděpodobně může být i chybou nebo nějakou specifickou konfigurací HW - teď ještě jak to přesně zjistit... Smůla asi je, že reklamovat notebook s tím, že na něm neběží Linux, v tomhle případě asi nepomůžek, protože doporučovaný systém je víte jaký
Prakticky jsem to na notebooku ještě nezkoušel ale asi nejlepší řešení by bylo spustit nějaké live distro které má minimálně memtest86 a s tím tu RAM-ku otestovat. S tím diskem nevím. Hlavně aby případný test nepoškodil data.
Pokud by byla RAM-ka OK, tak je tu možnost, že se něco opravdu pokazilo v software. Pak jen zkusit reinstalaci systému
Má verze kernelu je 2.6.18.8-03-default x86_64
Jejda, opravuji na Mám 
. Chtěl jsem to uvést pouze pro upřesnění mé konfigurace.
Neviem, ci to pomoze, ale ja mam kernel 2.6.18-0.3-default, takze odporucam skontrolovat updateUpdatoval jsem na .0.3 a evidentně to nepomohlo. Paradoxně nejhorší je, že to vytuhnutí se nestává vždycky... a když to naběhne, tak zase nemám chuť comp vypínat a testovat, jestli to naběhne i podruhé
Ja mam T60, ale x86 - nemam problemNo právě, možností kombinací je docela dost... a kdoví jestli svou roli nehrají i skvrny na slunci
Mounting local file systems... done proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) udev on /dev type tmpfs (rw)a konec, vždycky na tomto místě, ale ne vždycky
Co je vlastně ono
loop: loaded (max 8 devices)
které by mělo následovat, ale nenásleduje?
Později se objevili problémy s destrukcí paměti i ve windows. Dělá ti to od začátku nebo to začalo později?Prakticky od začátku, tj. asi 1 týden, protože ale jak píšu, občas se to neděje ... problém je, jakým způsobem to věrohodně otestovat, tj. někomu předvést. Čekat tedy na problémy i ve Windows?
Pokud se jedná o nějaké hardwarové problémy mohlo by to zlobit i ve windows. Akorát nevím jak otestovat doma základní desku. Třeba bude nakonec chyba jen v linuxu nezkoušel si jiné distro s novějším kernelem Ubuntu, Fedoru?Bohužel se s tím notebookem dostanu zatím jen k poněkud pomalému připojení na net, tzn. že instalovat a udržovat např. Arch nebo Gentoo je poměrně nepohodlné. Dále si také Visty pro sebe zarezervovaly přes půlku HD (asi 45G) a nechtějí se už dál zmenšovat, i když mají ještě 73% neobsazeno ... prý to budou potřebovat, což je dost hustý už samo o sobě. Uvidím, co se bude dít dál, tj. jestli se problém bude zhoršovat, postupně zkusím i novější jádra do SUSE a když ani to nepomůže, tak snad nějakou jinou distribuci... i když předtím bych se raději dopátral toho, kde může být chyba... tj. co je to ten "loop", který už nenaběhne, jestli např. s tím nemá přece jen něco společného ta zašifrovaná /home partišna, anebo jestli je chyba v "udev" - což je místo, kde pravidelně proces vytuhne (viz popis výše). OpenSUSE jsem zvolil na tenhle notebook (T60) po zralé uvaze, a tak nevím, jestli mám doufat raději v chybu HW anebo přece jen v nějaký skrytý bug SW
Zvlášt' to zamrzí u notebooku Lenovo které jsou známé svou podporou v linuxu
kernel-default-2.6.22_rc4_git3-2@i586
z Factory.
Pokud používáš smart tak přidej channel
[factory] type = yast2 name = factory disabled = yes priority = 5 baseurl = http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/odblokuj jej (
smart channel --enable factory), proveď update (smart update factory) a upgraduj (smart upgrade kernel-default).
smart channel --disable factory.
Zkus tam narvat jádro kernel-default-2.6.22_rc4_git3-2@i586
z Factory.
Nerad bych to zakřik, ale se zmíněným jádrem už se zatím povedly 4 pokusy ze 4, čili to opravdu vypadá na jádro, díky
Zkus pro jistotu s puvodnim jadrem vyvolat vytuh s parametrem jadra vga=normal (pridat do /boot/grub/menu.lst nebo rucne v grubu prikazdem bootu) ... treba se dozvime vic, uvidime. Nekdy to pomuze.Díky, zkusil jsem, ale nevypsalo se nic jiného než při bootování s výpisem do framebufferu.
2.6.22-rc4-git6-2-default nezaznamenal už několik dní při bootování žádný problém, považuji tímto problém za vyřešený. Díky za všechny tipy a rady.
Omlouvám se "komunitě", že si nebudu zpátky instalovat starší jádro a pokoušet se zjistit, kde ta chyba byla.
Ještě přidám, že na /home je šifrovaný souborový systém
Přidám jen, že na šifrování to nezáleží, když jsem ho odstranil, problém s distribučním jádrem (2.6.18) trvá. Nové jádro (2.6.22) vyřeší problém s bootováním, ale bohužel zase znemožní funkci wifi.
Zatím jsem nenašel žádný triviální a spolehlivý postup, jak tohle dilema vyřešit (viz link výše). Jediné řešení je snad čekat na 10.3...
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.