[Gentoo] kdm start niet na't booten

[sebas]

Na het booten geeft gentoo's init aan, dat kdm gestart wordt, maar dat is niet het geval. rc-status geeft het als gestart aan, maar er gebeurt niets. Als ik als root inlog en daarna 'kdm' intik, start-ie wel gewoon.

Ik heb in rc.conf o.a. de volgende instellingen:

code:

DISPLAYMANAGER="kdm"
XSESSION="kde-3.3.2"

In /etc/X11/Sessions/ is een entry genaamd kde-3.3.2.

Zoals in deze howto gesuggereerd, heb ik xdm aan mijn default runlevel toegevoegd.

Heeft iemand nog suggesties wat ik kan checken, dat het wel goedgaat? Ik zelf vind het geen probleem om na't booten ff op de console in te loggen, maar mijn vriendin gebruikt deze computer ook redelijk vaak, en ik wil haar Linux experience niet aantasten door dit soort dingen, vooral niet aangezien het triviaal te fixen lijkt. Eigenlijk. Daarnaast vergeet je op deze manier makkelijk een kant-en-klaar ingelogde rootshell, wat mij ook nog dwarszit.

[_Squatt_]

Je kunt /var/log/kdm.log eens bekijken, misschien staat daar wat informatie in over waarom kdm ermee stopt.

Wat als je '/etc/init.d/xdm restart' doet?

/etc/init.d/xdm doet niet veel meer dan de juiste executable kiezen, en dan 'telinit a' runnen. Heb je /etc/inittab veranderd? Of preciezer, staat de volgende regel daar nog steeds in:

code:

x:a:once:/etc/X11/startDM.sh

[sebas]

Deze regel staat erin, ik heb ook niets aan de runlevels veranderd. kdm.log zegt niets, dus ik heem aan dat het hele gedoe helemaal geen kdm start. In /etc/X11/kde-3.3.2 staat een verwijzing naar startkde. startkde heeft echter niet direct met kdm te maken (kdm staat niet eens in dat script genoemd ...).

Hoe de Gentoo mensen dit verzonnen hebben weet ik niet.

\edit:

Ik heb even in /etc/X11/Sessions/kde-3.3.2 in plaats van startkde kdm gezet, maar ook die voert niets uit.

[ Voor 16% gewijzigd door sebas op 21-12-2004 20:14 ]

[smokalot]

/etc/X11/kde-3.3.2 is om een KDE-sessie te starten, en dat heeft in zoverre met kdm te maken dat kdm dit script voor je kan uitvoeren als je inlogt.

Op mijn wat trage laptop heb ik hetzelfde probleem, maar omdat ie zo traag is heb ik de tijd in te loggen en ps ax uit te voeren, waarna ik meestal twee processen zie van kdm, kdm en kdm_config meen ik, en soms zie ik daarna ook X staan, met -nolisten tcp en alle andere opties. Soms wordt X dus gestart, en soms niet, waarna kdm gewoon afsluit. er is dan ook geen kdm-log.

oh, ik zie nu dat jij altijd last hebt van dit probleem, en ik maar soms, maar misschien heeft het toch een vergelijkbare oorzaak...

oplossing lijkt me om ergens debugmeldingen te genereren. stdout en stderr redirecten in scriptjes enzo...

[Kees]

Welk runlevel staat er in je inittab?
wat roept 'rc-update add kdm default'?

[sebas]

Ik heb zoiets al geprobeerd (het probleem had al vaker mijn aandacht getrokken, nooit met een oplossing als gevolg), maar ik kwam niet echt ver. Maar blijkbaar ben ik niet de enige die er last van heeft....

[sebas]

Kees schreef op dinsdag 21 december 2004 @ 20:21:
Welk runlevel staat er in je inittab?
wat roept 'rc-update add kdm default'?

Ik kan kdm toevoegen, rc-update gaat er verder niet om zeuren. Zoals ik uit de documentatie begrijp is het de bedoeling om xdm te starten, en in rc.conf aan te geven dat je kdm wilt. Dat heb ik ook. kdm zelf aan de runlevel heeft hetzelfde effect. xdm roept bij't draaien ook dat kdm gestart wordt. Ik boot default (3) normaal gesproken. Ik zie ook langskomen dat kdm gestart wordt (zegt-ie tenminste), maar hij gaat vervolgens niet chvt'en en kdm komt ook niet in mijn top te staan. VT7 blijft leeg.

[ Voor 3% gewijzigd door sebas op 21-12-2004 20:28 ]

[Pyrowired]

