search

matt-wu / Ext3Fsd

Ext2/3/4 file system driver for Windows
http://www.ext2fsd.com
710 stars 106 forks source link

Will cause Ubuntu boot error #6

Open qakcn opened 7 years ago

qakcn commented 7 years ago

I have Windows 10 installed on sda2, Ubuntu installed on sda3 (ext4 filesystem). sda1 is EFI partition. After I ran ext2fsd on Windows, mounting or not, it caused Ubuntu boot error. It says superblock error. I need to run e2fsck -b 32768 \dev\sda3 to fix it. Please help this.

jonaslb commented 7 years ago

I ran into this issue as well with the 0.69 "devel" version on an ext4 filesystem (unlike OP it was a separate harddrive though). I guess the really interesting part is that this bug occurs no matter if the drive has been mounted or not, as long as Windows was started (uninstalling ext2fsd works though). The fsck output is

ext2fs_open2: Superblock checksum does not match superblock
fsck.ext4: Superblock invalid, trying backup blocks...
<partitionlabel> was not cleanly unmounted, check forced.

Followed by a gazillion lines about inodes, groups etcetera being fixed.

jerekupari commented 7 years ago

Me too. I also had this problem with Windows 10 and ext4, when using ext2mgr. Possible workarounds:

Let me try to remember what I did and what happened.

New Thinkpad T560 with a 500G ssd. Ext2fsd 0.68 Partitions (GPT) are in this order on the disk:

  1. sda1 some small system partition for windows
  2. sda2 efi
  3. sda3 Windows 10 Home 64bit C:
  4. sda7 /home ext3
  5. sda6 ubuntu swap
  6. sda5 Ubuntu 16.10 / ext4
  7. sda4 lenovo recovery

(Note: sda4-sda7 are in reverse order on the disk.)

I never mounted the ext4-partition in ext2fsd, but that is the one that got the superblock checksum issue. The home partition (ext3) I mounted in Windows and it worked fine.

When I first installed ext2fsd it worked and read the sda7, but the next reboot into windows got stuck in a black screen that I had to kill with the power switch. Then I tried to boot ubuntu and it had this superblock issue ending up in BusyBox. After rebooting from that, Windows booted ok and the sda7 mount worked fine, I did not start ext2mgr. Everything now worked, Windows and linux booted and the ext3 partition was visible in Windows.

Later I again started ext2mgr, and again it broke the sda5 superblock. Maybe I could next try to start the ext2mgr without doing any changes in it and see what happens.

ngkaho1234 commented 7 years ago

Hi, Could you provide the output when running the following command? on Linux: $ debugfs -R "stats" BLOCK_DEVICE_PATH on Windows (with administator priviledge): debugfs -R "stats" DRIVE_LETTER:

Cheers, Kaho Ng

jerekupari commented 7 years ago

Here they are, in Windows the command just got stuck after printing its version. But I can read the file system in explorer just fine and even opened some files. linux-debugfs-stats.txt win-debugfs-stats-stuck.txt

ngkaho1234 commented 7 years ago

@jerekupari After taking a look at the e2fsprogs package provided in Ubuntu yakkety, it seems that e2fsprogs in Ubuntu is patched to enable metadata_csum. As it is unsupported in Ext2Fsd currently, that eventually causes the issue. In such case, filesystem(with metadata_csum) touched by Ext2Fsd will still passes metadata tests in e2fsck, but fsck is required to recalculate metadata checksum. We are going to work on a fix/solution for that problem.

EDIT: word choices...

piranna commented 7 years ago

Problem is related to Ubuntu 16.10 started to create new EXT4 partitions with the 64bits and metadata_csum flags enabled by default. One solution is to disable them on the filesystem themselves, but point is Ext2fsd should add support for this flags, so it doesn't corrupt the Ext4 partitions...

davidfoerster commented 7 years ago

As long as Ext2Fsd doesn't support these features, at the very least it should not modify these partitions without a big warning sign and explicit user consent to a possible data corruption. Mount them read-only or refuse to mount them at all otherwise.

humanfactors commented 7 years ago

Is there any hope for data recovery? I'm completely outraged that this occured.

For some of my drives, a call to sudo fsck.ext4 -v /dev/X fixed the issues. However, this was a completely insane bug and this is dangerous software!

piranna commented 7 years ago

Can someone send a pull-request fixing this?

ngkaho1234 commented 7 years ago

The latest commit should reject attempts to mount an EXT4 filesystem with unsupported INCOMPAT features, while preventing the user from writing to a filesystem with unsupported RO_COMPAT features (metadata_csum in this case).

EDIT: uploaded a zip package containing test-signed kernel modules built against https://github.com/matt-wu/Ext3Fsd/commit/b7657e58d1cf6347ac711cc0136f0c22a29cb1b1 for both AMD64 and i386 architecture. In order to use them, enable test signing mode by following the guide https://docs.microsoft.com/en-us/windows-hardware/drivers/install/the-testsigning-boot-configuration-option , and replace the kernel modules (in safe mode) in %SYSTEMROOT%\system32\drivers . ext2fsd.zip

jerekupari commented 7 years ago

The new 0.69 release fixes all the problems I have mentioned in this issue. Thanks a lot!

(I'm sorry I never found the time to go through the test-signing boot thing.)

akupac commented 6 years ago

Problem is related to Ubuntu 16.10 started to create new EXT4 partitions with the 64bits and metadata_csum flags enabled by default. One solution is to disable them on the filesystem themselves, but point is Ext2fsd should add support for this flags, so it doesn't corrupt the Ext4 partitions...

Same here with latest Debian 9 and Windows 8.1 and Ext2fs 0.69. First couldn't even read the partition. Mounted, but didn't recognize the filesystem, asking to format.

Solved with tune2fs -O ^metadata_csum,^64bit /dev/sdX