From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 Description of problem: IBM R40 laptop with FC1 the gnome battery applet on the panel works correctly (reports charge, power connection, etc) Upgrade to FC2 with new 2.6 kernel which enables ACPI by default and the Battery Charge Monitor fails on load with: """ Can't access ACPI events in /var/run/acpid.socket! Make sure the ACPI subsystem is working and the acpid daemon is running. """ Additionally it then fails to show any charge in the battery or respond to power/no power etc. If the 2.6 kernel is booted with acpi=off in the kernel command line the Battery Charge Monitor works correctly again. Version-Release number of selected component (if applicable): gnome-applets-2.6.0-5 How reproducible: Always Steps to Reproduce: 1.Run FC1, Battery Charge Monitor works correctly 2.Upgrade to FC2 with 2.6 kernel, Battery Charge Monitor fails on load 3.Reboot with acpi=off with 2.6 kernel (or boot old 2.4 kernel) and Battery Charge Monitor loads and works correctly Actual Results: Battery Charge Monitor non-functional (shows 0% charge forever) Expected Results: Battery Charge Monitor reflects actual battery status Additional info: I assume this is because the applet uses APM, which is disabled by ACPI on boot.
If applet settings are stored in a user directory, and a user partition is restored from backup on a newly updated system, how does the battstat applet recognise that APM has been replaced by ACPI? I had trouble with ACPI not detecting my battery info, and when I removed and reinstalled a battstat applet on the panel it chose the wrong default suspend command (apm related one on an ACPI kernel)
The same happened to me. In my case I understud that the acpid RPM was not installed on my machine after the upgrade. So I installed it from the first FC2 CD and now it works.
Wrong suspend command issue is in bug #121061. The issue with the applet working with ACPI on - i.e.: """ Can't access ACPI events in /var/run/acpid.socket! Make sure the ACPI subsystem is working and the acpid daemon is running. """ has always turned out to be a problem with ACPI in any upstream report I've seen. Moving to acpid.
Well, if acpid isn't running, there is the problem in bug 114443.
Is acpid running on machines that experience this?
Closing, no response. If you get that message, it generally means that acpid isn't running.