En heb je al eens geprobeerd om je default runlevel naar 5 te zetten?
Dat is nl de standaard runlevel voor grafische weergave.

[Verwijderd]

Volgens mij moet je in /etc/profile.env de regel
MY_XDM="kde" toevoegen.

[sebas]

Pyrowired schreef op woensdag 22 december 2004 @ 07:33:
En heb je al eens geprobeerd om je default runlevel naar 5 te zetten?
Dat is nl de standaard runlevel voor grafische weergave.

In Gentoo zijn de nummers anders verdeeld, level 3 en 5 (en 4) zijn allemaal 'default' dus hetzelfde (als ik me niet helemaal vergis tenminste), dus dat zal weinig effect hebben, helaas. (Ik heb het uiteraard nog even getest, geen verschil.)

Ook MY_XDM="kde" heeft niet het beoogde effect.

[ Voor 13% gewijzigd door sebas op 22-12-2004 12:46 ]

[Roel]

ik heb ik mijn rc.conf

code:

XSESSION=""

staan.

Geen idee of dat wat uitmaakt, maar het heeft als voordeel dat je bij kdm kunt kiezen welke sessie je gebruikt. Ook makkelijk bij een upgrade van kde, hoef je je rc.conf niet meer aan te passen..

[laurencevde]

je kan natuurlijk ook in inittab die regel van squatt in kdm kunnen veranderen
het hoort misschien niet, maar werkt wel, en dan heb je ook meteen geen last meer van die gare onduidelijke scripts

code:

x:a:once:kdm

[ Voor 5% gewijzigd door laurencevde op 22-12-2004 13:07 ]

[blouweKip]

Ik heb het idee dat je niet de enige bent met het probleem:

http://forums.gentoo.org/viewtopic.php?t=221942
http://bugs.gentoo.org/show_bug.cgi?id=66011

om te testen of t nu aan kdm ligt kun je misschien ook nog even testen of xdm of een andere login manager wel opstart

[sebas]

Ik ben eerlijk gezegd na de laatste updates Gentoo behoorlijk beu, ik ga het wel proberen om te fixen als ik er weer wat meer vertrouwen in heb, voor mij zijn de afgelopen tijd gewoon teveel dingen kapot gegaan, hier enkele voorbeelden:
- een tijdje geleden was tar broken, het systeem bootte niet meer omdat tar nodig is om de udev devices uit te pakken
- vixie-cron heeft sinds twee weken kuren, hij start wel, maar returned daarna niet meer, ik moet dus met Control+C onderbreken voordat die verder gaat
- De laatste update van enkele udev scripts (gok ik) hebben als enig tot nu toe merkbaar effect dat ik onder Xorg geen muis meer ter beschikking heb
- kdbrate is sinds de laatste update kapoet, dat wil zeggen het heeft totaal geen effect, werken op de console is hiermee zwaar irritant, omdat je heeeeeeeeeel vvvvvvaaaaaaaaaakkkkk lettterrrss te vaak indrukt, de kdbrate veranderen heeft geen effect (niet met kdbrate althans)

Het klinkt misschien een beetje suf, maar ik heb weinig zin om hier verder nog veel tijd in te steken. Gelukkig had ik nog een Debian sid installatie op de disk, die heb ik nu als default ingesteld in grub en ik heb dus een werkend systeem. Helaas is mijn vertrouwen in Gentoo (en de updates) nu behoorlijk zoek. Alleen al het aan de praat krijgen van kdm (doodsimpel zou je zeggen) heeft me onderhand al meerdere uren gekost, plus dat op mijn systeem een update van KDE wel eens 40 uur kan duren (niet alleen kdebase uiteraard), en ja, dat vind ik te lang. Ik heb het idee gekregen dat Gentoo wel leuk in elkaar zit, maar dat het simpelweg nog niet rijp is, althans niet als je de keurigheid, volledigheid en goed geteste Debian packages (zelfs die uit sid) gewend bent.

[DeMoN]

sebas schreef op woensdag 22 december 2004 @ 14:10:
--blaat gentoo teh sux0r--

Ik wil eigenlijk even mededelen dat ik dit topic al een tijdje lees, omdat ik hetzelfde probleem heb.
Alleen dan met gdm en met Debian.
Nu boeit mij het niet zo want ik heb niet echt veel behoefte aan een login manager, maar is het bij jou ook zo dat als je systeem boot (helemaal compleet met X en KDE) en je CTRL+ALT+BACKSPACE drukte X werd gekilled en vervolgens wel kdm (re)startte en zich liet zien?

