Red Hat Bugzilla – Bug 21185
GNOME panel not displayed
Last modified: 2013-04-02 00:14:45 EDT
GNOME menu bar is not displayed on DELL Inspiron 5000e with Rage mobility
128 AGP X2.
Have gone thru everything RedHat support suggested but still doesn't work
(upgraded to XFree86-4.0.1 and changed monitor type/ refresh rates)
KDE works fine - but i want to use GNOME
Switch to a VC. Type:
If I'm guessing right, you'll suddenly see some odd kernel messages. :)
If so, ask Dell for a BIOS upgrade.
But I am a complete newbie to Linux -
>Switch to a VC. Type:
what does that mean or what do I do?
Hit 'contrl-alt-f1'; you'll see a login prompt.
Login as root, and then type:
Downloaded the latest bios update from the dell support pages - still get error
messages with cat /proc/apm and GNOME menu bar still just flashing for a while
on login then dissapears totally.
>Inspiron 5000e System BIOS Release Notification (Rev. A04) 9/22/00
Any more suggestions?
Bug Dell. It really is a bug in their BIOS.
There are workarounds in progress for this (they refuse to enable
APM on these particular BIOSes).
*** Bug 21397 has been marked as a duplicate of this bug. ***
My bug report was marked a duplicate of this (21397) and closed. I was told
that this was a "hardware bug". However, the bug is about panel crashing not
about wether the apm implementation is correct. Panel is crashing because it is
hard-coded to check this apm file and turn on the battery monitor. The fact
that it can not handle errors in this process (heck, the fact that it is hard-
coded with no bypass that I can see) is a bug in panel. Simply blaming it on
the bios or saying "boot with apm=off" will not help the problem any. Some
cases certain apm functions (such as suspend) will work correctly without the
apm=off but panel crashes. In these cases it is not always the best solution to
just say "oh, apm=off fixes the panel crash" as they may have need to use the
suspend features of the laptop/computer.
In short: Can't there be some way to at least bypass the check that panel does
It is not a panel bug that it crashes. The panel dies, because
the kernel kills it, because the BIOS in your laptop crashes
when a perfectly-within-standard call is made to it.
*** Bug 21405 has been marked as a duplicate of this bug. ***
A buggy APM BIOS still does not explain why the global defaults for the panel
are hard-coded without a way to bypass them. In the situation where it is a
multiuser system, a situation where the user's hard-coded default settings for
the panel crash it (yet, the admins do not, because he say for example copied
his other machine's .gnome directories with the panel.d intact) can make life
annoying for that user and/or the admin. The fact that there is no easy way
(aside from setting up a working user and moving his .gnome settings to the
skel dir) to bypass the hardcoded settings for global defaults is the bug here.
It has the potential to cause more problems then those simply related to a
Hi Guys. I worte bug #21405 Conflict between gnome-core(panel) and apm.
I hope this hasen't degenerated into one of those situations where having the
high moral ground keeps getting in the way of progress.
This problem originated feb00 as a new feature. I'd say on the whole it is well
ment and properly implemented. But it has proven to be premature. The APM issues
need to be worked out before it is accepted globally. Until APM works with more
BIOSes, the basic installation should not flake out.
Very possibly it should be changed. It's not that APM needs to work
with more BIOSes, it's that those BIOSes are fundamentally broken.
The BIOSes in question implement ACPI; that's what Windows uses for
powersaving on those machines. Instead of simply not implementing
APM, however, they implemented just enough so that it's detected, but
it crashes if you tell the BIOS to do APM related stuff.
I recieved a response from the maintainer re this issue. Excerpted summary
> > Would you consider changing session.c so that hard coding is used only
> > for those applets necessary to the proper operation of the panel?
> Hmm I would still like to include battery_applet if apm is available since it
> is very useful for those with laptops and thus would be good to start by
> default. I've added a "fix" to my TODO so that we check for buggy /proc/apm
> on not auto-add battery_applet if it crashes. That's not the
> best solution but I suppose it's a good enough solution.
> I've had a little more time to think on this, and chatted with some
> others. Another solution that was brought up was to have a config
> option, perhaps in .gnome/panel or the enviroment. One that could
> disable the use of apm and the battery applet.
I've actually implemented the crash test in CVS HEAD now, so it will be in
there for 1.4. An option is hard to find and would likely still result in
people filing bugs.
gkb 12-1-00 skip back to a comment about a workaround
> The trick is to have each user login during a boot where apm=off is
> passed to the kernel on boot. That way /proc/apm is not created, the
> panel starts up without referencing apm and crashing, and all the
> necessary files get created. On subsequent boots even if apm is enabled,
> the test in session.c is never called.
George 12-3-00 (referring to hardcoded defaults)
Yes it is only for creating a default session. There is quite a bit of logic
there to figure out what would be a good default setup for the user. And
this is part of it. Once there is any other setup none of it gets called.
That's it. George is putting in code to test for buggy APM/BIOS interactions.
Doesn't fix the real problem, but doesn't continue to compound it either.
*** Bug 22603 has been marked as a duplicate of this bug. ***
The panel has a check for a broken /proc/apm. The real fix is, of course,
getting the bios fixed, but this will work for now.