ACPI ac module not getting loaded before e2fsck runs

[MsK`]

This ACPI module needs to be loaded before e2fsck runs. This would allow e2fsck to detect when a laptop is booting on battery, so it can skip filesystem checks to save battery life.

[Mark Reitblatt (mark-reitblatt)]

Interesting idea. Perhaps not just skipping, but instead increasing the threshold to X + n for some n?

[Michael Vogt (mvo)]

If runing on battery, the fsck will be skipped automatically. If this is not the case for you, please run:
$ sudo on_ac_power ; echo $?
and attach the output here.

Thanks,
 Michael

[MsK` (msk-lywenn)]

$ sudo on_ac_power ; echo $?
1

[Ian Redfern (ian-redfern)]

I have the same problem, running Feisty on my ACPI-equipped ThinkPad X60, and on_ac_power works correctly for me once booted.

However, the problem seems to be that on an ACPI machine on_ac_power checks for /proc/acpi/ac_adapter.

This directory only exists when the ac kernel module is loaded.

That module is loaded by /etc/rc2.d/S10acpid, which runs after /etc/rcS.d/S30checkfs.sh.

So when checkfs.sh calls on_ac_power, the answer it gets is 255, at least on my machine.

Perhaps on_ac_power should modprobe ac?

[Roel Huybrechts (rulus)]

I'm running the latest Ubuntu Feisty, and I just had a check while running on battery..

The output of $ sudo on_ac_power ; echo $? shows:
0

[Ian Redfern (ian-redfern)]

Does on_ac_power report 255 when the file system check runs, before the ac module has been inserted?

The easiest way to find out is to modify /etc/init.d/checkfs.sh to do something like

log_success_msg "Result from on_ac_power is $?"
sleep 5

after it runs on_ac_power.

The following patch has worked for me, and I no longer get fscks on battery:

$ diff -u /sbin/on_ac_power.orig /sbin/on_ac_power
--- /sbin/on_ac_power.orig 2007-04-05 17:01:23.000000000 +0100
+++ /sbin/on_ac_power 2007-04-07 11:27:50.000000000 +0100
@@ -20,6 +20,7 @@
 # that have known states. If any adapter is on-line, we return 0. If
 # no adapters are on-line but one or more are off-line, we return 1.
 #
+modprobe ac
 if /sbin/acpi_available && [ -d /proc/acpi/ac_adapter ]; then
     OFF_LINE_P=no
     for FN in /proc/acpi/ac_adapter/*; do

[Roel Huybrechts (rulus)]

I have modified my /etc/init.d/checkfs.sh, it know looks as follows:

(..)
do_start () {
 # See if we're on AC Power
 # If not, we're not gonna run our check
 if which on_ac_power >/dev/null 2>&1
 then
  on_ac_power >/dev/null 2>&1

  #changed from here
  log_success_msg "Result from on_ac_power is $?"
  sleep 5
  #to here

  if [ $? -eq 1 ]
  then
   [ "$VERBOSE" = no ] || log_success_msg "Running on battery power, so skipping file system check."
   BAT=yes
  fi
 fi
(..)

Is this correct?

Another question: I'll have another check for my / partition in about 5 mounts: how to check and what will happen?

Thanks

[Theodore Ts'o (tytso)]

This bug should be rejected, since e2fsck already has this functionality (built into the binary).

If you are running off battery, it will double the number of mounts that are allowed until it forces an fsck. This allows the check to be deferred, but not indefinitely.

[Theodore Ts'o (tytso)]

e2fsck has this feature already (and has had it since e2fsprogs version 1.35, released February 28, 2004)

[Ian Redfern (ian-redfern)]

The problem is that, like on_ac_power, e2fsck checks for /proc/acpi/ac_adapter/*/state in unix.c:is_on_batt().

This directory will not exist until the ac module is loaded.

The ac module is loaded by /etc/rc2.d/S10acpid, which runs after /etc/rcS.d/S20checkroot.sh and /etc/rcS.d/S30checkfs.sh, so e2fsck can't know that it's running on battery.

