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 -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp