login background color is hardcoded

Bug #132833 reported by mon
80
Affects Status Importance Assigned to Milestone
gdm
Fix Released
Medium
gdm (Ubuntu)
Fix Released
Low
Ubuntu Desktop Bugs

Bug Description

Hi

In gutsy, after entering my login credentials, the desktop background color is changed to a camel color. I've tried changing this setting in the appeareance applet and the gdm/login configuration both to black but this camel color continues to appear, so it seems somewhere this color is hardcoded and picked by gnome. Since many people like to change the desktop I think this is an annoying thing to happen. This is a regression from feisty.

gdm:
  Instalados: 2.19.5-0ubuntu3
  Candidato: 2.19.5-0ubuntu3
  Tabla de versión:
 *** 2.19.5-0ubuntu3 0
        500 http://archive.ubuntu.com gutsy/main Packages
        100 /var/lib/dpkg/status

gnome-control-center:
  Instalados: 1:2.19.90-0ubuntu1
  Candidato: 1:2.19.90-0ubuntu1
  Tabla de versión:
 *** 1:2.19.90-0ubuntu1 0
        500 http://archive.ubuntu.com gutsy/main Packages
        100 /var/lib/dpkg/status

thanks

Related branches

Revision history for this message
mon (javiermon-deactivatedaccount) wrote :

To reproduce just launch the login window configuration applet and change the background color to black, then launch the appeareance apple and change the color to black. Restart X and log in again. You'll see a camel background between the transition from gdm to the desktop.

Revision history for this message
QuentinHartman (qhartman) wrote :

This behavior has always existed, AFAIK, but you imply that in Feisty that background color was synchronized with your GDM choice. Is that the case? That color you see between login and Gnome is the root X window, which exists "below" the GDM and typical Gnome Desktop levels. So you will see it "poke through" between the time GDM exits and Gnome finishes loading. To change it by hand, you can edit the file /etc/gdm/PreSession/Default and change the BACKCOLOR variable defined around line 61 of that file. It is default set to "#dab082", which is the camel color you describe. To make it black instead, set it to "#000000". I will continue to look into this and see if it syncs to my GDM choice on a Feisty box.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks for the bug report. This particular bug has already been reported, but feel free to report any other bugs you find.

Changed in gdm:
assignee: deque → desktop-bugs
importance: Undecided → Low
status: Confirmed → Invalid
Revision history for this message
Sebastien Bacher (seb128) wrote :

not sure of the Ubuntu bug number, it's upstream http://bugzilla.gnome.org/show_bug.cgi?id=438939, marking Triaged for now

Changed in gdm:
status: Invalid → Triaged
Changed in gdm:
status: Unknown → New
Revision history for this message
karlinux (carlosmolines) wrote :

The same thing happens to my me.
Installed Gutsy Tribe4 updated to 5

Revision history for this message
Guido Conaldi (guido-conaldi) wrote :

The regression stil occurs on my gutsty up-to-date and the last comment upstream is from june.

Here:
http://bugzilla.gnome.org/show_bug.cgi?id=438939#c12
a reversion is suggested to fix the problem, could some expert look if that can be done without causing incompatibilities?

thanks

eTM (juergen-mangler)
Changed in gdm:
status: Triaged → Confirmed
Revision history for this message
eTM (juergen-mangler) wrote : Re: login background color is hardcoded - FIX

Affected File (in gutsy):
/etc/gdm/PreSession/Default

Reason:
GDM_GREETER_TYPE is not set, so always fallback to hardcoded color

Fix - add the following lines (after the comment "Set background color"):
GDM_GREETER_TYPE=`gdmflexiserver --command="GET_CONFIG daemon/Greeter $DISPLAY"`
GDM_GREETER_TYPE=`echo $GDM_GREETER_TYPE | sed 's/^.*gdmlogin.*$/PLAIN/'`
if [ "x$GDM_GREETER_TYPE" != "xPLAIN" ]; then
  GDM_GREETER_TYPE=THEMED
fi

regards

eTM

Revision history for this message
eTM (juergen-mangler) wrote :

I confirmed the bug and provided a solution.

Revision history for this message
eTM (juergen-mangler) wrote : FIX #2

First fix was only working when already authenticated (gdmflexiserver): the following fix should work for EVERYONE :-)

Affected File (in gutsy):
/etc/gdm/PreSession/Default

Reason:
Authentication missing

Fix:
replace every "gdmflexiserver" whith "gdmflexiserver -a"

