Laptop boots at Midnight, by itself.

Bug #235539 reported by wub on 2008-05-28
This bug affects 1 person
Affects Status Importance Assigned to Milestone
acpi (Ubuntu)

Bug Description

1. Ubuntu 8.04 revison 8.04, but also true for 7.04 and 7.10
2. No idea if any particular package is involved. Happy to submit info as update if directed to a package.
3. When I HALT, I expect my laptop to remain OFF until I ask it to start again.
4. It spontaneously boots at Midnight (local time).

True Fact. I thought my battery was defective because it would not hold a charge overnight, until I happened to turn off my laptop but leave the lid open and in my view. At 00:00:08 (according to my log) the system started up, right in front of me, and without my permission. All versions of Ubuntu I have tried, including the update I ran on 5/28/2008 at approximately 04:00 GMT, show the same behavior.

This system dual boots Windows XP. One reason that OS is still present is that >AFTER< my battery runs flat, I lose control of my touchpad. The only reliable way I have found to restore function is to boot into XP. (I don't have to login, tho ;) As a point of interest, if I "halt" from XP, the system does not spontaneously start. It will not start up again until I ask it to do so.

When I halt from Ubuntu the system appears completely inert. I think there must be some kind of BIOS setting that functions as an alarm clock, although I cannot find such a setting in Windows or Ubuntu. I have learned to press and hold the power button after Halting from Ubuntu, until the fan and lights go on, and a few seconds later, off. This process does work, when I remember to follow it. Thanks, Nathan!

If anyone wants further info from the machine itself, please ask, and I will add it.

Henrik S. (henrik-hw0) wrote :

I suppose some info from the "acpi -V" command would be helpful. alternatively the contents of relevant files from /proc/acpi. I recommend putting it in a compressed file and attach it to this bugreport.
There are a couple of things that could trigger a wakeup event, those things are controlled by ACPI (or APM).

Henrik S. (henrik-hw0) wrote :

Please check out the following link and try out what the page says:

botch77 (botch77) wrote :

Hello Hendrik!

I have the same problem, though it's not a laptop. The PC boots automatically at midnight. Here are some more facts:

- 2 OS installed: Win XP and Ubuntu 8.04
- I always do a regular shutdown (i, e. "shutdown -h now")
- Problem appears to be related to Ubuntu 8.04, since I did not have any problems under 7.10. I assume problem came with an update to 8.04, as I had no problems directly after "fresh" initial install in early may '08, but I am not sure.
- If I boot into WinXP and shutdown from there, PC does not boot at midnight
- It is unlike to be a virus/Trojan, since I scanned the system with 2 differet antivirus applications
- In BIOS option "Wake On RTC" (Wake PC up at specific time) is turned off
- BIOS option "Wake On LAN" is turned on (I need the abillity to remotley start the system). But PC also boots at midnight when I turn it off.
- I updated my BIOS to the most recent version, but still the system boots at midnight.

I attached the output of "lshw". "acpi -V" reports the following:

"No support for device type: thermal"

 If you need any other secific logs or something please mail me. I will try to follow the "Debugging ACPI"-URL also and let you know the results.

Thanks, Mark

Lars Ola Liavåg (l-liavag) wrote :

Hello there,

I got exactly the same problem when upgrading from Gutsy to Hardy, or probably rather after running the update manager afterwards. I've played around in BIOS to find a solution but without luck and went on to test boot parameters more or less randomly. After testing a parameter sequence I found on an Ubuntu forum for solving a somewhat different problem, the situation now seems OK. No more spontaneous booting at midnight. The trick was to boot the kernel with acpi=off and apm=power_off. Additionally, the line

apm power_off=1

must be added to /etc/modules. I don't understand why I need to make these changes. My BIOS is supposed to support both APM and ACPI, even though the computer admittedly is getting old, and why didn't I have any problems with Feisty or Gutsy. Beats me, but you could try it out and see if it helps even in your case.

botch77 (botch77) wrote :


A small update: Not just Ubuntu, also Xubuntu 8.04.1 comes with the behavior of booting spontaneously at midnight (kinda logic, isn't it? :) )

I installed Debian Etch. Etch did not show such behavior.

As a test I booted the machine with the "acpi=off" kernel parameter and then booting at midnight stopped. Thus I assume the problem is really related to ACPI somehow.

botch77 (botch77) wrote :

Hello Lars,

you were right:
- kernel option acpi=off turns ACPI support completely off
- kernel option apm=power_off turns on APM for powering the PC down
- "apm power_off=1" in /etc/modules loads the module for APM power off (I think)

This seems to be a valid work around, as the PC shuts down completely and does not boot spontaneously at midnight anymore.
But I guess it remains as a bug anyway, because as far as I understand ACPI it takes care of some more things than the (outdated) APM or works in a more efficient way. This affects mostly the energy saving functions.

I also tested Debian 4.0r3 and the Debian Testing XFCE distribution (Testing dated to begin of july 2008).
4.0r3 DOES NOT suffer from the wake up problem where as Testing DOES.


wub (wub) wrote :


Thank you for the suggestions about modifying /etc/modules and using the boot option acpi=off. I tried this but could only find two variations: either my system would not shut down at all, or it still rebooted at midnight.

I found a later note in a debian forum that indicated that dual-core cpus don't respond properly to acpi=off,
which a) applies to my laptop, and b) probably explains why my laptop would not even shut down when I tried this. I ended up in the Ubuntu Wiki at DebuggingACPI page, where I found this:

