Zawieszenie ładowania Systemu

[zabezpieczeniowiec]

Witam

 

Używam FC4 . Zainstalowany na PIII 500 , używany od 3 miesięcy .

Mam czasami problem z długim czasem do pojawienia się okna logowania .

Ładuje się tryb graficzny , pasek postępu uruchamiania kończy się i nic .

Przechodzę wtedy pomiędzy trybem konsoli i graficznym i udaje się zobaczyć okienko logowania .

Czasem nie chce mi się już czekać na to żeby się pojawiło okno logowania i resetuję sprzęt .

 

Nie wiem gdzie szukać dziury .

Co o tym sądzicie

Pozdrawiam

Marcin

[@Sorror]

Dawno temu podobne objawy występowały na FC2 zainstalowanych na ext2. Dziś nie mam pojęcia.

[wachu0809]

ja proponuje wywalic z grub.conf wpis (rhgb)

to spowoduje ze tryb graficzny bedzie sie wlaczal dopiero po wystartowaniu wszystkiego (uslug demonow...)

i jak sie moze przyjrzysz co ci sie laduje i ktore uslugi potrzebuja najwiecej czasu na wlaczenie to troszke sie temat przejasni

 

jak nie dokladasz nic nowego to radze wylaczyc kudzu - odpowiada za wyszukiwanie nowych urzadzen przy starcie systemu

i pare innych uslug ktore na pewno sa zbedne.. na forum bylo o tym (przyspieszy ladowanie systemu)

[zabezpieczeniowiec]

Wielkie dzięki .

 

Sposób z usunięciem z grub.conf (rhgb) przyspieszył start .

Czasami przydałoby się dać użytkownikowi przy rozruchu żeby od razu było okienko logowania graficzne bez tekstów w konsoli .

 

Z usług wywaliłem wszystko co się nie przydaje teraz : kudzu , gpm ,pcmcia , isdn ,wine .

Działa sprawnie .

 

Nie jestem pewien czy rhnsd jest niezbędny jeżeli będę chciał robić update .

[SeeM]

nie jest potrzebne; i tak system aktualizuje się za pomocą yum, a nie up2date

[wachu0809]

Czasami przydałoby się dać użytkownikowi przy rozruchu żeby od razu było okienko logowania graficzne bez tekstów w konsoli .

 

mozesz dodac do gruba wybor

 

juz masz aby nie uruchamial w trybie graficznym

 

dodaj drugi w ktorym bedzie wpis (rhgb)

 

rozumiesz tak jak bys mial inny system tylko ze uruchamiasz to samo z dodatkowa flaga rhgb

[eXt]

Mam czasami problem z długim czasem do pojawienia się okna logowania .

Ładuje się tryb graficzny , pasek postępu uruchamiania kończy się i nic .

Przechodzę wtedy pomiędzy trybem konsoli i graficznym i udaje się zobaczyć okienko logowania .

Czasem nie chce mi się już czekać na to żeby się pojawiło okno logowania i resetuję sprzęt .

Ile mniej więcej czasu musisz czekać na pojawienie się okienka? Pytam bo mam podobny problem, z tym, że jeszcze nigdy się nie doczekałem na ekran logowania. Co gorsza u mnie też najpierw problem występował okazjonalnie i po resecie normalnie się logowałem, ale od 2-ch dni niemożność normalnego zalogowania się do systemu jest stanem permanentnym. Za każdym razem muszę przełączyć się na drugą konsolę (powrót na pierwszą konsolę pokazuje zazwyczaj biały lub "zawieszony" ekran), zalogować się i startx-nąć

 

Przeglądałem logi (message, xorg), googlałem, reinstalowałem i wywalałem stery do grafy (radeon 9600), zmieniałem ekrany logowania, sprawdzałem na starszych kernelach (system jest w pełni zupdateowany) i nic, za kazdym razem zwis, a w logach nie ma żadnych błędów , albo nie umiem ich znaleźć.

 

Testowałem też wywalenie rhgb quiet, ale nie rozwiązuje to problemu, wszystkie uslugi sie uruchamiają, potem się loguję i muszę jeszcze wklepać startx i.. X-y wstają bez problemu, tak jak przy przełączeniu konsoli. Ja jednak chcę żeby to normalnie działało. Co to może być, bo ja już nie mam pomysłów? Nadmienię, że jestem __użytkownikiem__ linux-a, a nie adminem. Jeszcze trochę to z powodu tych zwisów zmienię dystrybucję. Aha - próbowałem robić upgrade z płytki instalacyjnej, ale też nic to nie dało

[gajownik]

Za każdym razem muszę przełączyć się na drugą konsolę (powrót na pierwszą konsolę pokazuje zazwyczaj biały lub "zawieszony" ekran), zalogować się i startx-nąć

Takie rzeczy zgłasza się w https://bugzilla.redhat.com/ bo to nie jes tnormalne i nie występuje u wszystkich użytkowników.

reinstalowałem i wywalałem stery do grafy (radeon 9600)

