Bug 221420

This is a kernel issue, really. Its not ntfs-3g's fault that we're shipping an
old fuse kernel module.

That's as maybe, but blindly packaging a new version of ntfs-3g wasn't very
helpful. The right thing to do is to revert to an older ntfs-3g until the kernel
packages catch up with the fuse module, surely?

agreed.  ntfs-3g jumped the gun. +1 for reverting to older build.

It's somewhat sad that this clearly wasn't even tested before it was pushed to
the extras repository.

It wasn't done entirely blind. Multiple people requested it be updated, in
bugzilla and in private emails. I checked the requirements (listed Fuse 2.6.0,
FE has 2.6.1). I was unaware that there was a major API break in the kernel
module and that FC-5/FC-6 didn't have a recent enough version.

I didn't catch this because I was running rawhide.

Nevertheless, I've reverted to the old ntfs-3g package in FC-5/FC-6 and have
bumped epoch to ensure everyone goes backwards. Working and buggy is better than
not working, I suppose. I'd still like to see a kernel update for FC-5/FC-6
which has a new enough Fuse for ntfs-3g current.

Pardon me,
but exporting in fuse's rpm the kernel/ dir of fuse tarball in
/usr/share/doc/<fuse....>/ and patching its configure to put fuse.ko in 
/lib/modules/`uname -r`/updates/ is NOT A Good Thing(tm) ?

or better update in-kernel fuse module with an external patch ?

The current FUSE kernel module always does lazy unmount unconditionally. This
can have a serious consequence regards to the data consistency of block device
based filesystems (I'm aware of only ntfs-3g and zfs) because the user space
processes don't have enough time to close the mounted device safely and sync all
[meta]data in certain circumstances (e.g. when the device physically detached
right after 'umount'). 

The fix is available only in the FUSE 2.6.[01] kernel modules that's why ntfs-3g
requires it (the fix was the new API). Unfortunately no workaround is possible
in ntfs-3g, the only possible fix is the requirement of FUSE 2.6.[01] kernel
module. All ntfs-3g releases which don't use the safe FUSE kernel module are
unsafe and subject to data loss after umounts (the risk is small but it's there
and the result can be serious).

The new FUSE kernel code is included in the kernel since version 2.6.20-rc1 but
the FUSE kernel module in the FUSE 2.6.x packages should work with kernels 2.6.9
and up and it must be backward compatible with all other FUSE filesystems. This
approach worked for users who replaced their vanilla FUSE kernel module. 

I also think the in-kernel solution is the better approach.

Why don't you move fuse kernel module from kernel rpm to fuse rpm? I did so in my 
assemble and now I can update kernel or fuse independently of one another. There 
appears problem of kernel updates, but as a temporary fix it's OK. Mine fuse 
src.rpm avaliable here: http://marush.com/?action=download&file_id=29

(In reply to comment #7)
> Why don't you move fuse kernel module from kernel rpm to fuse rpm? 

when updates the kernel ( kmod-version dont matchs) and thus you must rebuild
fuse module for new kernel version.

For that I in #5 suggest to move kernel/ subdir in a %doc section.  

I was bit by this, too.  This is a painful one because ntfs-3g seems to have
become the preferred method of ntfs access in FC6.  Updates that break
filesystem access can be especially painful.

Tom, can you add a comment explaining the best workaround for this?  Perhaps a
link that points to the downlevel RPMs so that people can get their systems
working again until the appropriate new kernel appears?  Or maybe there is a
clever yum command that will do the needed work?

A kernel with the needed fix in it could be several weeks out, correct?

I pushed new ntfs-3g packages for FC-5 and FC-6 that revert to the previous
build. They have epoch bumped, so they should go in and replace the "new, but
broken" ntfs-3g I pushed previously. As soon as someone signs and pushes the new
packages to the repository, it will be fixed with a simple:

yum update ntfs-3g

(In reply to comment #10)
> I pushed new ntfs-3g packages for FC-5 and FC-6 that revert to the previous
> build. They have epoch bumped, so they should go in and replace the "new, but
> broken" ntfs-3g I pushed previously. As soon as someone signs and pushes the new
> packages to the repository, it will be fixed with a simple:
> 
> yum update ntfs-3g

In the meantime (the new package has not hit the extra repository as of this
moment):

yum remove ntfs-3g

yum install yum-utils

yumdownloader ntfs-3g-0-0.5.20070920.fc6

rpm -Uhv ntfs-3g-0-0.5.20070920.fc6.i386.rpm

yum list ntfs-3g





Cheers,

Panajev

Downgrade dont prevent the bug(see the first paragraph of #6. ) to hit.

Fuse 2.6.1 make  only a more loudly warning about on it.


 

The another option is leaving the previous kernel (I mean version with 2868) and
waiting for the new release. I was wondering when Red Hat is gonna fix this
SElinux bug related to ntfs-g and fuse kernel mdule. The sooner the better :) 

The another option is leaving the previous kernel (I mean version with 2868) and
waiting for the new release. I was wondering when Red Hat is gonna fix this
SElinux bug related to ntfs-g and fuse kernel mdule. The sooner the better :) 

another is an hotfix: 
release a kernel-2870 == kernel-2869 (from updates-testing) plus a
fuse-kernel-2.6.20-rc* backport patch

(In reply to comment #12)
> Downgrade dont prevent the bug(see the first paragraph of #6. ) to hit.
> 
> Fuse 2.6.1 make  only a more loudly warning about on it.
> 
> 
>  

Not to me and I had everything else updated (including FUSE) and downgrading
back to the older ntfs-3g module WAS fixing my problem.

I apologize, I read the reply #6 better and noticed the "bug" better, it can be
quite dangerous indeed. In my case after the downgrade ntfs-3g was able to mount
XP partitions and Vista partitions normally without any FUSE complaint.

Still, now that I have the bug well in mind I think I will stop using the module
until a new FUSE kernel module is released.

Bad approach or safe approach ?

> I was wondering when Red Hat is gonna fix this SElinux bug
> related to ntfs-g and fuse kernel mdule. The sooner the better :)

It's already fixed, please update your selinux-policy package.

Paulo Cavalcanti submitted a kmdl-enriched fuse rpm to ATrpms. It is exactly
identical to the one in Fedora Extras, but builds kmdls and pulls them in
automagically. For myself it's a concept of proof (I'm not an ntfs user) on kmdl
methology (and propaganda thereof), but Paulo did it for fixing this bug until
the kernel catches up.

The packages are in ATrpms' testing repo. As a side-effect you can also have
fuse for RHEL4 and RHEL5 (perhaps RHEL3, too), as well as freshened up fuse user
& kernel module for FC5.

Important note: Dave Jones and other kernel developers in RH/Fedora will hate
you rightfully if you file bugs to this bugzilla with kmdls installed - only
file bugs here that are really against the kernel rpm in question, e.g. no fuse
kmdl, no nvidia kmdls and so on.

OK, reverting update has been pushed to mirrors. So shall this bug remain open
until 2.6.20 or an appropriate backport makes its way into fc6, or rather closed?

2.6.20 will reach FC6 a week or so after its upstream release.  Given where it
is currently in the rc stage, I'd guesstimate that we're looking at about a
month away.