fsck not run on boot if on battery power

[Ian]

I can see that this is deliberate - a 'feature' - in that /etc/init.d/checkroot.sh (and checkfs.sh) has an explicit check for being on batteries and then skips fsck if it is.

The problem is that if you are on batteries, it becomes difficult to run fsck on the root partition.

So, you're on battery power, something goes wrong, the file system is corrupted / the journal is not consistent, and... you're stuffed. When you next reboot, the file system won't be mended, it'll be left in a mess.

Why yes, this did affect me (thanks to a problem with Hardy alpha and beta causing kernel panics and lock ups). What I ended up having to do was editing the relevant bit out of the script.

I can't imagine skipping fsck saves any power - if the file system is ok, running it is extremely short. But ultimately, if the file system is in a mess, it needs to be sorted, on boot, whether you're on battery power or not.

The alternative of booting into maintenance mode, manually umounting the partition, then mounting read-only, then fsck-ing is beyond most users.

So please either lose this 'feature' or provide a way around it (check if a key is held down?)

[Ian (superian)]

This boot has reminded me that the system forces a full check every thirty or so mounts of a partition.

That's ok to skip if on batteries...

[danmb (danmbox)]

Mounting a "dirty" root file system without fsck is a dangerous feature. It negates the benefits of journaling file systems (fast fsck on unclean shutdown).

I think I understand how this "fix" came to be (people were complaining about the forced periodic fsck on ext3), but the hammer is too big.

The initscripts need to distinguish fsck's due to ext3's maximum mount count from fsck's due to a dirty file system.

[danmb (danmbox)]

I can also see why a fsck might be dangerous when running on batteries (what happens if the fsck takes a long time and the power runs out?)

However mounting a dirty fs can be even more dangerous, especially if the laptop is rebooted several times while on battery power.

The user must be given a choice.

[Scott James Remnant (Canonical) (canonical-scott)]

This is quite deliberate, you can run fsck using gparted by hand.

[sbs (sbs-bugs)]

It may be deliberate, but it is a bug nonetheless.

I'd say that 95+% of the improper shutdowns I've ever had have been on battery-powered devices, so specifically skipping filesystem checks on those devices is a huge problem.

As mentioned above, the power savings when the filesystem is fine is negligible, so there is no benefit. Unless you consider corrupted data a benefit.

Go ahead and skip the periodic check if you want, but do not skip a check forced due to an improper shutdown.

I am a relative noob to Ubuntu, having used Debian for the last ~10 years and now experimenting with Ubuntu due to the improved high-level usability over Debian. But poor low-level usability like this is driving me right back to Debian.

[Fabio Puddu (fabius)]

This is totally a bug and I don't understand the reason to mark it invalid.
The user should be able to decide if he/she prefers doing or not the filesystem check.
There's no reason to automatically skip fsck while running on batteries without giving an option to change the default behaviour!
I propose to mark it as confirmed.

[Scott James Remnant (Canonical) (canonical-scott)]

You're quite right, the report is valid. It should be Won't Fix, since the behaviour is intended.

Discussion for better ways to handle fsck should be held elsewhere.

[Removed by request (removed67550)]

I recently reinstalled my laptop to use jfs.. my experiences are purely positive. Now, let's combine these topics. Fsck for JFS takes few seconds even on large filesystems. This same behaviour (fsck skipped when on battery power) is quite annoying feature, since JFS refuses to mount as rw when the filesystem is marked as "dirty". So, I have to login+fsck+reboot after a crash.

I'm slowly giving up with ext filesystems, could anyone tell me a good reason why using so badly immature, slow and fscking annoying filesystem?

My decision to move to JFS with a laptop was based on lower processor usage (=lower battery usage) with a satisfying performance. I know, it is not the fastest on this planet but seems to be a reasonable compromise between resources and performance.

jouni

[Gilles Schintgen (shigi)]

@Scott: So where should this be discussed?

