kernel-packages team mailing list archive

["Christopher M. Penalver" <christopher.m.penalver@xxxxxxxxx>]

Martin Erik Werner, this bug was reported a while ago and there hasn't
been any activity in it recently. We were wondering if this is still an
issue? If so, could you please test for this with the latest development
release of Ubuntu? ISO images are available from
http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in
the development release from a Terminal
(Applications->Accessories->Terminal), as it will automatically gather
and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's
Status as Confirmed. Please let us know your results. Thank you for your
understanding.

** Changed in: linux (Ubuntu)
       Status: Triaged => Incomplete

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/514498

Title:
  whole filesystem lost to corruption

Status in “linux” package in Ubuntu:
  Incomplete

Bug description:
  Ubuntu 9.04
  kernel 2.6.28-17-generic
  EXT4 on /dev/sda5 ("logical" partition)

  PROBLEM
  when running "fsck -fy" on ext4 filesystem _whole_ structure was lost, corrupted, disorganized and placed in /lost+found.

  BACKGROUND
  I have experienced several hiccups during a longer period where I've been required to manually fsck -f(y) from the maintenance shell invoked on normal boot after automatic fsck failed. So far this has only resulted in an occasional lost file, and the system working apparently fine after manual fsck and reboot.

  Also possibly relevant is that I've had two or three recent hard
  poweroffs due to power loss, but afaik, I have fsck:d succesfully
  after these occasions and am unsure if these would be the cause of
  this particular problem.

  CURRENT
  I have a filesystem which is one single lost+found folder, whose size is 5GB (which is somewhat less than the total amount of data on the original FS).
  It is still possible to extract some data from the contents of lost+found but it is heavily disorganized/corrupted.
  ##
  Example is a (toy) script which was formerly located at /home/mw/scripts/urandom_hex_matrix.bash :
  Currently there is a file "/lost+found/#9601/bounce.5.gz/stock_mail-import.png/urandom_hex_matrix.bash" However this file is mostly binary gibberish.
  If greping for a known string from the script it appears that the contents of the file "/lost+found/#6660/Nauru" is that of the original script.
  Needless to say, everything is a complete mess.
  ##

  "LOGS"
  I've been using grep*1 in a hunt for fsck logs and have found at least something, I have 8 files with contents which *resembles* fsck output [attached], however, these are all corrupted to varying degrees of unreadable.

  *1 Command used: « find . | xargs grep 2>/dev/null -l -a non-
  contiguous | xargs grep -l -a fsck » (It _worked_, I don't claim it's
  efficient)

  ----

  I take it that the filesystem is pretty much unrecoverable (fortunately not a huge problem in my case).
  But Is there something else I should try to scavange from the remnants, before wiping the system, to possibly find the initial cause? If so, which strings should I feed to grep in order to distinguish these files?

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