Comment:
This could be a problem in other places besides this file also (leading possibly to other bugs).

regards Jürgen

Revision history for this message
Guido Conaldi (guido-conaldi) wrote :

I tried to apply your solution Jurgen, but the color I set appears just for a second and afterwards it falls back to the hardcoded color.

Here is my /etc/gdm/PreSession/Default

Revision history for this message
eTM (juergen-mangler) wrote : Try this

Yeah, my comments are a bit confusing now :-) Please try this (I should have sent an attachment from before)

This should word

Jürgen

Revision history for this message
Guido Conaldi (guido-conaldi) wrote :

It actually works, thanks Jürgen.
I hope the fix will be noticed upstream.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Could anybody send a patch or debdiff to fix the issue?

Revision history for this message
Sebastien Bacher (seb128) wrote :

I've also forwarded some informations from the bug upstream now

Changed in gdm:
status: Confirmed → Triaged
Revision history for this message
Justin Straub (jwstraub) wrote :

Here's how to fix the problem.....

open /etc/gdm/PreSession/Default

change the part under the comment "#Default value" from this:

 # Default value
  if [ "x$BACKCOLOR" = "x" ]; then
   BACKCOLOR="#dab082"
  fi

To This:

 # Default value
  if [ "x$BACKCOLOR" = "x" ]; then
   BACKCOLOR="x"
  fi

that worked for me, hopefully it does (and it should) for those who are having a problem with
the bug. If it doesn't work, just login under 'failsafe gnome' and reedit the file to its original state.

Revision history for this message
mon (javiermon-deactivatedaccount) wrote :

Worked here. I've created a patch from what Justin said

Revision history for this message
Sebastien Bacher (seb128) wrote :

the patch doesn't really make sense, you can as well remove the test if that's to do if color=x then color=x

Revision history for this message
mon (javiermon-deactivatedaccount) wrote :

no test patch

Revision history for this message
Guido Conaldi (guido-conaldi) wrote :

The fix proposed by eTM in comment #11 is already working perfectly for me, so I patched the Default file that comes with gdm 2.20.0ubuntu3 using his file.

Revision history for this message
Sebastien Bacher (seb128) wrote :

the new patch is weird, anyway why do you want to remove the default rather than fixing this bug the correct way?

Revision history for this message
Sebastien Bacher (seb128) wrote :

Could people stop to apply such workaround? you are breaking next upgrades this way but will probably not notice for some time until the configuration change in the package and then you will wondering why the upgrades are broken

Revision history for this message
Ivan Diaz (saisyukusanagi) wrote :

In my opinion, this is the best solution:

Replace this line in /etc/gdm/PreSession/Default

BACKCOLOR="#dab082"

With this:

BACKCOLOR=`gdmflexiserver --command="GET_CONFIG greeter/BackgroundColor $DISPLAY"`

If you make changes using gdmsetup, won't have to change the file, for every backcolor change.

The file is used only by GDM, i don't think that the file should have a static color in its config.

Revision history for this message
yop (yop) wrote :

"In my opinion, this is the best solution:

Replace this line in /etc/gdm/PreSession/Default

BACKCOLOR="#dab082"

With this:

BACKCOLOR=`gdmflexiserver --command="GET_CONFIG greeter/BackgroundColor $DISPLAY"`"

That did not work for me, however.
If I replace the line in /etc/gdm/PreSession/Default

 # Default value
  if [ "x$BACKCOLOR" = "x" ]; then
  BACKCOLOR="#dab082"
  fi

to

 # Default value
  if [ "x$BACKCOLOR" = "x" ]; then
  BACKCOLOR="x"
  fi

Then it obey the login manager colour settings.

Revision history for this message
thom (tsk) wrote :

Hi there,

Most of the solutions here just obscure the bug, Sebastien Bacher is right in this.
The reason that the "camelcolor" appears is the wrong usage of gdmflexiserver.

The gdmflexiserver -a (authenticate) should be a more direct approach to the real reason that we all seem to get the "camelcolor" screen.
For me it does not make a difference, here is my ~/.xserver-error log (set -x) and see what (not) happens:

Pay particular attention to:
------
Refusing to initialize GTK+.
+ BACKCOLOR=
------
which is the direct reason for the camelcolor to appear.