gdm start dus bij de boot, maar wordt niet gebruikt bij mij. X start gewoon op en als ik die kill en hij vanzelf X weer wilt starten start hij eerst gdm....

Ben benieuwd of dit dus bij jou ook zo is het en het helemaal niet zo distro specifiek is.

[ Voor 19% gewijzigd door DeMoN op 22-12-2004 15:05 ]

[sebas]

Heb je geprobeerd om met

code:

dpkg-reconfigure gdm

gdm als standaard in te stellen? Werkt dit met kdm bijvoorbeeld wel?

Bij mij is het zo (onder Debian) dat het systeem boot, kdm opstart, ik inlog, en als ik d.m.v. Control+Alt+Backspace X kill, dat dan kdm weer terugkomt (kdm zorgt er dus voor, dat X opnieuw opgestart wordt na de kill). Werkt bij jou

code:

/etc/init.d/gdm start

trouwens wel goed?

[DeMoN]

sebas schreef op woensdag 22 december 2004 @ 15:22:
Heb je geprobeerd om met

code:

dpkg-reconfigure gdm

gdm als standaard in te stellen? Werkt dit met kdm bijvoorbeeld wel?

Bij mij is het zo (onder Debian) dat het systeem boot, kdm opstart, ik inlog, en als ik d.m.v. Control+Alt+Backspace X kill, dat dan kdm weer terugkomt (kdm zorgt er dus voor, dat X opnieuw opgestart wordt na de kill). Werkt bij jou

code:

/etc/init.d/gdm start

trouwens wel goed?

Nee ik heb er verder nog niet aan geknutseld.. ik denk dat dit wel zal werken en die gdm service opnieuw starten werkt zeker weten
Ik vroeg me alleen af of we misschien wel precies hetzelfde probleem hadden, alleen jij dan met Gentoo

[sebas]

