tty7 wordt standaard niet meer meegestart

[Verwijderd]

hallo allemaal,

ik heb hier een zeer vreemd probleem, tenminste ik heb het nog nooit meegemaakt, en ik hoop dat jullie me ermee kunnen helpen.

ik heb hier een installatie van LTPS 4.2 draaien ( Fedora Core 6 (Zod) ) en dat werkte allemaal goed, tot op een gegeven moment X het niet meer deed.
dus ik als echte windowsgebruiker een reboot geven in de hoop dat het allemaal weer ging werken, maar helaas.

ik op zoek op GOT en Google naar een antwoord op mijn probleem, kijken of andere mensen dat zelfde probleem ook hadden, maar niet echt veel bruikbaars kunnen vinden.

de volgende dingen heb ik ondekt:
- als de server start dan heb ik tty1 t/m 6. tty7 t/m tty12 zijn niet actief
- wanneer ik dan startx doe (ingelogd als root) loopt de server vast, reageert ook niet meer op CAPS-lock
- wanneer ik eerst xdm start vanaf een console (tty1) worden tty7 en tty8 geactiveerd en xdm draait op tty7
- als ik daarna zeg: "startx -- :8" dan start hij X wel gewoon

ik denk dus dat het ergens in de boot zit, waar die hogere tty's niet gestart worden, alleen kan ik niet vinden waar. ik heb al alle conf bestanden bekeken van grub en ltsp enzo, maar daar staat niks in.

ps.
deze info is misschien niet zo heel interessant omdat dit pas na de start van X gebeurd, maar nadat ik dus X heb kunnen starten na XDM en kijk ik op tty1 voor de output van X en zie daar staan "(EE) AIGLX: screen0 is not dri capable " en " ** eggcups:3345 WARNING ** IPP request failed with status 1030 ".

Misschien dat iemand van jullie dit bekend voorkomt?
de server start trouwens standaard in multi-user mode (text)

groeten daan

[thunder7]

Allereerst is natuurlijk de vraag wat je deed voordat het stopte met werken (een update, wellicht?).

Wat op welke tty gestart wordt, wordt meestal geregeld in /etc/inittab. Wanneer is die file voor het laatste gewijzigd? Staan er vreemde dingen in?

[GX]

In ieder geval gebruik je AIGLX in je xorg (zal wel een FC6-trekje zijn), probeer die dus eens uit te schakelen, misschien dat dan X in ieder geval weer wel werkt. Waarom tty8 en hoger kwijt zijn is ook mij echter een volkomen raadsel;

[moto-moi]

X wil juist niet gestart worden op een tty waar al iets op actief is, vandaar dat je meestal op tty7 of 8 uitkomt
De foutmelding die je krijgt over dri-capabilty lijkt me een veel logischere route om uit te gaan zoeken dan je tty's, die kloppen in 99% van de gevallen wel

[Verwijderd]

thunder7 schreef op woensdag 28 maart 2007 @ 17:02:
Allereerst is natuurlijk de vraag wat je deed voordat het stopte met werken (een update, wellicht?).

Wat op welke tty gestart wordt, wordt meestal geregeld in /etc/inittab. Wanneer is die file voor het laatste gewijzigd? Staan er vreemde dingen in?

volgens mij waren er na de laatste update geen problemen (yum update).
ik heb wel laatst wine geinstalleerd, maar dat mag toch niet je boot aanpassen?

in de /etc/inittab worden tty1 t/m tty6 gestart, ik zal ff in file posten:

code:

# Default runlevel. The runlevels used by RHS are:
#   0 - halt (Do NOT set initdefault to this)
#   1 - Single user mode
#   2 - Multiuser, without NFS (The same as 3, if you do not have networking)
#   3 - Full multiuser mode
#   4 - unused
#   5 - X11
#   6 - reboot (Do NOT set initdefault to this)
# 
id:3:initdefault:

# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit

l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6

# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now

# When our UPS tells us power has failed, assume we have a few minutes
# of power left.  Schedule a shutdown for 2 minutes from now.
# This does, of course, assume you have powerd installed and your
# UPS connected and working correctly.  
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"

# If power was restored before the shutdown kicked in, cancel it.
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"


# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6

# Run xdm in runlevel 5
x:5:once:/etc/X11/prefdm -nodaemon

[Verwijderd]

moto-moi schreef op woensdag 28 maart 2007 @ 18:32:
X wil juist niet gestart worden op een tty waar al iets op actief is, vandaar dat je meestal op tty7 of 8 uitkomt
De foutmelding die je krijgt over dri-capabilty lijkt me een veel logischere route om uit te gaan zoeken dan je tty's, die kloppen in 99% van de gevallen wel

ik dacht eigenlijk dat bij een standaard installatie, altijd tty1 t/m tty6 werden geladen als shell en tty7 ook, maar die is dan gewoon zwart, tot je in een shell startx command geeft. dat was volgens mij ook het geval hier voor dat ik dit probleem had.
maar ik ga wel ff kijken wat ik over dat dri capable kan vinden, alhoewel het toch vreemd blijft dat xdm wel een sessie kan starten en tty7 en tty8 vrij geeft

[Verwijderd]

GX schreef op woensdag 28 maart 2007 @ 18:30:
In ieder geval gebruik je AIGLX in je xorg (zal wel een FC6-trekje zijn), probeer die dus eens uit te schakelen, misschien dat dan X in ieder geval weer wel werkt. Waarom tty8 en hoger kwijt zijn is ook mij echter een volkomen raadsel;

Ik heb AIGLX en compositing uitgeschakeld zoals beschreven in de FC rendering wiki:
add in /etc/X11/xorg.conf

code:

Section "ServerFlags"
        Option  "AIGLX" "off"
EndSection

Section "Extensions"
        Option "Composite" "Disable"
EndSection

ff de pc opnieuw gestart en hij deed het weer.
als ik nu opstart en het startx commando geef, opent hij in tty7 en tty8 wordt netjes zwart. er zal dus wel een foutje ergens zitten in die AIGLX.
ik zie bij de output nog wel staan " ** eggcups:3345 WARNING ** IPP request failed with status 1030 " ik weet niet of dit kwaad kan?? denk ut eigenlijk niet.

iig bedankt voor de reacties

[it0]

Die laatse melding is dat er iets niet met printing werkt, misschien netwerk print spooler of printer niet bereikbaar.

[Verwijderd]

misschien ook wel even leuk om te melden. Nu werken xdm en startx wel, maar wanneer ik kdm start als eerste grafische omgeving loopt hij wel weer vast.
ik denk zelf dat het iets te maken heeft met dat ik in init 3 boot en xdmcp dan nog niet gestart is ofzo. hoewel dat wel weer raar is omdat xdm het wel doet.

als ik namelijk na inloggen op tty1 zeg "inittel 5" en dan zeg "kdm", dan wordt netjes kdm gestart op tty7

misschien heeft iemand een idee wat dit kan zijn?

PS. gdm doet het wel gewoon onder init3 en als ik daarna kdm start werk het wel

[Verwijderd]

Het probleem met KDM is ook opgelost

Na het starten van kdm in runlevel 3 liep heel de pc vast, reageerde nergens meer op. Dit bleek te komen door de firewall, dus ik iptables uitgeschakeld en draaien maar.

Daarna in inittab het runlevel omgezet naar 5 en de laatste regel aangepast naar:

code:

x:5:once:/usr/bin/kdm

reboot, weer vast

laatste regel in inittab weer aangepast, nu naar:

code:

x:5:respawn:/usr/bin/kdm

en alles draait nu normaal als ik me pc aan zet