kernel-packages team mailing list archive

[Launchpad Bug Tracker <514498@xxxxxxxxxxxxxxxxxx>]

[Expired for linux (Ubuntu) because there has been no activity for 60
days.]

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

-- 
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:
  Expired

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