On Tue, Mar 3, 2015 at 11:04 AM, Jeff Sadowski <jeff.sadowski@xxxxxxxxx> wrote: > On Tue, Mar 3, 2015 at 5:36 AM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: >> On Mon, Mar 2, 2015 at 4:35 PM, Jeff Sadowski <jeff.sadowski@xxxxxxxxx> wrote: >>> I was wondering why only ntfs-3g method of mounting ntfs partitions is >>> all that is supported? >>> >>> If the ntfs kernel module was build then it would be all that should >>> be needed to boot from an ntfs partition. >> >> We don't enable it because it isn't a robust driver and ntfs-3g >> provides better support. There may also be legal issues but if there >> are I'm completely unaware of them. It has been disabled in Fedora >> for a very very long time. >> > > ntfs-3g provides better write support that is for sure. From what I had been > reading the read only support for the kernel module was complete and very > robust but we all know how people like to hype things up. It comes with the > linux kernel so the same licencing of the rest of the kernel. Legal issues don't always involve licenses. >>> You could use the read only during the boot up procedure and remount >>> it with ntfs-3g when booted. >> >> Your question is kind of confusing. Why would you have an ntfs >> partition with the contents of a linux root filesystem on it? >> Virtually all uses of ntfs I have seen are for a common data >> partition, not an actual system partition. >> > > There are people wanting to build the the installer/live image on an already > formatted ntfs thumb drive because of how the livecd/installer works from > a cd image it could be left read only all the time. More to get the squash > image it loads from the LiveOS directory But why? What does that gain anyone, aside from skipping a format step of the device? The data on the USB key would still be destroyed and you're left with something that boots Linux that has no practical advantage over using any other FS. > I have documented how to use syslinux to build a fat32 livecd/installer here > http://forums.fedoraforum.org/showthread.php?t=303138 > > I was surprised that syslinux worked on ntfs It stopped when the kernel > could not read the ntfs file system. I was looking at ways to fix this. > Someone suggested as you did to put fuse support into the initramfs but > that sounds like a lot of work. I know (Done it in the past) that I could > build the ntfs driver right into the kernel and it would fix my problem. > I was looking and it doesn't appear to be difficult to build it as a module > and include it in the initramfs so I was thinking this would be a trivial > way to support building a LiveOS on an ntfs formatted thumb drive. If this is about creating a live image from within Windows, the time would be better spent fixing the tools so that the users don't have to worry about this at all. >> Also, I don't think you can switch the underlying driver of the root >> device out like that. I'm also not sure if you can use a FUSE device >> for the root mount point but if you can then you can just include > > With the kernel module you wouldn't be using fuse for the root file system. > Although I remember reading else where that this is possible and I think it > has been done. I was more thinking mounting it again elsewhere but I don't > know if that would really be necessary or if it would cause issues mounting > it twice with two different drivers. It would. You really don't want two disjoint drivers operating on the same physical device/partition. >> ntfs-3g in the initramfs and use that from the start anyway. >> >> josh > > Putting a kernel module into a initramfs is one thing (what I was talking > about;) building all the tools to use a fuse file system into the initramfs > is another. I think that would involve rebuilding busybox? (Is that what is > used in Fedora's initramfs). Sorry, but I don't see us enabling the ntfs driver in Fedora kernels. You don't need to rebuild busybox as I don't think dracut even uses busybox. Likely all it would need is the ntfs-3g package (and its dependencies) and a dracut module to start it up. josh _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
