Bug 480113

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.