In my humble opinion this is a serious matter which is being downplayed by having it marked as WONTFIX. Now, I understand that technically speaking it's the design that's broken rather than the implementation, but the end result is the same: the current behaviour is endangering users' data. (Especially when they're experiencing random hard lockups due to the crappy Broadcom wl driver.)

I'm quite astonished that I have to manually edit the init.d scripts just to make sure I'm not putting my data at risk when booting after something unexpected happens.

[Scott James Remnant (Canonical) (canonical-scott)]

On Tue, 2009-02-17 at 20:28 +0000, Gilles Schintgen wrote:

> @Scott: So where should this be discussed?
>
UDS, or at least on the ubuntu-devel mailing list.

Scott
--
Scott James Remnant
<email address hidden>

[Martin Leopold (martin-leopold)]

Hi all,
This has further implications when using jfs as root (I am): jfs will only mount as read-only when it is dirty. This means that after a crash the system is un-bootable if running on battery power.

As far as I can tell, there is no way to force a check at boot time that will allow me to boot my system.

- Martin.

[Alistair Phipps (alistairphipps)]

Can someone with a clue take another look at this? I also came from Debian and am using JFS (a supported option via the alternate installer) and this bug renders my system unbootable from battery on unclean shutdown. It is a bug, plain and simple. fsck needs to be run on every boot, on battery or not. The issue with ext3 doing periodic checks on battery should have been fixed by the fix to bug #89752 so now this "feature" is just a bug.

[sumdog (sum-notify)]

Well my Dell Mini 10 wouldn't boot at a coffee shop and I couldn't figure out what was going on. This is my first shot at Ubuntu (been a Gentoo user for years) and I got all the errors I'm reading about in this bug when booting on battery. I used JFS (I like JFS) and it does need to have fsck run. I don't see why it's such a big deal to not run it on battery. Even with ext3, does it take THAT long? Seriously?!

So I tried all the normal tricks like "mount / -o remount -o rw" and all kinds of combinations. Never seen an fstab that attaches a UUID to a drive before now, but I can understand how that's useful.

Not even "init=/bin/sh" as a kernel param worked. There was no way for me to fix this until I got home, found this bug, and commented those lines out of the checkroot.sh and checkfs.sh boot scripts while on A/C power.

I'm about to go back to Gentoo. I like being able to actually fix stuff when it goes bad without having to plug in an A/C adapter. This is a serious bug. Won't fix? Seriously? You have got to be kidding me! And I though the guys on the Gentoo bugzilla were jerks. This is a serious bug. I guess it just doesn't apply to ext3 (probably xfs too)?

[DaveAbrahams (boostpro)]

on Thu May 28 2009, sumdog <sum.notify-AT-gmail.com> wrote:

> Not even "init=/bin/sh" as a kernel param worked. There was no way for
> me to fix this until I got home, found this bug, and commented those
> lines out of the checkroot.sh and checkfs.sh boot scripts while on A/C
> power.

1. boot into single user mode
2. touch /forcefsck
3. reboot

> I'm about to go back to Gentoo.

Don't kid yourself; all things involving computers are equally bad, just
in different ways <wink>. Can't blame you for being frustrated, though.

> I like being able to actually fix
> stuff when it goes bad without having to plug in an A/C adapter. This
> is a serious bug. Won't fix? Seriously? You have got to be kidding me!
> And I though the guys on the Gentoo bugzilla were jerks. This is a
> serious bug. I guess it just doesn't apply to ext3 (probably xfs too)?

Definitely JFS, anyway.

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

[sumdog (sum-notify)]

I should have cooled down first from my frustration. Sorry for the inappropriate bugzilla comment. All Linux systems have these kinds of problems, which is why we have these bug tracking systems.

The above "touch /forcefsck" wouldn't have worked because the filesystem was read-only. In the duplicate bug attached to this one, someone tried:

#mount -o remount,rw /
 # fsck /

I tried "mount / -o remount -o rw" but I kept getting "filesystem already mounted." It was probably because I was specifying -o twice instead of once with a coma between args, maybe?