Instalowałeś binarne sterowniki? Które? Te z ati.com czy z rpm.livna.org? Czy taka sama sytuacja jest ze standarowymi sterownikami (wywalienie driverowm z ati.com nie pomoże, bo zostawiają one śmieci)?

[eXt]

Za każdym razem muszę przełączyć się na drugą konsolę (powrót na pierwszą konsolę pokazuje zazwyczaj biały lub "zawieszony" ekran), zalogować się i startx-nąć

Takie rzeczy zgłasza się w https://bugzilla.redhat.com/ bo to nie jes tnormalne i nie występuje u wszystkich użytkowników.

Czyli tutaj pyta się tylko o to co jest normalne i występuje u wszystkich? Nie jestem specem od linux-a i nie wiem czy to ja coś namieszałem, czy to faktycznie jakiś bug, nawet nie wiem co dokładnie się zawiesza, dlatego tutaj pytam o wskazówki, które pozwolą mi to określić.

 

Dzięki jednak za sugestię, przeszukałem bugi na redhatowej bugzilli i znalazłem to. U mnie również, najczęściej, po uruchomienu hal-a następuje zwis, no czasem (start w trybie interaktywnym) uda się jeszcze odpalić ostatnią po hal-u usługi "local". Dziwne, ale może to ma coś wspólnego.

 

reinstalowałem i wywalałem stery do grafy (radeon 9600)

Instalowałeś binarne sterowniki? Które? Te z ati.com czy z rpm.livna.org? Czy taka sama sytuacja jest ze standarowymi sterownikami (wywalienie driverowm z ati.com nie pomoże, bo zostawiają one śmieci)?

Miałem zainstalowane stery z livny. Potem je wywaliłem, następnie probowalem binarki z ati.com, potem znowu livna na innym kernelu. A odnośnie standardowych sterowników to powiedz mi co mam zrobić aby je uaktywnić, skoro zwykłe wywalenie driverów ati/livna nie wystarcza.

 

Pozdrawiam

[gajownik]

Czyli tutaj pyta się tylko o to co jest normalne i występuje u wszystkich?  Nie jestem specem od linux-a i nie wiem czy to ja coś namieszałem, czy to faktycznie jakiś bug, nawet nie wiem co dokładnie się zawiesza, dlatego tutaj pytam o wskazówki, które pozwolą mi to określić.

Nie, nie, nie. Źle mnie zrozumiałeś. Chodziło mi o to, że takie błędy trzeba zgłaszać w bugzilli, bo inaczej nie zostaną poprawione.

 

Oczywiście na forum można sobie pisać do woli, byleby na temat ;-) W takich sytuacjach bez skontaktowania się z deweloperami jednak się nie obejdzie :/

przeszukałem bugi na redhatowej bugzilli i znalazłem to. U mnie również, najczęściej, po uruchomienu hal-a następuje zwis, no czasem (start w trybie interaktywnym) uda się jeszcze odpalić ostatnią po hal-u usługi "local". Dziwne, ale może to ma coś wspólnego.

Czy wyłaczenie usługi hal "rozwiązuje" Twój problem?

A odnośnie standardowych sterowników to powiedz mi co mam zrobić aby je uaktywnić, skoro zwykłe wywalenie driverów ati/livna nie wystarcza.

Wywalenie paczek z livny wystarczy. Tych z ati -- nie. Tak się pytam o sterowniki, bo czasami to one powodują takie problemy (szczególnie te binarne).

[eXt]

Czy wyłaczenie usługi hal "rozwiązuje" Twój problem?

Wywaliłem hala (odinstalowałem), po reboocie system próbuje wstawac i na koniec następuje twardy zwis, nawet mysz nie działa. Uruchomiłem kompa w trybie konsoli i zainstalowalem hal-a i.. nadal twarde zwisy (czyli gorzej niż było). Na dokładkę startx powoduje teraz uruchomienie nie Gnome ale KDE!? Polecenie: switchdesk gnome wypisuje że gnome nie jest zainstalowany. Po reinstalacji HAL-a?? Ale jaja

 

Wywalenie paczek z livny wystarczy. Tych z ati -- nie. Tak się pytam o sterowniki, bo czasami to one powodują takie problemy (szczególnie te binarne).

Teraz mam paczki z ati - jak więc zrobić aby przejść z nich do zwykłych sterowników?

 

Pozdrawiam

[@perl]

sprobowalbym starszych sterownikow ati, oczywiscie z livna (tych od ati nie instaluj)

 

mam najnowsze stery ati i juz kilkanascie razy zaobserwowalem zwiechy z ich powodu, najczesciej przy logowaniu i wylogowywaniu,

 

 

[gajownik]

Wywaliłem hala (odinstalowałem)

Chciałem tylko, byś sprawdził wyłączenie usługi (programem ntsysv albo system-config-services), a nie usuwał cały pakiet.

Uruchomiłem kompa w trybie konsoli i zainstalowalem hal-a

