Dotaz: openSUSE 10.2 x86_64 při bootování zatuhne

[xkesh]

Několik dní už se mi stává při bootování openSUSE 10.2 x86_64 (jádro 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

Odpovědi

[Ladislav Sückr]

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

[xkesh]

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

Ne, 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ý

[Ladislav Sückr]

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

[xkesh]

Přes noc jsem nechal běžet memtest86+, asi 8 hodin, žádnou chybu neukázal. Dnes zatím 1:2 (1 úspěšný start ze 2 pokusů)... jelikož proces zastaví pokaždé ve stejném místě, jsem k chybě RAM spíš skeptický. Ještě zkusím nějak otestovat disk.

[miso]

Neviem, ci to pomoze, ale ja mam kernel 2.6.18-0.3-default, takze odporucam skontrolovat update a az potom riesit problem (mozno je to nieco uz opravene)
Ja mam T60, ale x86 - nemam problem

[Ladislav Sückr]

Má verze kernelu je 2.6.18.8-03-default x86_64

[miso]

No neviem, hned v prvej vete sa pise o verzii xxx-0.2xx ...

[Ladislav Sückr]

Jejda, opravuji na Mám . Chtěl jsem to uvést pouze pro upřesnění mé konfigurace.

[xkesh]

Neviem, ci to pomoze, ale ja mam kernel 2.6.18-0.3-default, takze odporucam skontrolovat update

Updatoval 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 problem

No právě, možností kombinací je docela dost... a kdoví jestli svou roli nehrají i skvrny na slunci

[xkesh]

Ještě doplním několik řádek výpisu bootování před vytuhnutím:

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?

[xkesh]

Projel jsem harddisk testovacími nástroji (zatím jen jednou), které nabízí výrobce na servisním oddílu (nějaký PC-Doctor či co) a všechny testy dopadly výborně. Dnešní statistika: 3x boot, z toho 1 vytuhnutí...

Protože zatím snad všechny pokusy startu v režimu FAILSAFE (tj. bez ACPI atd.) dopadly dobře, zkusím otestovat nějaké parametry startování.

I nadále děkuji za všechny nápady, odkazy nebo návrhy na řešení problému.

[Martin]

Četl jsem celou diskuzi a měl jsem doma na desktopu stejný problém(zaseknutí při bootu a pomohl jen reset). Nejdříve jsem podezříval pamět', ale pak jsem tam dal zapůjčenou od kamaráda a stejně to blblo. Postupně se bootovací proces zhoršoval až už fungoval boot jen s live CD. Nakonec jsem to odnesl do firmy která se specializuje na opravy PC. Celé mě to stálo 150 kč a tam zjistili, že je vadná základní deska. Linux byl na tyto problémy s deskou citlivější(neoprávněný přístup do paměti (SIGSEGV). 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?

[xkesh]

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?

[Martin]

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?

[xkesh]

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

[Martin]

Já tě chápu tohle je vždy hodně těžké když není zřejmé kde je chyba Zvlášt' to zamrzí u notebooku Lenovo které jsou známé svou podporou v linuxu

[Käyttäjä 11133]

Loop device může souviset se šifrovaným diskem, ale zavádí se i pokud se šifrovaný disk nepoužívá. A IMO to nehavaruje na loop, ale na tom, co následuje za loopem.

[Käyttäjä 11133]

Zkus tam narvat jádro 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).

[Käyttäjä 11133]

Poté zablokuj smart channel --disable factory.

[xkesh]

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

[jbohac]

obcas se stava, ze jadro by rado pri zdechnuti vypsalo spoustu uzitecnych informaci, ale zvaladne to jen kdyz vypisuje do textove nebo seriove knzole. Kdyz vypisuje do framebufferu, coz je nepomerne slozitejsi, tak uz to ve svem kritickem stavu nedokaze.

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.

[xkesh]

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.

[xkesh]

Protože jsem od výměny defaultního distribučního jádra za 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.

[xkesh]

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...