I don't think this would be an issue if you ran XFS either because its fsck.xfs doesn't do anything (if you look at the source, it exits 0 right after main) and the journal playback is done on mount.

I agree with the other comments that fsck shouldn't be skipped on boot; that AC vs battery shouldn't play a role in that decision. I didn't notice that it had been changed from 'wont-fix' back to 'confirmed.'

Commenting out those lines in the check startup scripts fixed the problem on my laptop.

[EricDHH (ericdhh)]

Crunchbang-9.04 with jfs on my eee 901.

Run 2 times in this ugly behaviour, a eee ist most used at battery and some acpi quirks can cause a hang. Then the eee must hard switched off, next boot / and /home are mounted ro and the system is completely unusable till fsck by hand from root. Hint! A root must exist before, cause with ro the user cannot login and "su fcsck" to his partition.

BUG: A fsck must be forced on dirty partitions in all cases. On battery there is no help and solution when a broken machine boots up to what?

[EricDHH (ericdhh)]

Suggestion: To keep the denied fsck feature for ext* we can add a check for the filesystem, then JFS / XFS get always their fsck and ext* will boot dirty. A fsck on ext* took up to an hour, but on JFS / XFS it's been done within seconds. JFS / XFS mount only ro when the filesystem is dirty, ext* runs dirty but got more defects when we force this situation.

[EricDHH (ericdhh)]

At debian this is a CRITICAL bug, cause it can hose a ext* fs completely to work on it at dirty state. With JFS the machine is broken and cause internal knowledge to repair without booting.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526398

Patch or fix needed to save the filesystems.

[Benjamin Mako Hill (mako)]

A number of people here have commented about the particularly bad effects of skipping a fsck on JFS when there is no AC power. In response to this, bug #361023 was marked as a duplicate of this bug. I'm pretty sure that the behavior on JFS is both different and severe enough that they should be treated separately. Even if this bug is not closed, the JFS should be special cased. As a result, I've marked #361023 about JFS as non-duplicate and added more information and a simple patch.

[sumdog (sum-notify)]

I would really like to reiterate that skipping fsck is a bad idea if the file system isn't clean. I'm surprised ext3 lets you mount a dirty file system.

The only exception is XFS (fsck.xfs doesn't do anything except exit(0). XFS runs an fsck each time you mount it. If the journal is damaged, it halts on the mount and tells you to run xfs_repair).

If the file system is damaged, really damaged, I know JFS may take four or five minutes, maybe more, to check the whole file system. I guess ext3 has a better recovery method? I'm not familiar enough with it.

If you really want to go ahead with this, I'd suggest you don't exclude JFS. Instead, exclude ext3. In all cases, run fsck if the file system is dirty *unless* is it one of the designated 'safe to mount dirty' file systems (which to my knowledge is only ext3) and the machine happens to have a battery and it's not on AC power.

I'd like to reiterate that even with ext3, I think this is a bad idea. How do other distributions (openSuse, Fedora, etc.) deal with this situation?

[Ian (superian)]

It's been over a year since I first posted about this and, yes, I still think I am right:

IF this must be the default behaviour, it needs to have a way around it just as the routine 'partition mounted x times check' can be skipped by pressing a key.

[Jort (jort)]

What about adding replacing the "Maximum mount count" with one "Maximum mount count on power" and one "Maximum mount count on battery"? The "on power" could have the same spot as the previous maximum mount count, to be backwards compatible. Then the same for "Next check after".

Then the user could tune it themselves; if the difference between the "power" and "battery" was sufficient, it would be very unlikely to get to the "battery" value - probably a difference of 10 would be enough.

Then, if there are errors on the disk, it would still do a check as normal.

[Phillip Susi (psusi)]

The automatic periodic checks were intentionally suppressed when on battery and were generally an unneeded waste of time, which is why they have now been removed completely. The skip when on battery power also seems to have been removed. If something is actually wrong with your fs, then you should boot into rescue mode and choose the friendly fsck option from the menu, rather than rely on rebooting until the automatic periodic check happens.