I suggest modifying /sbin/on_ac_power (which is run by checkroot.sh) to do a modprobe ac, in which case, this should be reassigned to powermgmt-base.

[ski (skibrianski)]

This bug has been bounced from 3 different packages like a hot potato. Will someone please own up?

Also, I take issue with it being classified as "wishlist" - this is not wishlist, this is a regression of working and important functionality. Laptops, unlike desktops, can boot up and down a lot, so 30-odd mounts can happen in a week easily, and if a fsck happens while you are on battery, it's a serious time and battery waste.

No one with a windows or mac laptop from the past decade will ever have to wait for a fsck on boot, especially on battery, unless they are using FAT. I think that, at the bare minimum, we should do better than windows 98 :)

[unggnu (unggnu)]

Still present in current Gutsy.

[Theodore Ts'o (tytso)]

It works fine for me (Ubuntu Feisty), but I'm building my own kernel and CONFIG_ACPI_BATTERY is set to "yes", instead of building it as a module. The problem is that the init scripts aren't loading the acpi ac module soon enough, so there is no way for e2fsck to tell whether or not we are on battery or not at that stage of the boot script. There is nothing e2fsck can do here; this is a bug in the init scripts. Or, you can do what I do and build your own kernel. In any case, this is NOT an e2fsprogs bug. As I said, it works fine for me, and the fix very clearly doesn't involve e2fsprogs; it involves making sure that /proc/acpi/ac_adapter is visible when e2fsck runs, which is a function of loading the acpi ac module early enough, or building it directly into the kernel.

[unggnu (unggnu)]

Of course it is an init bug. It works fine in Dapper and started with Edgys upstart to ignore battery mode.

[Ian Jackson (ijackson)]

This would be a useability improvement I think. Does anyone object to the solution proposed by Ian Redfern ?

(Thanks, Ian, for your helpful comments.)

[unggnu (unggnu)]

It seems to be fixed in Gutsy. At least I always got a message fsck was skipped because of battery mode.

[ski (skibrianski)]

unggnu -

Unfortunately, the problem is still happening for me - I retested just now after receiving your message.

sudo tune2fs -c 33 /dev/sda6
sudo tune2fs -C 33 /dev/sda6

unplug and reboot, and I still get a fsck.

Trying to figure out what could be different between my system and yours...

sda6 is my my root filesystem, which is ext3 - it might not happen on other partitions?
My install is not a fresh gutsy install - I upgraded from feisty (which was a fresh install).
I also am on amd64, not i386, which might make a difference.

[Theodore Ts'o (tytso)]

Suggestion: In /etc/init.d/checkfs.sh and /etc/init.d/checkroot.sh, at the beginning of the file, place the command:
ls /proc/acpi/ac_adapter. If it's not there, then that's clearly your problem. The thing to check would be the initrd file. to see if it includes the acpi modules:

gunzip < /boot/initrd.img-2.6.24-rc1 | cpio -t | grep acpi

(Replace initrd-2.6.24-rc1 with the name of the initrd of whatever kernel you're running.)

Finally, check /etc/initramfs-tools/initramfs-tools.conf. What is the settings for the MODULES parameter? I've set my config file to:

#
# MODULES: [ most | netboot | dep | list ]
#
# most - Add all framebuffer, acpi, filesystem, and harddrive drivers.
#
# dep - Try and guess which modules to load.
#
# netboot - Add the base modules, network modules, but skip block devices.
#
# list - Only include modules from the 'additional modules' list
#

MODULES=most

It may be that you have this set to "list" or "dep", and it's not picking up the APCI modules as a result.

The problem is I run bleeding edge kernels because I like to live on the edge (and because I like being able to get 8 hours of battery life out of my computer --- see http://thunk.org/tytso/blog/2007/10/29/tip-o-the-hat-wag-o-the-finger-linux-power-savings-for-laptop-users/#comments
for more details. So I don't see things which are clearly kernel packaging and configuration options issues for default ubuntu kernel users. Those issues are important of course; but I'm not the person to debug them....

[Manuel López-Ibáñez (manuellopezibanez)]

What is incomplete in this bug report? I also have the same problem. I just deactivated the fsck check completely.

[Manuel López-Ibáñez (manuellopezibanez)]

Fixes?

1. Build the kernel with the ac module compiled into the kernel.
2. Modify the initscripts to load the ac module early enough and (it that fails) complain in a message, so users can tell that something went wrong (Failed loading ac module: Cannot determine whether running on batteries). I mean, once you are dumped into fsck, every novice user thinks that something went wrong already, so another scary message can't hurt.
3. ???

Also, that the initscripts have all the logic about running or not fsck when the same logic is already implemented in fsck is totally redundant and a source of confusion (and confusion leads to bugs). Should I report another bug about that?

[unggnu (unggnu)]

It is still not fixed. It doesn't happen with my self compiled kernel but still with the Ubuntu one.
It happens since the first integration of Upstart (Edgy).

[unggnu (unggnu)]

It seems to be only a kernel bug so the init entries could be closed.

[Theodore Ts'o (tytso)]

It's not necessarily a kernel bug. The issue is that *either* the ac_adapter module needs to be loaded explicitly by the init scripts *before* fsck is run, *or* the ACPI and ac_apater modules need to be explicitly configured as being built into the kernel, i.e.:

CONFIG_ACPI=y
CONFIG_ACPI_AC=y

So this can be fixed in the kernel config file or by having the init scripts load the acpi and ac modules early.

[Stefan Bader (smb)]

I would propose the attached patch for the initscripts package.

[Stefan Bader (smb)]

This is not a real kernel problem. IMHO the module should be loaded by the script that requires it.

[ski (skibrianski)]

Stefan's patch works perfectly for me on an otherwise clean amd64/gutsy box. Please do apply this patch to hardy (in fact, if I had a vote I'd vote for applying it on gutsy, and with further testing feisty and edgy as well), as this bug has lingered an embarrassingly long time! Thanks much Stefan.

[Manuel López-Ibáñez (manuellopezibanez)]

So now this bug is INVALID in 3 packages and WONTFIX in 1 (the kernel). How useful!

Well, let's say it is a general Ubuntu bug. But sending it into oblivion can't be right when everybody agrees that it is a bug.

[ski (skibrianski)]

manu, I share your sense of frustration - time for the various teams to stop squabbling and for someone to pick up the slack and commit Stefan's fix. At least we have a patch that works and an assignee at canonical now. The bug is still open in ubuntu-meta, where I suspect it will be filed. Have faith ;-)

[Theodore Ts'o (tytso)]

Well, if someone official believes that it's not a kernel bug, I'm changing the status of the sysvinit from "Invalid" to "Conformed", and hopefully someone official from the sysvinit team will deal with it, noting that a patch has already been provided by Stefan Bader. Can someone official from Ubuntu assign a priority and a relevant Ubuntu developer? Many thanks!!

[Colin Watson (cjwatson)]

Closing out ubuntu-meta task; the sysvinit one is adequate.

[Colin Watson (cjwatson)]

I've sponsored Stefan's fix to sysvinit.

[Launchpad Janitor (janitor)]

This bug was fixed in the package sysvinit - 2.86.ds1-14.1ubuntu39

---------------
sysvinit (2.86.ds1-14.1ubuntu39) hardy; urgency=low

  * If ACPI is available, load the ac module before checking the root
    filesystem (LP: #89752).

 -- Stefan Bader <email address hidden> Tue, 11 Mar 2008 15:01:49 +0000

[Theodore Ts'o (tytso)]

Colin, Stefan, many thanks!!

[Colin Watson (cjwatson)]

Sorry it took so long to get all the ducks in a row.

[ski (skibrianski)]

Thanks all for finally getting this straightened out. I realize it's not a priority at the moment with the big crunch for hardy upon us, but is there any change for a "backport" (it's the exact same patch) to gutsy, feisty, or etch (all of which it is also broken in, but I believe it works as intended in dapper) ?