Description of problem: The version of fsck.ext4 / e2fsprogs shipped with fedora ( e2fsprogs-libs-1.42.13-4 ) does not support checking ext4 filesystems created with the now default metadata_csum flag in 1.43 Version-Release number of selected component (if applicable): e2fsprogs-libs-1.42.13-4 How reproducible: Create a ext4 filesystem on a device i.e (mkfs.ext4 /dev/sda1 ) with e2fsprogs >= 1.43 (default in several distros) Attempt to run fsck on the newly created partition i.e ( fsck /dev/sda1 ) Actual results: [aenertia@localhost ~]$ fsck /dev/sdb2 fsck from util-linux 2.28 e2fsck 1.42.13 (17-May-2015) fsck.ext2: Permission denied while trying to open /dev/sdb2 You must have r/w access to the filesystem or be root [aenertia@localhost ~]$ Expected results: fsck run succesfully on the ext4 filesystem Additional info: Upgrade/backport 1.43 version of e2fsprogs to fedora 24
edit - output as root is : [aenertia@localhost ~]$ sudo fsck /dev/sdb2 [sudo] password for aenertia: fsck from util-linux 2.28 e2fsck 1.42.13 (17-May-2015) /dev/sdb2 has unsupported feature(s): metadata_csum e2fsck: Get a newer version of e2fsck! [aenertia@localhost ~]$
Why did you use a version of e2fsprogs which was not shipped with the OS? If you use utilities not shipped by the OS to create a filesystem, I do not think you should be surprised if the (older) stock tools are unable to handle it. Now that you are in this unsupported configuration, I would suggest getting the src.rpm from Rawhide, building, and installing it. But this is not a bug in e2fsprogs or in Fedora 24; you made an administrative choice to use un-shipped tools, and so you get to keep any broken pieces that may result...
Further, e2fsprogs-1.43 was a huge change: $ git log --oneline v1.42.13..v1.43 | wc -l 731 I'm not going to rebase in Fedora 24 just for kicks; if you need to be able to handle newer filesystems created on newer distros, you'll need to use a newer distro (f25), or manage things on your own.
I accept your decsion. But bare in mind that it is quite common to need to support filesystems that were not created with the distro. Several examples come to mind including virtual machine images, external storage, or Dual boot. If it were for a less popular filesystem I would agree entirely; however ext4 is the goto for most desktop and virt-image builders. I remember having a similar discussion several years ago with Theodore Tso at a Linuxconf, during the ext3-4 transition. Certainly Tso's thoughts are that Distro's should keep core utilities as current against core-utilities so long as they are in a support cycle. I tend to agree.
I'm sorry, but I am unwilling to fundamentally change a critical path administrative tool for all users in the middle of the F24 release. As far as I know, there is not yet any released major distribution which ships e2fsprogs-1.43; F25 and the next Ubuntu release will both do so towards the end of this year. F24 is not the proper testing vehicle for e2fsprogs-1.43. I have no doubt that Ted would love to see the very latest bits everywhere, but he is not the Fedora maintainer. I have to balance features with stability. If you wish to use bleeding-edge filesystem formats under F24, you have at least 2 options: 1) Get the rawhide e2fsprogs srpm, build it, and install it on your system 2) Check out the e2fsprogs git tree, build it, and run tools from it -Eric