[RESOLVIDO] XDM (e consequentemente SLiM) não arranca no boot

[raVemjr]

Boas, andava praqui a "brincar" com a minha distro de Gentoo, e agora deixou de bootar para o SLiM, e só boota para o login textual default do Gentoo.

Já meti o DISPLAYMANAGER na conf do XDM, já re-adicionei (tendo apagado primeiro) o XDM do runtime default e continua a arrancar para o login de texto.

Sugestões?

 

[esquiso]

Desculpa, mas o que é que o XDM tem a ver com o SLiM? Um não interefere com o outro, são totalmente independentes (da ultima vez que vi).
Sugestões? Mexeres no /etc/inittab.

 

[raVemjr]

Desculpa, mas o que é que o XDM tem a ver com o SLiM? Um não interefere com o outro, são totalmente independentes (da ultima vez que vi).
Sugestões? Mexeres no /etc/inittab.

No handbook de Gentoo, diziam que para pormos o SLiM a arrancar no início, tinhamos que adicionar o XDM ao run-time default e alterar o /etc/conf.d/xdm colocando lá slim no Display Manager.

Quanto ao inittab... um bocado confuso, a parte relevante seria esta?

# Used by /etc/init.d/xdm to control DM startup.
# Read the comments in /etc/init.d/xdm for more
# info. Do NOT remove, as this will start nothing
# extra at boot if /etc/init.d/xdm is not added
# to the "default" runlevel.
x:a:once:/etc/X11/startDM.sh

Será que este último script precisa de umas alterações? Mas eu nem lhe mexi...

Outra coisa de que eu me lembrei, é possível que um 'emerge -DuN world' tenha causado isto?

 

[neonl]

No handbook de Gentoo, diziam que para pormos o SLiM a arrancar no início, tinhamos que adicionar o XDM ao run-time default e alterar o /etc/conf.d/xdm colocando lá slim no Display Manager.

Quanto ao inittab... um bocado confuso, a parte relevante seria esta?

# Used by /etc/init.d/xdm to control DM startup.
# Read the comments in /etc/init.d/xdm for more
# info. Do NOT remove, as this will start nothing
# extra at boot if /etc/init.d/xdm is not added
# to the "default" runlevel.
x:a:once:/etc/X11/startDM.sh

Será que este último script precisa de umas alterações? Mas eu nem lhe mexi...

Outra coisa de que eu me lembrei, é possível que um 'emerge -DuN world' tenha causado isto?

Calma lá. O que o esquiso disse estava mal (perdoa-se, ele não é user de Gentoo ). Tal como diz no Handbook e nos guias apropriados tens que iniciar o daemon XDM (que lança os Displays Managers gráficos todos) e especificá-lo no /etc/conf.d/xdm .

Esquece, portanto, a parte do inittab. Em relação ao

emerge -uDN world

podes ter quebrado alguns links entre dependências, para despistar essa hipótese, nada como um

revdep-rebuild

Depois posta o /etc/conf.d/xdm inteiro só para ver (caso o comando anterior não dê em nada).

 

[raVemjr]

Calma lá. O que o esquiso disse estava mal (perdoa-se, ele não é user de Gentoo ). Tal como diz no Handbook e nos guias apropriados tens que iniciar o daemon XDM (que lança os Displays Managers gráficos todos) e especificá-lo no /etc/conf.d/xdm .

Exacto, foi esta parte que eu repeti umas 3 vezes, sem resultados. Cheguei até re-emergir o SLiM.

Mais tarde logo tento o revdep. Só uma questão, por vezes quando faço um 'emerge -DuN world' ele no final queixa-se que "foram alteradas X configurações": istyo terá alguma coisa a ver com o problema, ou mesmo este comando?

 

[neonl]

Mais tarde logo tento o revdep. Só uma questão, por vezes quando faço um 'emerge -DuN world' ele no final queixa-se que "foram alteradas X configurações": istyo terá alguma coisa a ver com o problema, ou mesmo este comando?

Pá, supostamente os ficheiros de configuração a actualizar não provocam este problema mas de qualquer maneira, deves actualizá-los:

etc-update

Este passo é complexo e delicado, procura no Google o manual para o fazeres pela primeira vez (se for o caso).

 

[raVemjr]

Bem, o rebuild não fez nada, continua a ir para o login de texto

Cá fica o /etc/conf.d/xdm , supostamente como manda a lei:

# We always try and start X on a static VT. The various DMs normally default
# to using VT7. If you wish to use the xdm init script, then you should ensure
# that the VT checked is the same VT your DM wants to use. We do this check to
# ensure that you have't accidently configured something to run on the VT
# in your /etc/inittab file so that you don't get a dead keyboard.
CHECKVT=7

# What display manager do you use ?  [ xdm | gdm | kdm | kdm-3.5 | kdm-4.0 | entrance ]
# NOTE: If this is set in /etc/rc.conf, that setting will override this one.
# KDE-specific note: kdm-3.5 and kdm-4.0 are just examples. You will find all 
# possible versions by looking at the directories in /usr/kde/.
DISPLAYMANAGER="slim"

