https://bugzilla.novell.com/show_bug.cgi?id=300694 Christoph Thiel changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cthiel@novell.com AssignedTo|coolo@novell.com |bk@novell.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=300694#c3 Bernhard Kaindl changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bk@novell.com AssignedTo|bk@novell.com |fehr@novell.com --- Comment #3 from Bernhard Kaindl 2007-08-20 09:49:59 MST --- Hi Thomas, could it be that /mnt/windows/C was only created for vfat and ntfs but not now with ntfs-3g? This bug at least seems to suggest that. I will try to get ntfs-3g changed to mount also volumes which are scheduled for check (but then only mount them read-only, unless -oforce is used), but I do not know whether this will happen and if that will cover all possibilities of a mount of ntfs-3g failing. Thomas, could you either: a) switch back to fstype "ntfs" for ntfs-partitions b) tolerate an error from mounting partitions with ntfs-3g when they are mounted. (Note: ntfs-3g could be used somewhere outside of /mnt/windows, but as ntfs-3g currently same level permission support as FAT (only fixed for whole fs using mount flags), it's not desirable to use it seriously for system files) I think that b) would be most desirable to prevent the complete abort of the installation if an error mounting some windows NTFS partition fails. Having b) implemented after installation, in the installed system may also be desirable because that would allow to set the options, boot into windows, check the filesystem as described by the mount error which yast2 disk shows and boot back into Linux and not having to redo all mount options again. PS: Please remove "nls=utf8" from the ntfs-3g mount flags, it's ignored by ntfs-3g and replaced by the locale=en_US.UTF-8, which you already added. PPS: In bug 293429, coolo suggested to use fmask=133,dmask=022, so these should replace the umask=0002 which is currently in the default options string, because umask=0002 acts very different with ntfs-3g (default permissions are then 775 [rwxrwxr-x] instead of the default of 777, not 555 [r-xr-xr-x] instead of the default of 500 [r-x-------] as it is with ntfs). Having 644 for files and 755 for directories as caused by fmask=133,dmask=022 with ntfs-3g seems more desirable. Coolo also suggested: noauto,user, which I'd second. Then the NTFS windows partitions would not be mounted by default and then any error in mounting NTFS partitions would not occur at boot (or during installation) but when the user really wants to access them. Having many partitions mounted with ntfs-3g can -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=300694#c5 --- Comment #5 from Bernhard Kaindl 2007-08-20 10:20:22 MST --- To continue my last comment: Having mounted many partitions mounted with ntfs-3g may also result in a bit more overhead than the in-kernel ntfs filesystem has because it creates a user space daemon per mount point, but OTOH, mounting my external 750GB Seagate FreeAgent Pro with 30.000 files (38% full) only takes ~150 ms after blockdev --flushbufs while mounting it with the kernel's ntfs takes ~350 ms, so on the time for mounting is lower, but the mount.ntfs-3g daemon shows 15MB VIRT, 1MB RES and 0.5M SHR in top, while after a 'find' over the full disk, it shows 20MB VIRT, 6.5MB RES and a few more K of SHR in top. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=300694 Christoph Thiel changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|fehr@novell.com |bk@novell.com Status|ASSIGNED |NEW -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=300694#c8 Szabolcs Szakacsits changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |szaka@sienet.hu --- Comment #8 from Szabolcs Szakacsits 2007-08-21 05:07:16 MST --- Hi! From NTFS-3G upstream: I think the fundamental problem here is that that the install/boot shouldn't stop if non OS critical file system can't be mounted. That is, trying to make NTFS mounted is not the right approach here, in my opinion. There can be many, different reasons why a file system is unmountable. NTFS-3G has extra sanity checks which are not included in ordinary file system drivers (i.e. it can detect unconfigured, unactivated, not correctly setup RAID, Dynamic Disks, etc). The "unclean volume" error is caused basically always by ntfsresize which is completely safe to ignore. Setting the NTFS volume flag dirty is used as a workaround for partition editors not doing correct NTFS partitioning. So, ntfsresize tricks Windows via the file system to fix the Windows partition, not the file system. The name of the 'force' mount option is also misleading. What it does in real is it ignores the file system dirty flag which was set by ntfsresize (see above) and it fixes/resets the NTFS journal file if needed. It's planned to ignore the otherwise unused "dirty flag" without a warning by default and use a new, more explanatory 'fix' mount option for the second and online repair cases. The driver already fixes silently minor corruptions what other drivers leave behind and this approach will be used more intensively in the future (ZFS also does online fsck, offline fsck is the past). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=300694#c10 --- Comment #10 from Szabolcs Szakacsits 2007-08-21 09:12:55 MST --- Thomas: would you please explain what you mean "ntfs-3g is not compatible with fstab semantics"? I'd really love to help but I seriously don't even understand what this issue has to do with ntfs-3g itself. Wouldn't you also abort if any FAT, ext3, etc partition would fail to mount/fsck? If not then why is NTFS handled differently? (I'm just interested, I've never met such drastic handling of non-critical mount failures.) If a volume is badly corrupted, or doesn't have the file system signature at all (wrong/changed device), or missing an important strip disk from a RAID, or a network server or removable media is not available when configured for boot time mount, etc then no driver can mount those non-existent file systems. Wouldn't it be more productive and user-friendly to continue and investigate/fix these issues when the OS is fully up instead of a total system failure? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=300694#c12 --- Comment #12 from Szabolcs Szakacsits 2007-08-21 10:41:00 MST --- Thanks, I see. You want the driver to mount read-only when the user expects read-write mount but that is refused. I'm sorry but this won't happen. (Of course the driver is yours, and you're encouraged to modify it to your liking.) Here is the current situation: 1. If a user asks read-write mount then he gets read-write mount or error. 2. If a user asks read-only mount then he gets read-only mount or error. If somebody wants to do what you want then he can make a script. Let's suppose now that ntfs-3g would do what you want. Then how would you satisfy people who want case 1? Using an option 'yes-i-really-want-only-read-write'? Isn't the 'rw' option is supposed to do that? The iso9600 case is a bit different, since there isn't read-write mount there. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=300694#c14 Thomas Fehr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |cthiel@novell.com --- Comment #14 from Thomas Fehr 2007-08-21 10:56:16 MST --- Christoph, what should be done? I would suggest to simply go back to old ntfs driver. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=300694#c16 Christoph Thiel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Info Provider|cthiel@novell.com | --- Comment #16 from Christoph Thiel 2007-08-21 11:28:58 MST --- I'd definitely vote/go for Bernhards approach in comment #15. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=300694#c18 --- Comment #18 from Thomas Fehr 2007-08-21 11:41:36 MST --- Maybe best would be to create a boot.ntfs-3g that handles mounting of the ntfs-3g entries from fstab and add a "nontfs-3g" to -t option in boot.localfs. So the handling of ntfs-3g would at least be in a central plase without unnecessary messing up boot.localfs. /etc/init.d/boot.ntfs-3g should then be part of ntfs-3g RPM. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=300694#c20 --- Comment #20 from Bernhard Kaindl 2007-08-21 17:53:58 MST --- Created an attachment (id=158857) --> (https://bugzilla.novell.com/attachment.cgi?id=158857) [PATCH] If the new mount option "rwonly" is not given, automatically fall back to read-only mount if volume is dirty The attached patch implements a new mount option which I called "rwonly", which, if given, disables the fallback to a read-only mount if the volume is dirty and makes mount fail in this case, which is the current behaviour of ntfs-3g. Otherwise, if rwonly is not given, it works like the previous patch, which adds the fall-back to read-only mode if the volume is given (and also allows to manually use the "ro" option to force read-only mode wihtout using force on a dirty volume. This patch does not yet log mount errors to syslog(3), but if any mount error happens during system boot, it is found /var/log/boot.msg: Mounting local file systems... proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) udev on /dev type tmpfs (rw) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) /dev/sda6 on /home type reiserfs (rw) Volume is scheduled for check. Please boot into Windows TWICE, or use the 'force' mount option. For example type on the command line: mount -t ntfs-3g /ntfs.image /media/ntfs -o force Or add the option to the relevant row in the /etc/fstab file: /ntfs.image /media/ntfs ntfs-3g defaults,force 0 0 failed<notice>'boot.localfs start' exits with status 0 <notice>boot.apparmor start Loading AppArmor module done BTW, a colleague told me that hfsplus has already a such fallback from read-write to read-only -- from fs/hfsplus/super.c: if (!(vhdr->attributes & cpu_to_be32(HFSPLUS_VOL_UNMNT))) { printk("hfs: Filesystem was not cleanly unmounted, " "running fsck.hfsplus is recommended. mounting read-only.\n"); sb->s_flags |= MS_RDONLY; } else if (sbi->flags & HFSPLUS_SB_FORCE) { /* nothing */ } else if (vhdr->attributes & cpu_to_be32(HFSPLUS_VOL_SOFTLOCK)) { printk("hfs: Filesystem is marked locked, mounting read-only.\n"); sb->s_flags |= MS_RDONLY; } else if (vhdr->attributes & cpu_to_be32(HFSPLUS_VOL_JOURNALED)) { printk("hfs: write access to a jounaled filesystem is not supported, " "use the force option at your own risk, mounting read-only.\n"); sb->s_flags |= MS_RDONLY; } As Szaka prefers the rw-only behaviour and as I'd find it handy to be able to change the default mount flags of ntfs-3g in system-wide and user-specifc config files, and if he (or we) like the idea, I'd also like to implement those. In Szaka's upstream code, the defaults could then implement rw-only by default and we or other admins could specify e.g. 'mount_dirty_ro' (which is what we want) and e.g. 'fmask=133,dmask=022' using /etc/ntfs3grc (and ~/.ntfs3grc for users which do not like the settings in /etc) so that a user or admin who simply mounts an ntfs-filesystem gets safer defaults than the default 777 permissions and if that would be accepted by Skzaka, we would not have to patch ntfs-3g but only need to provide config files. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=300694#c23 Thomas Fehr changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dkukawka@novell.com --- Comment #23 from Thomas Fehr 2007-08-30 02:52:10 MST --- *** Bug 306029 has been marked as a duplicate of this bug. *** https://bugzilla.novell.com/show_bug.cgi?id=306029 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.