Description of problem: After this morning's updates, my system failed to boot on the latest kernel (kernel-2.6.29-0.137.rc5.git4.fc11.x86_64) or the previous one (kernel-2.6.29-0.134.rc5.git2.fc11.x86_64). Consistently hung at "Mounting local filesystems:" (see attached photo of screen). After some fear and anxiety, I managed to boot "readonlyroot", remount / "rw", and edit /etc/rc.d/rc.sysinit commenting out the lines that do the "local filesystem mounts". System then booted fine, but it appeared (via "ps algx") that the mount of the ntfs partition was hung. In fact, trying "ls /media/disk" hung the console. I rebooted single user, edited out the /etc/fstab entry, and restored /etc/rc.d/rc.sysinit to its pristine state. Rebooting was fine........ Here is the (now) commented line from /etc/fstab: #LABEL=WinXP /mnt/winXP ntfs-3g defaults 0 0 Now, after the system boots up graphicall, I see the partitions mounted: /dev/sda1 on /media/disk type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096) and can "ls /media/disk" without issue: [tbl@tlondon ~]$ ls /media/disk& [2] 5196 [tbl@tlondon ~]$ AUTOEXEC.BAT hiberfil.sys Program Files boot.ini IO.SYS SWTOOLS Config.Msi MSDOS.SYS System Volume Information CONFIG.SYS NTDETECT.COM TrackitAudit.id Documents and Settings ntldr WINDOWS DRIVERS pagefile.sys [2]+ Done ls --color=auto /media/disk [tbl@tlondon ~]$ I didn't see ntfs-3g updated today.... Version-Release number of selected component (if applicable): kernel-2.6.29-0.134.rc5.git2.fc11.x86_64 kernel-2.6.29-0.124.rc5.fc11.x86_64 ntfs-3g-2009.2.1-2.fc11.x86_64 kernel-2.6.29-0.137.rc5.git4.fc11.x86_64 How reproducible: Freezes every boot. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 332735 [details] photo of screen hanging on boot with ntfs mount in /etc/fstab
If I turn off 'mdmonitor' (via 'chkconfig mdmonitor off'), the system boots just fine with the ntfs-3g partition in /etc/fstab. Moving this from ntfs-3g to mdadm.....
Can you re-enable mdmonitor and see if the problem returns? The reason I ask is because the point at which your machine is hanging is *before* mdmonitor is even started, so whether on or off, if your machine reliably hangs at that point, it's never even running mdmonitor, so one would think that mdmonitor can't be the catalyst to the hang.
Damn. Of course not..... I did 'chkconfig --level 2345 mdmonitor' and rebooted; of course it works now. Not sure what changed. Sigh. This failed every boot (10 times in a row....). Looks like same kernel, same ntfs-3g, same mdadm. So, this froze until I edited these lines from /etc/rc.d/rc.sysinit: # Mount all other filesystems (except for NFS and /proc, which is already # mounted). Contrary to standard usage, # filesystems are NOT unmounted in single user mode. if [ "$READONLY" != "yes" ] ; then action $"Mounting local filesystems: " mount -a -t nonfs,nfs4,smbfs,ncpfs,cifs,gfs,gfs2 -O no_netdev else action $"Mounting local filesystems: " mount -a -n -t nfs4,smbfs,ncpfs,cifs,gfs,gfs2 -O no_netdev fi With these commented, the system booted up to runlevel 3 fine, but something else was mounting the ntfs-3g partition (/dev/sda1) from /etc/fstab: there was an 'ntfs-3g' process running, and an attempt to "ls /mnt/winXP" hung the terminal. I then commented out the line in /etc/fstab and rebooted just fine; /dev/sda1 got mounted just fine as /media/WinXP). I thought I saw an mdadm process in the bootchart, and I saw the thread in fedora-test referring to mdadm, so I turned that off, restored fstab, and the reboot worked just fine (with /dev/sda1 mounted as /mnt/winXP). Sorry for pointing a finger in the wrong direction here.... I remain "dazed and confused"......
This happened again after the "big rawhide update" this past weekend. I recovered as described above, by booting "readonlyroot", remounting / as r/w, and editing out the ntfs mount in /etc/fstab. Since I couldn't localize it further than that, I've continued to boot with that entry commented out. With new devkit-disk, this now mounts when I login, btw.
I can confirm this, the same happens here. This is my fstab: /dev/vg0/fedora / ext4 defaults 1 1 /dev/vg0/scratch /scratch ext3 defaults 1 2 /dev/vg0/data /home ext3 defaults 1 2 /dev/vg0/games /games ext3 defaults 1 2 /dev/vg0/music /mnt/music ext3 defaults 1 2 UUID=6a780285-f5e7-492b-b5ba-2ce7774b1534 /boot ext3 defaults 1 2 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 UUID=bcd904af-68f5-4dcf-95c6-99ee989bb809 swap swap defaults 0 0 /dev/mapper/isw_bgjcdcfheh_volume0p1 /mnt/windows/C ntfs-3g defaults 0 0 /dev/mapper/isw_bgjcdcfheh_volume0p2 /mnt/windows/Games ntfs-3g defaults 0 0 /dev/mapper/isw_bgjcdcfheh_volume0p3 /mnt/windows/Stuff ntfs-3g defaults 0 0 The boot also hangs at "Mounting local file systems:". After that message a warning "All config files need .conf: /etc/modprobe.d/floppy-pnp" is printed for every file under /etc/modprobe.d/ . Then the system stays dead. In this state even Control-Alt-Backspace is not able to reboot the system. If I change to nfts-3g entries in /etc/fstab to "noauto" the system boots fine. My NTFS partitions are on a dmraid managed raid0. Mounting them after the system has been fully booted works fine. Another interesting thing: If I initiate a full relabeling of the filesystems (i.e. touching /.autorelabel) the system boots fine too and mounts the ntfs paritions during boot without problems. The next boot will hang again (unless initiating another relabeling or changing the nfts fstab-entries to noauto) This is with current rawhide: ntfs-3g-2009.2.1-3.fc11.x86_64 kernel-2.6.29-0.258.rc8.git2.fc11.x86_64 dmraid-1.0.0.rc15-6.fc11.x86_64
Hmmm. Does booting with selinux in permissive get it working again? I'm wondering if this is an SELinux issue. I'm trying to reproduce this on my end, but at the moment, I only have a file mount in /etc/fstab as opposed to a partition mount, and I can't seem to trigger any lockups. There is a new ntfs-3g as well, but they don't list anything in the changelog that leads me to believe that it would resolve this... I'm going to push it anyways because the other fixes are useful, but I didn't want anyone to think I had forgotten about this bug.
Nope. Freezes for me both with and without "enforcing=0". Here is my /etc/fstab when it boots: [tbl@tlondon ~]$ cat /etc/fstab # # /etc/fstab # Created by anaconda on Fri Oct 17 14:03:24 2008 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or vol_id(8) for more info # /dev/VolGroup00/LogVol00 / ext3 defaults,noatime,nodiratime 1 1 UUID=27db997b-1bda-4e46-8a89-ae5159412a00 /boot ext3 defaults,noatime,nodiratime 1 2 tmpfs /dev/shm tmpfs defaults 0 0 tmpfs /tmp tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 /dev/VolGroup00/LogVol01 swap swap defaults 0 0 #LABEL=WinXP /mnt/winXP ntfs-3g defaults 0 0 #LABEL=extra /mnt/extra ext3 defaults,noatime,nodiratime 0 0 #/mnt/extra/tbl /home/tbl/Music/more none defaults,bind 0 0 [tbl@tlondon ~]$ Deleting the '#' on the line starting with "LABEL=WinXP" makes it freeze. I can "recover" by booting with "readonlyroot s", and then remounting / with "mount -o remount,rw /", and then editing /etc/fstab to put the '#' back in. I'm running latest rawhide with an encrypted root partition (I guess swap too). Froze 4 or 5 consecutive times....
Try updating to this: http://kojipkgs.fedoraproject.org/packages/ntfs-3g/2009.3.8/1.fc11/x86_64/ntfs-3g-2009.3.8-1.fc11.x86_64.rpm See if it makes any difference? Also, try changing it to mount by /dev/foo rather than by label? Admittedly, I'm making guesses in the dark here. When I get back into the office next week, I'm going to reinstall a system with an NTFS partition (rather than a file). e.g. /home/spot/cvs/ntfs-3g/devel/ntfs.img /mnt/ntfs ntfs-3g defaults 0 0
Created attachment 336928 [details] screenshot of boot freeze with ntfs-3g mount Nope... ntfs-3g-2009.3.8-1.fc11.x86_64 freezes too. But, I did get some red "FAILED" indications on the screen. Sorry for the blurry picture. Believe the error messages says: mount: devpts already mounted, or /dev/pts is busy. Not sure why it appeared twice. Restoring the comment to the /etc/fstab line restores booting (and removes the devpts error message). I'll try changing the mount from a "label mount" to a partition mount next.
Well, a "partition mount" appears to work (at least once!). Booted up in SELinux enforcing mode. I did however notice a few "new" AVCs, the first that came out as or before udev started: Mar 26 17:15:39 tlondon kernel: mount used greatest stack depth: 3088 bytes left Mar 26 17:15:39 tlondon kernel: type=1400 audit(1238112926.206:4): avc: denied { read } for pid=973 comm="dmesg" name="ld.so.cache" dev=dm-1 ino=28009 scontext=system_u:system_r:dmesg_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file Mar 26 17:15:39 tlondon kernel: udev: starting version 139 Here is the second: Mar 26 17:15:39 tlondon kernel: Adding 4063224k swap on /dev/mapper/VolGroup00-LogVol01. Priority:-1 extents:1 across:4063224k Mar 26 17:15:39 tlondon kernel: type=1400 audit(1238112936.209:5): avc: denied { read } for pid=2129 comm="dmesg" name="ld.so.cache" dev=dm-1 ino=28009 scontext=system_u:system_r:dmesg_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file Mar 26 17:15:39 tlondon kernel: platform microcode: firmware: requesting intel-ucode/06-17-06 and the third: Mar 26 17:15:39 tlondon kernel: Microcode Update Driver: v2.00 <tigran.co.uk>, Peter Oruba Mar 26 17:15:39 tlondon kernel: type=1400 audit(1238112936.713:6): avc: denied { read } for pid=2191 comm="microcode_ctl" name="ld.so.cache" dev=dm-1 ino=28009 scontext=system_u:system_r:cpucontrol_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file Mar 26 17:15:39 tlondon kernel: Microcode Update Driver: v2.00 removed. Notwithstanding, system booted and ntfs-3g mounted the fs: [root@tlondon ~]# ls /mnt/winXP 73b7774c2054f88ef458b8e2 DRIVERS pagefile.sys AUTOEXEC.BAT hiberfil.sys Program Files boot.ini IO.SYS SWTOOLS Config.Msi MSDOS.SYS System Volume Information CONFIG.SYS NTDETECT.COM TrackitAudit.id Documents and Settings ntldr WINDOWS [root@tlondon ~]# This helpful?
I don't think the audit messages have anything to do with the lockup. How did you label the ntfs filesystem? Did windows do that? I'm not sure why it tries to mount devpts twice. Something very strange is happening here.
Hello, we had the same issue on Mandriva but could not often reproduce it. It was triggered by readahead-collector enabling audit. I can now easily trigger it with : auditctl -e 1 auditctl -w /etc mount /dev/sda1 /mnt/windows
Interesting..... Well, in (partial?) support of #13, I just got a freeze with a "partition mount" too, so the issue must be something "underlying".
I think I understood the problem and sent the explanation upstream mount.ntfs-3g calls mount to update mtab mount does readlink on mountpoint and when audit is enabled this leads to a fuse request which hangs because mount.ntfs-3g can't reply as it is waiting for mount to return mount S 00004cca 0 11821 11819 c3401dcc 00200082 00004cca 00004cca c3401d7c c0134709 00200086 386e9131 000003e1 00004cca dfb8d540 dfb5a000 c05ebcd9 c05b7380 df88a490 df88a6f0 c1409380 00000000 00000000 38734404 000003e1 c3401db0 c3401da8 df88a6f0 Call Trace: [<c0134709>] ? release_console_sem+0x199/0x1e0 [<c014934a>] ? prepare_to_wait+0x3a/0x70 [<e0d4a77c>] wait_answer_interruptible+0x6c/0xa0 [fuse] [<c01490f0>] ? autoremove_wake_function+0x0/0x50 [<e0d4a9f1>] fuse_request_send+0x181/0x250 [fuse] [<e0d4bba5>] ? fuse_get_req+0xc5/0x120 [fuse] [<e0d4c403>] fuse_getxattr+0xe3/0x140 [fuse] [<e0d4c320>] ? fuse_getxattr+0x0/0x140 [fuse] [<c022d940>] get_vfs_caps_from_disk+0x60/0xe0 [<c01ba5eb>] ? __link_path_walk+0x26b/0xd70 [<c016cfa7>] audit_copy_inode+0x77/0xb0 [<c016d410>] __audit_inode+0xf0/0x280 [<c01bb4da>] do_path_lookup+0x13a/0x1a0 [<c01bc0aa>] user_path_at+0x4a/0x80 [<c01c770d>] ? mntput_no_expire+0x1d/0x140 [<c01c770d>] ? mntput_no_expire+0x1d/0x140 [<c01b45fe>] sys_readlinkat+0x2e/0x90 [<c01b4687>] sys_readlink+0x27/0x30 [<c0103fdb>] sysenter_do_call+0x12/0x2f [<c03a0000>] ? serial_pnp_probe+0xb0/0x240
The new ntfs-3g package from comment #9 doesn't change here anything too. I am also able to trigger a mount-freeze with the commands from comment #13.
Pascal, thanks for the great information. Did you hear anything back from upstream?
Upstream is still discussing the issue with FUSE. We would like to know why /etc/mtab update needs readlink(mountpoint)? Perhaps mount(8) shouldn't do it for /etc/mtab update. Where could I find the used util-linux-ng mount(8) source code (and all the applied patches)? The long term solution would be to symlink /etc/mtab to /proc/mounts. There are kernel patches for this for years. Temporary workaround could be compiling ntfs-3g with ./configure --disable-mtab, or patch ntfs-3g not to wait for /bin/mount -i to return. We are still investigating the later solution (e.g. should an mtab update problem result umount(2) or not?).
You may consider the below patch as a better temporary workaround: http://ntfs-3g.org/download/mount-readlink-hang-workaround.diff It should be used with internal fuse-lite (default) and no --disable-mtab option. --disable-mtab breaks too many things (df, mount, etc).
ntfs-3g-2009.3.8-2.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/ntfs-3g-2009.3.8-2.fc9
ntfs-3g-2009.3.8-2.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/ntfs-3g-2009.3.8-2.fc10
Here is a testing update with that patch attached, please test it out: Fedora 9: https://admin.fedoraproject.org/updates/ntfs-3g-2009.3.8-2.fc9 Fedora 10: https://admin.fedoraproject.org/updates/ntfs-3g-2009.3.8-2.fc10 Rawhide: http://koji.fedoraproject.org/koji/buildinfo?buildID=95884
ntfs-3g-2009.3.8-2.fc11.x86_64 "works for me" (did not freeze boot, at least a couple of times).....
Works here too, tested ntfs-3g-2009.3.8-2.fc11.x86_64.rpm on current rawhide. Thanks.
Closing this as fixed in rawhide.
ntfs-3g-2009.4.4-1.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/ntfs-3g-2009.4.4-1.fc9
ntfs-3g-2009.4.4-1.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/ntfs-3g-2009.4.4-1.fc10
ntfs-3g-2009.4.4-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
ntfs-3g-2009.4.4-1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.