Tę samą wersję co była czy jakąś inną? Odpal system w trybie rescue → http://www.fedorafaq.org/basics/#rescue , chrootnij się do systemu, zainstaluj yum-utils i odpal:

package-cleanup --problems

Na dokładkę startx powoduje teraz uruchomienie nie Gnome ale KDE!?

Co masz w pliku ~/.dmrc?

Polecenie: switchdesk gnome wypisuje że gnome nie jest zainstalowany.

W jaki sposób usunąłeś hal? `rpm -e hal --nodeps' czy `yum remove hal'? Jeśli to trugie, to się nie dziw, że nie masz Gnome Gnome zależy od hal, więc musiał zostać razem z nim odinstalowany. Jeśłi to pierwsze, to nie dziw się, że system pada ;-) W 99.9% przypadków opcja `--nodeps' nie powinna być nigdy użyta, bo powoduje efekty podobne jak u Ciebie.

Teraz mam paczki z ati - jak więc zrobić aby przejść z nich do zwykłych sterowników?

To nie jest takie proste teraz. Ciężko mi powiedzieć co faktycznie zmienia paczka ati w systemie. Wystarczy przejrzeć skrypty w niej zawarte (rpm -qp --scripts fglrx_6_8_0-8.19.10-1.i386.rpm) -- aż się włosy jeżą na głowie. Podmieniają biblioteki, kasują pliki, itd. Całkowicie przeczy to idei pakietów RPM.

 

Najpiewniej będziesz musiał przeinstalować xorg-x11-Mesa-libGL albo nawet całe X-y. Ale zrobiłeś bałagan w systemie :/

[eXt]

Chciałem tylko, byś sprawdził wyłączenie usługi (programem ntsysv albo system-config-services), a nie usuwał cały pakiet.

Zmieniłem skrypt startowy żeby się usługa nie startowała, ale potem pomyślałem, że może lepiej reinstalnąć hala, albo w ogóle usunąć skoro to najpewniej on powoduje problemy.. no i spróbowałem. Fakt: dalem yum remove hal, ale kurcze nie wypisał mi, że coś jeszcze zostanie usunięte, a zazwyczaj to robi. Sam proces usuwania hala trwał ledwie kilka sekund i nie myślałem, że zdążył całego gnome wyciąć.

 

Tę samą wersję co była czy jakąś inną?

yum install hal.. chyba tą samą bo wcześniej system był w pełni zaktualizowany.

 

Odpal system w trybie rescue → http://www.fedorafaq.org/basics/#rescue , chrootnij się do systemu, zainstaluj yum-utils i odpal:

package-cleanup --problems

package-cleanup --problems

Setting up yum

Reading local RPM database

Processing all local requires

No problems found

 

Co masz w pliku ~/.dmrc?

session=default, a w /etc/sysconfig/desktop: DESKTOP="GNOME", ale skoro nie ma gnome to i tak sie on nie wystartuje.

 

To nie jest takie proste teraz. Ciężko mi powiedzieć co faktycznie zmienia paczka ati w systemie. Wystarczy przejrzeć skrypty w niej zawarte (rpm -qp --scripts fglrx_6_8_0-8.19.10-1.i386.rpm) -- aż się włosy jeżą na głowie. Podmieniają biblioteki, kasują pliki, itd. Całkowicie przeczy to idei pakietów RPM.

Najpiewniej będziesz musiał przeinstalować xorg-x11-Mesa-libGL albo nawet całe X-y. Ale zrobiłeś bałagan w systemie :/

Co to znaczy przeinstalować? yum remove org.. i potem wylatuje wszystko zalezne? Czy moze wywalenie z nodeps i potem instalacja? A i tak chyba zrobię reinstalację całego systemu, bo mnie wkurza ten bajzel, który się zrobił.

[gajownik]

Fakt: dalem yum remove hal, ale kurcze nie wypisał mi, że coś jeszcze zostanie usunięte, a zazwyczaj to robi. Sam proces usuwania hala trwał ledwie kilka sekund i nie myślałem, że zdążył całego gnome wyciąć.

A to dziwne. yum zawsze wypisuje to co usuwa. Może wczesniej jakoś wywaliłeś Gnome? Przejrzyj logi w /var/log/yum.log.

yum install hal

Czyli w porzadku.

session=default, a w /etc/sysconfig/desktop: DESKTOP="GNOME", ale skoro nie ma gnome to i tak sie on nie wystartuje.

Chciałem tylko się upewnić, bo kiedyś miałem przypadkowy wpis w ~/.dmrc i nie mogłem switchdeskiem zmienić kde na gnome ;-)

Co to znaczy przeinstalować? yum remove org.. i potem wylatuje wszystko zalezne?

rpm -Uvh --replacepkgs --replacefiles nazwa_pakietu

A i tak chyba zrobię reinstalację całego systemu, bo mnie wkurza ten bajzel, który się zrobił.

Zawsze trzeba na poczatku rozwalić system ;-) Tak się można najwięcej nauczyć. Potem już się wie czego nie nalezy robić i jak to potem ewentualnie naprawić.