...e já agora o /etc/rc.conf , que deveria ser irrelevante neste caso, segundo os comentários a prioridade está no 'xdm':

# /etc/rc.conf: Global startup script configuration settings

# UNICODE specifies whether you want to have UNICODE support in the console.  
# If you set to yes, please make sure to set a UNICODE aware CONSOLEFONT and 
# KEYMAP in the /etc/conf.d/consolefont and /etc/conf.d/keymaps config files.

UNICODE="yes"

# Set EDITOR to your preferred editor.
# You may use something other than what is listed here.

EDITOR="/bin/nano"
#EDITOR="/usr/bin/vim"
#EDITOR="/usr/bin/emacs"

# DISPLAYMANAGER has moved to /etc/conf.d/xdm

# XSESSION is a new variable to control what window manager to start
# default with X if run with xdm, startx or xinit.  The default behavior
# is to look in /etc/X11/Sessions/ and run the script in matching the
# value that XSESSION is set to.  The support scripts are smart enough to
# look in all bin directories if it cant find a match in /etc/X11/Sessions/,
# so setting it to "enlightenment" can also work.  This is basically used
# as a way for the system admin to configure a default system wide WM,
# allthough it will work if the user export XSESSION in his .bash_profile, etc.
#
# NOTE:  1) this behaviour is overridden when a ~/.xinitrc exists, and startx
#           is called.
#        2) even if ~/.xsession exists, if XSESSION can be resolved, it will
#           be executed rather than ~/.xsession, else KDM breaks ...
#
# Defaults depending on what you install currently include:
#
# Gnome - will start gnome-session
# kde-<version> - will start startkde (look in /etc/X11/Sessions/)
# Xfce4 - will start a XFCE4 session
# Xsession - will start a terminal and a few other nice apps

#XSESSION="Gnome"

Mais alguma sugestão?

EDIT: Já agora, aquela sugestão para resolver as configs atrasadas está a dar água pela barba. É esta a razão pela qual tanta gente se queixa de Gentoo queimar tempo? Enfim, 3 das configs que precisam de actualização referem-se ao HAL...estará relacionado?

 

[neonl]

Bem, o rebuild não fez nada, continua a ir para o login de texto

Cá fica o /etc/conf.d/xdm , supostamente como manda a lei:

# We always try and start X on a static VT. The various DMs normally default
# to using VT7. If you wish to use the xdm init script, then you should ensure
# that the VT checked is the same VT your DM wants to use. We do this check to
# ensure that you have't accidently configured something to run on the VT
# in your /etc/inittab file so that you don't get a dead keyboard.
CHECKVT=7

# What display manager do you use ?  [ xdm | gdm | kdm | kdm-3.5 | kdm-4.0 | entrance ]
# NOTE: If this is set in /etc/rc.conf, that setting will override this one.
# KDE-specific note: kdm-3.5 and kdm-4.0 are just examples. You will find all 
# possible versions by looking at the directories in /usr/kde/.
DISPLAYMANAGER="slim"

...e já agora o /etc/rc.conf , que deveria ser irrelevante neste caso, segundo os comentários a prioridade está no 'xdm':

# /etc/rc.conf: Global startup script configuration settings

# UNICODE specifies whether you want to have UNICODE support in the console.  
# If you set to yes, please make sure to set a UNICODE aware CONSOLEFONT and 
# KEYMAP in the /etc/conf.d/consolefont and /etc/conf.d/keymaps config files.

UNICODE="yes"

# Set EDITOR to your preferred editor.
# You may use something other than what is listed here.

EDITOR="/bin/nano"
#EDITOR="/usr/bin/vim"
#EDITOR="/usr/bin/emacs"

# DISPLAYMANAGER has moved to /etc/conf.d/xdm

# XSESSION is a new variable to control what window manager to start
# default with X if run with xdm, startx or xinit.  The default behavior
# is to look in /etc/X11/Sessions/ and run the script in matching the
# value that XSESSION is set to.  The support scripts are smart enough to
# look in all bin directories if it cant find a match in /etc/X11/Sessions/,
# so setting it to "enlightenment" can also work.  This is basically used
# as a way for the system admin to configure a default system wide WM,
# allthough it will work if the user export XSESSION in his .bash_profile, etc.
#
# NOTE:  1) this behaviour is overridden when a ~/.xinitrc exists, and startx
#           is called.
#        2) even if ~/.xsession exists, if XSESSION can be resolved, it will
#           be executed rather than ~/.xsession, else KDM breaks ...
#
# Defaults depending on what you install currently include:
#
# Gnome - will start gnome-session
# kde-<version> - will start startkde (look in /etc/X11/Sessions/)
# Xfce4 - will start a XFCE4 session
# Xsession - will start a terminal and a few other nice apps

#XSESSION="Gnome"

Mais alguma sugestão?

Aparentemente isso está tudo normal. Já não sei que mais sugestões hei-de dar... Se há algo aí a gerar um conflito...

Só uma coisa, mostra o ~/.xinitrc (embora não tenha directamente a ver).

EDIT: Já agora, aquela sugestão para resolver as configs atrasadas está a dar água pela barba. É esta a razão pela qual tanta gente se queixa de Gentoo queimar tempo? Enfim, 3 das configs que precisam de actualização referem-se ao HAL...estará relacionado?

Eu avisei que a actualização dos ficheiros de configuração não era propriamente uma coisa 'fácil'. Vais demorar um pouco a atinar. Dá uma vista de olhos por

man etc-update

Acho que te vai ajudar. Seja como for, não creio que esteja relacionado.

 

[raVemjr]

Só uma coisa, mostra o ~/.xinitrc (embora não tenha directamente a ver).

O meu .xinitrc tem simplesmente 'exec fluxbox', já li em sítios que deveria estar startfluxbox por uma razão ou outra, mas acho que problemas ali começam depois do SLiM começar, não?

Eu avisei que a actualização dos ficheiros de configuração não era propriamente uma coisa 'fácil'. Vais demorar um pouco a atinar.

Felizmente não houve muito que atinar, os 3 ficheiros eram iguais, só umas linhas trocavam de posição, e os dois restantes eram ficheiros Gnome Sounds, por isso nem liguei muito, dado usar fluxbox (espero não me arrepender quando vier a usar uma app GTK )

 

[neonl]

O meu .xinitrc tem simplesmente 'exec fluxbox', já li em sítios que deveria estar startfluxbox por uma razão ou outra, mas acho que problemas ali começam depois do SLiM começar, não?

Pois... Supostamente. Eu estou a acabar neste momento os backups para fazer uma nova instalação de Gentoo (passar de i686 para 64-bits e re-particionar o disco todo). No fim, vou instalar o SLiM (também uso Fluxbox) e ver o que é que dá.

Seja como for, o .xinitrc tem que conter 'exec startfluxbox' e não 'fluxbox' .

Felizmente não houve muito que atinar, os 3 ficheiros eram iguais, só umas linhas trocavam de posição, e os dois restantes eram ficheiros Gnome Sounds, por isso nem liguei muito, dado usar fluxbox (espero não me arrepender quando vier a usar uma app GTK )

GNOME e GTK estão separados no que toca a configuração.

 

[raVemjr]

Pois... Supostamente. Eu estou a acabar neste momento os backups para fazer uma nova instalação de Gentoo (passar de i686 para 64-bits e re-particionar o disco todo). No fim, vou instalar o SLiM (também uso Fluxbox) e ver o que é que dá.

Seja como for, o .xinitrc tem que conter 'exec startfluxbox' e não 'fluxbox' .

O estranho disto tudo é que passou a não dar, depois de já ter dado. Não sei precisar o que é que aconteceu para despoletar isto tudo, dado que fiz imensa coisa (uma delas foi tentar por o touchpad a funcionar, que mesmo assim ainda não tem o drag na parte direita)

Já agora, não bastava só mudares de Kernel que ficava tudo bem? Ou os binários não funcionam depois?

EDIT: Lembrei-me agora, fiz um auto-config ao X11, será que re-escreveu alguma coisa que não devia?

 

[neonl]

Já agora, não bastava só mudares de Kernel que ficava tudo bem? Ou os binários não funcionam depois?

Desculpa, mas não percebo a pergunta. Tem a ver com o SLiM?

 

[raVemjr]

Desculpa, mas não percebo a pergunta. Tem a ver com o SLiM?

Não, tem a ver com o teu update para x64. Pensava que um update para 64bit passava somente pelo kernel, mas já percebi que não, se assim fosse não haveriam tantas queixas em relação aos drivers

Entretanto já resolvi o problema, e a minha suspeita estava certa, quebrei isto quando configurei o Xorg para funcionar com o touchpad e meter scroll. Se tivesse lido o log teria evitado esta confusão toda. Lesson learned

 

[neonl]

Não, tem a ver com o teu update para x64. Pensava que um update para 64bit passava somente pelo kernel, mas já percebi que não, se assim fosse não haveriam tantas queixas em relação aos drivers

Entretanto já resolvi o problema, e a minha suspeita estava certa, quebrei isto quando configurei o Xorg para funcionar com o touchpad e meter scroll. Se tivesse lido o log teria evitado esta confusão toda. Lesson learned

Foi (quase) tão erro teu como meu . Tu falaste numa coisa que necessariamente intervinha no xorg.conf e eu deixei escapar essa indicação. Therefore, lesson learned for both of us!

Cumprimentos.

 

[raVemjr]

Teve ainda o bónus do scroll ter comecado a funcionar (na declaração lá em cima tinha Mouse1, e em baixo na declarcao 'InputDevice' tinha 'TouchPad'...é o que dá copy paste da net)

Enfim, obrigado pela ajuda de qualquer das formas. Acabei por aprender a tratar dos config files (usei o dispatch-conf, pois deixa backups) que também é bastante importante...