On Tue, Mar 3, 2015 at 11:04 AM, Jeff Sadowski <jeff.sadowski(a)gmail.com> wrote:
On Tue, Mar 3, 2015 at 5:36 AM, Josh Boyer
> On Mon, Mar 2, 2015 at 4:35 PM, Jeff Sadowski <jeff.sadowski(a)gmail.com> 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
>> 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
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
> 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.
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.