Description of problem: This is caused by the fact that kernel in fc6 contains too old fuse module. I don't know if upstream kernel even contains fuse 2.6. The possible solution are as follows: - fall back to older ntfs-3g and wait until 2.6 version gets its way into the kernel - rip the fuse kmod out of kernel and ship it separately (this was discouraged last time I asked in #fedora-extras) Version-Release number of selected component (if applicable): ntfs-3g-0-0.6.20070102.fc6 How reproducible: always Steps to Reproduce: 1. yum update ntfs-3g 2. reboot Actual results: Errors during boot, no ntfs partitions mounted Expected results: Everything works OK. Additional info: Problem is described here: http://ntfs-3g.org/support.html#fuse26
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 :)
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.