touch-packages team mailing list archive

[Theodore Ts'o <tytso@xxxxxxx>]

1)  e2fsck (which is what fsck.ext[234] is hard linked to) is designed
to be safe when getting interrupted by ^C

2)  The all kernel code uses the same address space.   So if there is a
wild pointer in the Nvidia driver scribbles on random kernel memory,
literally anything can happen.  There is a reason why upstream kerenl
developers will generally refuse to debug a kernel crash where the
kernel is "tainted" by using a proprietary closed source kernel module.
The kernel oops has a taint flag specifically because buggy video
drivers in particular have historically been responsible for a huge
number of failures that were at first not obviously related to the video
driver, and upstream kernel developers wasted a lot of time before
concluding: try again without any closed source modules loaded; we
refuse to debug a tainted kernel.

And before you ask why not put the Nvidia driver in a separate address
space --- Microsoft tried this a long time ago with the version of
Windows NT --- and the resulting video performance was sooooo awful that
the first version of Windows NT was a complete failure, and they had to
reverse course and allow video drivers to run in the same address space.
Linux cares about performance as well, and besides, we have zero
interest in enabling crappy closed-source drivers, especially those from
video card companies.   Personally, I use laptops with Intel video
chips, since that allows me to use 100% open source kernel.

3)   It may be possible to recover the data by using e2fsck and debugfs,
if you can find someone with ext4 skills who is willing to give you some
free consulting time.    Alternatively, you can try using photorec,
which is one of the better tools for scanning the raw partition and
finding and recongizing various data formats.  It was originally
designed to find image files (hence photorec), but it has since been
extended to support a huge number of document types, including
Libreoffice, Microsoft Office, etc., etc.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1375640

Title:
  fsck should do some sanity checks to avoid damaging an ext3/ext4 file
  system

Status in “e2fsprogs” package in Ubuntu:
  New

Bug description:
  After some crashes due to a broken nvidia driver, the system didn't boot and presented me a shell to manually repair the file system.
  Then I didn't think and typed fsck without the -t ext4 parameter and the program asked me many questions, if I want to fix something which I answered with y.
  After some time I remembered, that I forgot to specify the -t ext4 parameter, but the filesystem was broken already, so it was already too late, when I do Ctrl-C.
  And I didn't think about that there could be already severe file system corruption, making the things even worse.

  Thus I would recommend that a warning message is displayed, when calling fsck manually with the wrong filesystem type.
  Also a big note that this is now the right time to make an image backup of the disk could be helpful for people like me that always tell other people how important backups are before working on something, but sometimes fail to make one, because they forget to turn their brain on before starting work. ;-)

  I would expect that when calling fsck on a filesystem, not just defaults are used, but the filesystem type is determined.
  Then a big scary warning message should say something like this:

  "
  You have called fsck on an ext4 filesystem. 
  For an ext4 file system you *must* specify the filesystem type with option "-t ext4", otherwise severe damage to the file system will occur.
  NOTE: It is highly recommended that you make a backup image of your disk device before you continue, so that you have something to recover from, if things go wrong. 
  This can be especially important, if the disk drive hardware you are trying to recover the filesystem on, is possibly dying.
  You can use dd_rescue or similar tools to try to get a disk image to recover as much as possible of your data from a damaged hard drive.

  Are you really sure, you want to continue (and probably damage the file system)? (yes/NO)
  "

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