Yesterday I upgraded to x11-base/xorg-server-1.9.2 and I merged the /etc/init.d/xdm script erasing the older one and using the new proposed script. After rebooting the system, the xdm script starts and so suddenly does kdm, but, after 2 seconds it comes back to tty1 to let me see other /etc/init.d scripts to start. Then I'm forced to manually switch to tty7 to log in kdm. Reproducible: Always Steps to Reproduce: 1. Upgrade x11-base/xorg-server to 1.9.2 version 2. use the new /etc/init.d/xdm script overwriting the older one 3. reboot the system. Actual Results: After the boot I see kdm for few seconds and suddenly I see again tty1 where other /etc/init.d scripts continue to start. To use kdm I have to manually switch to tty7. Expected Results: I should not automatically go back to tty1 after starting kdm. My system is in the stable amd64 branch. There's an easy workaround: in /etc/init.d/xdm script, in the depend() function I added a line "after *".
Created attachment 257947 [details] emerge --info
Please paste the list of init scripts used by you too, e.g. the output of: $ rc-update show
Normally it is not a problem to start xdm before other init scripts. Only if one of those init scripts causes a vtswitch you will see the described behaviour. To isolate the issue, try the following: Note which init scripts are started after xdm, then restart them one by one until you find the culprit.
Created attachment 258022 [details] rc-update --show Output of the command rc-update--show
Comment on attachment 258022 [details] rc-update --show I've done a mistake this is not the right file!
Created attachment 258023 [details] rc-update --show output I'm sorry, this is the right output of the rc-update --shpw command. I also tried to restart every init script that starts after xdm manually, but no one of them caused a VTswitch! The init scripts that start after xdm are (in order): dcron, dbus, consolekit, hald,laptop_mode, mysql, ntpd, wicd, local, vboxdrv.
(In reply to comment #6) > I also tried to restart every init script that starts after xdm manually, but > no one of them caused a VTswitch! Do you have parallel boot enabled? If you do, it might be possible that rc displays the particular init script before xdm while its execution continues later. > The init scripts that start after xdm are (in order): dcron, dbus, consolekit, > hald,laptop_mode, mysql, ntpd, wicd, local, vboxdrv. Do you have any custom commands for the local script? Could you attach them?
Created attachment 258034 [details] rc configuration This is the /etc/conf.d/rc file: parallel startup is not enabled. My /etc/conf.d/local.start is empty.
Ok, the first candidate would be vboxdrv which AFAICS isn't even a standard Gentoo init.d script. Please try the following: $ modprobe -r vboxdrv vboxnetflt and then restart that service.
(In reply to comment #9) > > Please try the following: > $ modprobe -r vboxdrv vboxnetflt > and then restart that service. > Again there is no VTswitch. Obviusly my tests are done in tty1 writing # sleep 7 && /etc/init.d/XXX restart switching to X and waiting to see if there is some VTswitch. Is it right? Thank you so much for your attention!
You may be able to use the depend function to identify the init script which causes the vtswitch.
(In reply to comment #11) > You may be able to use the depend function to identify the init script which > causes the vtswitch. Yeah, bisecting through adding these scripts one by one to the 'after' command should give us the answer. It's going to take some time though.
(In reply to comment #12) > (In reply to comment #11) > > You may be able to use the depend function to identify the init script which > > causes the vtswitch. > > Yeah, bisecting through adding these scripts one by one to the 'after' command > should give us the answer. It's going to take some time though. > You both were right. In the depend() function in the init.d/xdm script I changed at every boot the line after XXX and I found that what cause the vtswitch was WICD! with "after wicd" in the depend() function of xdm, everything goes fine! I will attach init.d/xdm and init.d/wicd scripts.
Created attachment 258106 [details] /etc/init.d/xdm script
Created attachment 258107 [details] /etc/init.d/wicd script
(In reply to comment #13) > You both were right. > In the depend() function in the init.d/xdm script I changed at every boot the > line after XXX and I found that what cause the vtswitch was WICD! > with "after wicd" in the depend() function of xdm, everything goes fine! > I will attach init.d/xdm and init.d/wicd scripts. That looks a little strange. Are you sure that this isn't something else depending on network set up (i.e. wicd + something else)?
(In reply to comment #16) > > That looks a little strange. Are you sure that this isn't something else > depending on network set up (i.e. wicd + something else)? > No, I'm sure! You can read my init scripts of wicd and xdm. All the subdirectories of /etc/wicd/scripts are empty!
wicd maintainers, could you take a look at this one?
(In reply to comment #18) > wicd maintainers, could you take a look at this one? I took over maintainership only a week ago, but looking at this I have no idea how wicd could switch VT, also I have never seen this bug on any of my machines that use wicd and xdm. Adding darkside as he has maintained wicd for long time.
Good morning and happy new year. I'm sorry for your waste of time. But after a new fresh install everything seems fine now. Surely it was my fault on changing something in a wrong way in the wicd script. I hope you can excuse me. Bye.
(In reply to comment #20) > Good morning and happy new year. > I'm sorry for your waste of time. > But after a new fresh install everything seems fine now. > Surely it was my fault on changing something in a wrong way in the wicd script. > I hope you can excuse me. That's OK. Thanks for the info.
