[Bug 531740] Re: Endless fsck/poweroff cycle if mountall-reboot.conf doesn't work correctly

[Daniel Richard G.]

Getting to the point of testing this on the same flaky hardware was a
long story (the laptop is very picky about its power supply, and the
original brick had to be shipped much later than the main unit), but I
finally did so with a fresh install of Oneiric.

This bug is licked. That final sync() makes all the difference. The
laptop still powers off abruptly when Linux attempts to reboot after the
fsck, but now, the changes made by the fsck actually stick.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to mountall in Ubuntu.
https://bugs.launchpad.net/bugs/531740

Title:
  Endless fsck/poweroff cycle if mountall-reboot.conf doesn't work
  correctly

Status in “mountall” package in Ubuntu:
  Fix Released
Status in “mountall” source package in Karmic:
  Invalid

Bug description:
  Binary package hint: mountall

  This concerns mountall 1.0 in Karmic.

  I recently installed Ubuntu Karmic on my aunt's Toshiba Satellite A65,
  a laptop with the bizarre quirk that rebooting doesn't work correctly.
  Instead of rebooting, the system simply powers off. This happens even
  with "reboot=bios" or "reboot=warm,bios" on the kernel command line.
  Ctrl-Alt-Del appears to be the only way to obtain a proper reboot on
  this hardware. (This is the kind of bug that is usually fixed with a
  BIOS update, but Toshiba does not offer a version newer than the one
  already installed.)

  The Ubuntu installation worked flawlessly until a power outage one
  fine day. From then on, it remained largely stuck in the following
  cycle:

  1. Power system on

  2. GRUB menu (hit Enter)

  3. Boot-time filesystem checks (this step often takes *hours* on a
  40GB disk)

  4. **** REBOOT LINUX **** (due to the root filesystem having been
  modified)

  5. System powers off

  6. Goto step 1

  My aunt somehow found that if she forcibly switched off the system
  after some time in step 3, sometimes the subsequent boot would skip
  the filesystem checks, and start up the desktop normally. I have no
  idea why this should work, yet that's what she reported.

  Anyway, when the system came up, I logged in remotely (note that this
  laptop is ~3000 miles away from me, so I'm a bit limited in what I can
  do) and examined the system. One very interesting tidbit in looking at
  the root filesystem's superblock was the mount count---it was thirty-
  something, against a maximum mount count of 23. Almost as if the fsck
  had never run at all... and with the system suddenly powering off when
  it should have rebooted, after the fsck...

  Aha! That had to be the problem. Because the system powered off,
  fsck's last few (and most important) corrective writes to the disk
  must have never made it out of the write cache. And indeed, I looked
  through the mountall package, in particular the mountall-reboot.conf
  file, and didn't see that it was doing any sort of syncing or buffer-
  flushing between the fsck invocation and "reboot -f". So naturally, if
  "reboot -f" is tantamount to pulling the system's power cable, bits
  are going to get dropped. With the end result being an Ubuntu system
  that is very difficult to get up and running.

  So what it comes down to is that there needs to be some
  syncing/flushing going on between the fsck and reboot to ensure that
  fixes to the filesystem are committed to disk, for cases like this
  when the reboot doesn't work as expected.

  (One worrisome thing I found, tangentially related, was in upstart's
  implementation of reboot(8). The man page for the reboot(2) syscall
  states "If not preceded by a sync(2), data will be lost" for
  restart/halt/poweroff, yet not only does reboot(8) not call sync(2), I
  don't see any calls to sync(2) or even sync(1) in all of upstart or
  mountall.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/531740/+subscriptions