Nee, volgens mij niet. Immers zitten beide systemen wat dat betreft anders in elkaar. (Debian gebruikt dpkg-reconfigure en volgens mij symlinks in /etc/alternatives, in Gentoo stel je de loginmanager via ENV vars in. Kijk maar ff naar die twee dingen die ik boven suggereerde, mocht dat niet helpen, laat het even weten. Ik heb ermee onder Debian nooit problemen gehad en kan je er vastwel mee helpen.

[Verwijderd]

Met slackware10 ook ruzie gehad. Initlevel huppeldepup moet automatisch "gdm" starten... Zal wel, gewoon het commando "gdm" in "etc/rc.d/rc.local" toevoegen doet wonderen.

[smokalot]

zou dit niet een kdm probleem zijn, en niet perse gentoo? verder kun je natuurlijk alleen x86 als ACCEPT_KEYWORDS gebruiken, en niet ~x86, zodat in principe alleen stable pakketten ge-emerged worden. Als je bij een bepaald pakket wel ~x86 wilt gebruiken kun je dat in /etc/portage/package.keywords aangeven.

Dat continue updaten is misschien voor de meeste gebruikers ook niet echt zinvol, een optie om alleen kritieke updates uit te voeren lijkt me best nuttig eigenlijk. Zoiets kun je dan ook via cron laten doen, emerge sync && emerge world durf ik nu nog niet automatisch te laten verlopen...

[DiNo!]

blouweKip schreef op woensdag 22 december 2004 @ 13:11:
Ik heb het idee dat je niet de enige bent met het probleem:

http://forums.gentoo.org/viewtopic.php?t=221942
http://bugs.gentoo.org/show_bug.cgi?id=66011

om te testen of t nu aan kdm ligt kun je misschien ook nog even testen of xdm of een andere login manager wel opstart

Ok, ik heb dit probleem ook sinds kort (,sinds de installatie van gentoo). Ik heb een diskless wireless gentoo pc die van een NFS share boot die het ook vertikt om kdm te starten. (startx werkt wel prima.)
Het probleem is volgens het gentoo forum dat /dev/random niet gevuld word, kdm heeft dat nodig en start niet op als er geen /dev/random gegevens zijn (maw... het wacht net zolang tot die er wel zijn). De oplossing is om de kernel wat random dingen te geven zoals het bewegen van je muis of het aanslaan van je toetsenbord. Het hercompileren van kde (dus niet....) word voorgesteld als oplossing. De truuk is dan om kdm /dev/urandom te laten gebruiken.

Een makkelijke oplossing is er ook: emerge rng-tools. rc-update add rngd boot
Dit is een deamon die (bij gebrek aan een hardware random number generator) de /dev/urandom gebruikt om /dev/random te vullen. Prima oplossing bij gebrek aan beter. Dit werkt dan ook gelijk voor alle andere programma's die /dev/random gebruiken.

[Elijan9]

Ik had hetzelfde met Slackware, bij mij kwam het doordat ik tmpfs gebruik op /tmp. Als je dat ook doet, dan kan dit je helpen, anders dus niet...
Maar voor mij was de oplossing om elke keer bij het opstarten na deze mount op /tmp, de directories /tmp/.X11-unix en /tmp/.ICE-unix opnieuw aan te maken (als root).

[Ryceck]

Ik heb hetzelfde probleem gehad toen ik een 2.6.8.1 kernel draaide.
Ik heb toen mijn kernel geupgrade naar een 2.6.9 en mijn probleem was verdwenen.
Als je voortaan ook s zoekt op http://forums.gentoo.org dan kan je deze oplossing daar een keer of tien terug vinden
Beter het probleem bij de source zoeken (gentoo) dan bij een 2e-rangs partij die er af en toe wat mee doet (GoT, nofi), dan komt je oplossing een stuk sneller en efficienter.
Als je btw @ de forums niet kan vinden...: http://bugs.gentoo.org en daar zoeken op "ALL kdm" vind je jouw probleem ook terug

[DiNo!]

Ryceck schreef op zaterdag 25 december 2004 @ 11:26:
Ik heb hetzelfde probleem gehad toen ik een 2.6.8.1 kernel draaide.
Ik heb toen mijn kernel geupgrade naar een 2.6.9 en mijn probleem was verdwenen.
Als je voortaan ook s zoekt op http://forums.gentoo.org dan kan je deze oplossing daar een keer of tien terug vinden
Beter het probleem bij de source zoeken (gentoo) dan bij een 2e-rangs partij die er af en toe wat mee doet (GoT, nofi), dan komt je oplossing een stuk sneller en efficienter.
Als je btw @ de forums niet kan vinden...: http://bugs.gentoo.org en daar zoeken op "ALL kdm" vind je jouw probleem ook terug

Mijn diskless pc was vers geinstalleerd met 2.6.9 en die deed het dus niet. Op het gentoo forum zitten heel veel mensen die veel roepen.... iedereen denkt de oplossing te hebben maar geen van alles werkt bij iedereen. Dat jij succes had met de upgrade naaar 2.6.9 betekend dat er iets veranderd is waardoor bij jouw wel de RNG entropy weer aangevuld werd. Wellicht door een driver van een pci kaart of je harde schijf. In mijn geval heb ik geen harde schrijf en ik gebruikte voor mijn wireless kaart de ndiswrapper. Geen van alles genereerde random gedrag. De drivers van je hardeschijf en sommige andere netwerk driver zetten de flag SA_SAMPLE_RANDOM. Dit betekend dat ze bij mogen dragen aan het generen van random numbers.

Sommige mensen gebruiken tmpfs voor /tmp. Dit werkt niet denkt iemand en dus gaan ze terug naar een /tmp op de harde schijf. Wat je dus eigenlijk doet is dus de hard schijf weer gebruiken voor dingen..... die genereerd dus dan weer meer random numbers en dus is onterecht de schuld gegeven aan tmpfs (die dus niet bijdraagt aan de random numbers).

Andere beweren dus weer dat als je de coldplug/hotplug pakketjes toevoegd aan je gentoo dat je probleem vaak (dus niet altijd) over is.... maar wat doe je met die pakketjes? Je laat USB en je harde schijf meer interrupts generen die weer bijdragen aan het generen van de random numbers.

Weer bij anderen help het intikken van een username direct bij het verschijnen van de console inlog. Die generen dus weer interrupts door het intikken van een naam. Dit draagt weer bij aan het generen van random numbers. Als die niks intikken dan krijg je geen kdm inlogscherm.

Weer anderen beweren dat het bewegen van de muis tijdelijk opluchting geeft.... maar wat doe je eigenlijk? Je genereerd interrupts die weer.... jeweetwel...

Maargoed. Het probleem van iedereen was dus dat er iets aan de hand was waardoor er geen of weinig interrupts waren of dat de bewuste interrupts die er wel zijn niet bijdragen aan het genereren van random numbers zoals bij mijn diskless pc met een netwerkkaart die niks bijdraagt.

Oplossing is dus om een of andere mannier ervoor te zorgen dat er wel random number gegenereerd worden. Bij mij door een stukje software, bij jouw door een kernel upgrade (lees: driver verandering) of door de harde schijf harder te laten werken (geen tmpfs) of door meer interrupts te generen met je keyboard of door je muis te bewegen.