Not sure why X is still starting on vt7, even after an upgrade to Fedora 10. I tried nomodeset, removing the xorg.conf file altogether, using the nv driver, using the nvidia binary driver and using the xorg.conf generated by the NVIDIA config tool. Nothing seems to work. I'm not sure where to configure gdm and/or Xorg to make this work right. At boot, vt1 shows all the output messages until gdm starts X on vt7. vt1 remains unusable even though X is on vt7. Then, at shutdown, all output messages are shown on vt7. If I switch to runlevel 3, vt1 becomes available for login again. What gives?
If you go to runlevel 3 and then log in to a tty and run X :123 vt1 does it bring up X on vt1 ?
Yes, it brings up X (just the crosshatch background) on vt1. I checked another machine where the upgrade went smoothly and X migrated from vt7 to vt1 successfully - [Machine stuck on vt7] /usr/bin/Xorg :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-Oa3kKk/database -nolisten tcp [Machine moved to vt1] /usr/bin/Xorg :0 -nr -verbose -auth /var/run/gdm/auth-for-gdm-pKo7NS/database -nolisten tcp vt1 I had some SELinux problems during the upgrade from f9 to f10 on the stuck machine. Maybe they prevented some of the configuration of gdm from completing? Clearly gdm is starting Xorg differently on the two machines. Thanks for the help.
Initially I thought it was the same issue being discussed here https://bugzilla.redhat.com/show_bug.cgi?id=467793 - but I am not sure.
Created attachment 329289 [details] X :123 vt1 After trying a few more times, I can only get to the crosshatch background, albeit on vt1, when trying to run X from the console. The server log file is attached.
Well if you're running X directly, you'll only get a crosshatch background. You won't get any apps. You'd have to export DISPLAY=:123 and then run e.g. xterm once the background is up.
So it seems that I can bring up X on vt1 manually just fine. What is preventing this from working during boot? Is this a configurable gdm setting?
I have the same problem after an upgrade from Fedora 9 to Fedora 10 the X-server still runs on vt7, is there a way to fix this?
It works now for me, what I did was rm -f /etc/sysconfig/desktop to remove the file which was empty (0 byte). Then I used ldconfig to update the /etc/ld.so.cache cache and after that I did mkinitrd -v -f /boot/initrd-`uname -r`.img `uname -r` to create a new initrd image and now the X-Server starts on vt1, the problem actually was that plymouth never created the file /var/spool/gdm/force-display-on-active-vt so my first idea was to create a new initrd image which changed nothing then I did 'ldconfig' and after this I created a new initrd image which again changed nothing, the last step was to remove the empty /etc/sysconfig/desktop file and after this 'ldconfig' and then "mkinitrd -v -f /boot/initrd-`uname -r`.img `uname -r`" and now it works... plymouth creates the /var/spool/gdm/force-display-on-active-vt file and the X-server starts on vt1. I don't know how all the steps are related :-) but this at least worked for me (on two different systems).
*** Bug 484432 has been marked as a duplicate of this bug. ***
/etc/sysconfig/desktop is also empty here. What's supposed to be in there?
Deleting the empty /etc/sysconfig/desktop fixed everything for me, no other steps were necessary. http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/ref-guide/ch-sysconfig.html#S2-SYSCONFIG-DESKTOP An old version of Fedora left /etc/sysconfig/desktop behind and the current code for something (gdm, plymouth, ?) doesn't handle the situation gracefully. An empty file should be ignored, as if non-existent? The new package that used to own this file should have rpmsave'd the config file? Unclear. But the workaround is easy. Delete the empty /etc/sysconfig/desktop file and things should behave nicely. Thanks for the help JM & Julian.
$ LANG=C rpm -qf /etc/sysconfig/desktop file /etc/sysconfig/desktop is not owned by any package
I can confirm that deleting the empty /etc/sysconfig/desktop file solves the problem. Updating the summary accordingly.
Ah this is a problem in the logic in /etc/X11/prefdm: if [ -f /etc/sysconfig/desktop ]; then . /etc/sysconfig/desktop if [ "$DISPLAYMANAGER" = GNOME ]; then preferred=/usr/sbin/gdm quit_arg="--retain-splash" elif [ "$DISPLAYMANAGER" = KDE ]; then preferred=/usr/bin/kdm elif [ "$DISPLAYMANAGER" = WDM ]; then preferred=/usr/bin/wdm elif [ "$DISPLAYMANAGER" = XDM ]; then preferred=/usr/bin/xdm elif [ -n "$DISPLAYMANAGER" ]; then preferred=$DISPLAYMANAGER fi else quit_arg="--retain-splash" fi should probably be: quit_arg="--retain-splash" if [ -f /etc/sysconfig/desktop ]; then . /etc/sysconfig/desktop if [ "$DISPLAYMANAGER" = GNOME ]; then preferred=/usr/sbin/gdm elif [ "$DISPLAYMANAGER" = KDE ]; then preferred=/usr/bin/kdm quit_arg="" elif [ "$DISPLAYMANAGER" = WDM ]; then preferred=/usr/bin/wdm quit_arg="" elif [ "$DISPLAYMANAGER" = XDM ]; then preferred=/usr/bin/xdm quit_arg="" elif [ -n "$DISPLAYMANAGER" ]; then preferred=$DISPLAYMANAGER quit_arg="" fi fi (or add an else clause inside the outer if that sets quit_arg to --retain-splash)
Hm. That won't quite work, because if you have an empty /etc/sysconfig/desktop, but only kdm installed, you'll get --retain-splash passed to plymouth when you don't want it.
... which is already the case if you have no /etc/sysconfig/desktop, so I suppose it's not a regression.
http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=747f8b92dd141b4ebe894d211e0500d3330cb84e Will be in 8.92-1, and is on the F-10 branch for a future update.
initscripts-8.86.1-1 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/initscripts-8.86.1-1
initscripts-8.86.2-1 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/initscripts-8.86.2-1
initscripts-8.86.3-1 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.