If "acpi=off" allows the system to boot, try to isolate the ACPI issue with the following boot parameters

    * Try booting with "acpi=ht"
          o This disables all of ACPI except just enough to enable Hyper Threading. If acpi=off works and acpi=ht fails, then the issue is in the ACPI table parsing code itself, or perhaps the SMP code.

And, surprise, I can't even boot when I try acpi=ht.

I believe that my problem may be tangentially related to the Foxconn BIOS problem posted at

I do not know if my BIOS is in the same state, but I suspect my problem is very much in this neighborhood.

I followed the instructions in the thread mentioned above, and I see that my BIOS does some strange workarounds to handle various versions of windows, and then just punts anything that has not been handled by the end of the block:

  Name (WNOS, Zero)
    Method (CKOS, 0, NotSerialized)
        If (LEqual (WNOS, Zero))
            If (SCMP (\_OS, "Microsoft Windows"))
                Store (One, WNOS)

            If (SCMP (\_OS, "Microsoft Windows NT"))
                Store (0x02, WNOS)

            If (SCMP (\_OS, "Microsoft WindowsME: Millennium Edition"))
                Store (0x03, WNOS)

            If (CondRefOf (\_OSI, Local0))
                Store (0x04, WNOS)

Then a bit further down the code, this appears:

                   Method (_STA, 0, NotSerialized)
                        If (LEqual (CKOS (), 0x04))
                            If (LEqual (HPTS, One))
                                Return (0x0F)
                                Return (Zero)
                            If (HPTS)
                                Return (0x0B)
                                Return (Zero)

Now, if I'm running "Not Windows", then instead of a 'real' value, NotSerialized is set to Zero. Um, might Zero also somehow relate to midnight.

Lars Ola Liavåg (l-liavag) wrote :

I'm really not fluent in these matters and part of what you wright is really beyond me. However, the motherbord on the plagued PC is an MSI so it's not impossible that it's got a BIOS from Foxconn. I'm prevented from checking it at the moment, though.

Still, even if it is about a bad BIOS, it doesn't explain why I didn't have any problems with Feisty or Gutsy (note that I never even tried to use suspend, I always shut down my computer when I'm done working on it). I've never updated my BIOS, so something's definitely changed in Ubuntu between Gutsy and Hardy.

Anyway, since I don't really need ACPI, I'm quite happy turning it off. I'll probably check the status again after each new kernel update and definitely after Intrepid is released.

Dave Gilbert (ubuntu-treblig) wrote :

Confirmed: Multiple reporters

Is anyone seeing this on anything after Hardy?
What hardware (vendor/model) are you all seeing it on?

Changed in acpi (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
Phillip Susi (psusi) wrote :

Hash: SHA1

 status expired
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird -


Changed in acpi (Ubuntu):
status: Confirmed → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments