← Back to team overview

touch-packages team mailing list archive

[Bug 1375640] Re: fsck should do some sanity checks to avoid damaging an ext3/ext4 file system

 

You're jumping to conclusions here that the damage was caused by the
lack of "-t ext4" to fsck.  #1, the fsck program will determine the file
system type based on the file system type found in /etc/fstab.   So if
the /etc/fstab file indicates that you were using ext4, then it wlil do
the equivalent of running "fsck -t ext4".    #2, even if that was wrong,
all that would have happened was the wrong fsck program would have been
called.  If it was really a btrfs or xfs file system, it would have run
fsck.btrfs or fsck.xfs, and they would have rejected the file system as
not a btrfs or xfs.    If the /etc/fstab wrongly thought it was a ext2
or ext3, then fsck would have run /sbin/fsck.ext2 or /sbin/fsck.ext3 ---
but /sbin/fsck.ext* are all symlinks to the same program, /sbin/e2fsck.
So it wouldn't have made a difference.

So the "severe file system damage" had nothing to do with the use or
lack thereof of "-t ext4", but rather because the file system was badly
damaged by the Nvidia-induced crash.   If the closed source kernel
module managed to scribble on kernel memory, it could have caused
metadata blocks to be written to the wrong place on disk, or corrupting
critical metadata blocks.  Or if you had to hard power cycle the system,
and you were using a SSD that doesn't have power fail protection (most
consumer grade SSD's don't), then that might also explain the severe
file system corruption.

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


References