Bug 480113 - empty /etc/sysconfig/desktop prevents gdm from starting Xorg on vt1 after upgrade from f9 to f10, still starting on vt7
empty /etc/sysconfig/desktop prevents gdm from starting Xorg on vt1 after upg...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
10
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
http://forums.fedoraforum.org/showthr...
:
: 484432 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-15 00:42 EST by Naveed Hasan
Modified: 2014-03-16 23:17 EDT (History)
6 users (show)

See Also:
Fixed In Version: 8.86.3-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-20 15:57:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
X :123 vt1 (14.52 KB, text/plain)
2009-01-17 15:40 EST, Naveed Hasan
no flags Details

  None (edit)
Description Naveed Hasan 2009-01-15 00:42:13 EST
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?
Comment 1 Ray Strode [halfline] 2009-01-15 08:59:06 EST
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

?
Comment 2 Naveed Hasan 2009-01-15 23:50:26 EST
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.
Comment 3 Naveed Hasan 2009-01-16 13:23:03 EST
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.
Comment 4 Naveed Hasan 2009-01-17 15:40:54 EST
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.
Comment 5 Ray Strode [halfline] 2009-01-19 11:39:05 EST
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.
Comment 6 Naveed Hasan 2009-01-27 14:40:16 EST
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?
Comment 7 JM 2009-02-27 11:45:53 EST
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?
Comment 8 JM 2009-02-27 12:40:32 EST
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).
Comment 9 Julian Sikorski 2009-02-27 13:10:04 EST
*** Bug 484432 has been marked as a duplicate of this bug. ***
Comment 10 Julian Sikorski 2009-02-27 18:49:21 EST
/etc/sysconfig/desktop is also empty here. What's supposed to be in there?
Comment 11 Naveed Hasan 2009-02-28 19:15:26 EST
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.
Comment 12 Julian Sikorski 2009-03-01 06:28:22 EST
$ LANG=C rpm -qf /etc/sysconfig/desktop
file /etc/sysconfig/desktop is not owned by any package
Comment 13 Julian Sikorski 2009-03-01 13:54:18 EST
I can confirm that deleting the empty /etc/sysconfig/desktop file solves the problem. Updating the summary accordingly.
Comment 14 Ray Strode [halfline] 2009-03-04 11:24:02 EST
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)
Comment 15 Bill Nottingham 2009-03-20 15:54:38 EDT
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.
Comment 16 Bill Nottingham 2009-03-20 15:55:21 EDT
... which is already the case if you have no /etc/sysconfig/desktop, so I suppose it's not a regression.
Comment 17 Bill Nottingham 2009-03-20 15:57:00 EDT
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.
Comment 18 Fedora Update System 2009-04-02 14:04:30 EDT
initscripts-8.86.1-1 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/initscripts-8.86.1-1
Comment 19 Fedora Update System 2009-04-03 00:16:11 EDT
initscripts-8.86.2-1 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/initscripts-8.86.2-1
Comment 20 Fedora Update System 2009-04-22 16:22:41 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.