=================================================
+ echo /usr/bin/xsetroot
+ XSETROOT=/usr/bin/xsetroot
+ [ x/usr/bin/xsetroot != x ]
+ CHECKBACKCOLOR=OK
+ [ xTHEMED = xTHEMED ]
+ gdmflexiserver -a --command=GET_CONFIG greeter/GraphicalThemedColor :0

(process:5969): Gtk-WARNING **: This process is currently running setuid or setgid.
This is not a supported use of GTK+. You must create a helper
program instead. For further details, see:

    http://www.gtk.org/setuid.html

Refusing to initialize GTK+.
+ BACKCOLOR=
+ echo
+ sed s/^\([^ ]*\) .*$/\1/
+ CHECKBACKCOLOR=
+ [ x = xOK ]
+ BACKCOLOR=
+ [ x != xOK ]
+ gdmflexiserver -a --command=GET_CONFIG greeter/BackgroundType :0

(process:5973): Gtk-WARNING **: This process is currently running setuid or setgid.
This is not a supported use of GTK+. You must create a helper
program instead. For further details, see:

    http://www.gtk.org/setuid.html

Refusing to initialize GTK+.
+ BACKTYPE=
+ [ x = xOK 1 ]
+ [ x = xOK 2 ]
+ [ x = x ]
+ BACKCOLOR=#dab082 #<----YES, THE F%$%ing CAMELCOLOR IS HERE
+ /usr/bin/xsetroot -cursor_name left_ptr -solid #dab082
+ exit 0

================================================

grtz, tom

Revision history for this message
thom (tsk) wrote :

Sorry, second paragraph in my reply contains "should be" instead of "seems to be".
My apologies, i'm not a native speaker of the english language.

Revision history for this message
infodroid (infodroid) wrote : Jürgen's patch works

Sebastian:

I am confused by your comments: "Could people stop to apply such workaround? you are breaking next upgrades this way but will probably not notice for some time until the configuration change in the package and then you will wondering why the upgrades are broken"

Which workarounds are you talking about? The reason is there are two sets of solutions people are proposing. One is simply to set the value of BACKCOLOR, and the second one is Jürgen's fix.

Isn't the gdmflexiserver the problem? Jürgen's fix @ https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/132833/comments/11 replaces every "gdmflexiserver" with "gdmflexiserver -a".

I confirm that this works.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Those change etc files and will break upgrades

Revision history for this message
infodroid (infodroid) wrote :

Sebastian: From what I understand, you are saying people should not be modifying files under /etc/gdm because this will break upgrades. This is fair enough.

But still no clarity about whether in the short term, Jürgen's fix is the right way or not.

Revision history for this message
Sebastien Bacher (seb128) wrote :

the correct way would be to try the change suggested on bugzilla and comment there

Changed in gdm:
status: New → Fix Released
Revision history for this message
Sebastien Bacher (seb128) wrote :

The bug has been fixed upstream now

Changed in gdm:
status: Triaged → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gdm - 2.20.3-0ubuntu1

---------------
gdm (2.20.3-0ubuntu1) hardy; urgency=low

  * New upstream version:
    - Now "Esc" key acts like the "Start Again" button in the greeter program.
    - Fix regression in GDM 2.20 that caused the daemon to not read
      any [server-foo] sections that were not referenced in the
      [servers] section of the configuration file. This caused
      problems for gdmsetup when you tried to edit the Xserver configuration.
    - Fix regression in GDM 2.20 that caused HaltCommand,
      SuspendCommand, and RebootCommand to not get updated properly
      when modified from gdmsetup. (LP: #132939)
    - Fix gdmsetup so that it doesn't use gtk_init when run with
      the "--command" option. This allows the gdmflexiserver --command
      option to be run with setuid/setgid without problems. (LP: #132833)
    - Fix counting of open XDMCP sessions. In some situations this
      problem would cause GDM to think the maximum number of XDMCP
      sessions had been started when this wasn't the case. (LP: #152068)
    - Fix Suspend configuration option so it works.
    - Fix so that XDMCP Willing configuration option works.
    - Fixes to avoid compiler warnings.
    - Fix gdmsetup so it does not crash if it cannot read any
      displays from the configuration file.
  * debian/patches/10_noxkeepcrashing.patch,
    debian/patches/70_mandatory-relibtoolize.patch:
    - updated
  * debian/patches/90_workaround_init_color.patch:
    - removed, the issue is fixed in the new version

 -- Sebastien Bacher <email address hidden> Wed, 09 Jan 2008 18:41:35 +0100

Changed in gdm:
status: Fix Committed → Fix Released
Changed in gdm:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.