On Tue, Mar 3, 2015 at 9:20 AM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > 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. > Not true, if you avoid formatting no data is destroyed. I was able to use syslinux on the device without destroying any information that was previously on the thumbdrive. I only included formatting steps in my tutorial as a guaranteed know state. Sometimes drives come with no partitioning information. Those may still need formatted. The only thing that needs to be in any certain area is the LiveOS directory containing the squashfs image. You can have what ever else on the drive with no consequence. >> 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. > This is about using tools that already exist that could be used totally non destructively if the filesystem was supported from the kernel/initramfs. Also to use the ntfs file system over the fat32 file system as a way to support larger partition and file sizes on a shared bootable media. >>> 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. > I'll do some testing on this latter and see. It will be interesting. >>> 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. I will have to see how hard that is and how hard it would be for its maintainers to agree to put into the installer image. I was only looking for a simple solution and thought I might have had a chance of maybe convincing the kernel maintainers to include the ntfs readonly kernel driver. Final Goal: I want a Fedora bootable ntfs thumbdrive without having to have a custom kernel/initrd of my own. That I could also use to share large files from a windows computer and linux computer. Maybe even capable of having a windows installer on the same drive (Maybe possible with UEFI). I didn't think a request for the ntfs kernel module was all that difficult a request with how easy it was for me to build my own kernel. If Fedora kernel/modules included ntfs it would have been trivial to requested a change to the prebuilt initramfs to include it. No worries. It was worth a try to see if I could make it easier for others. I don't need the Fedora bootable image as much as my ntfs format (more for size support). I will read a little about dracut and attempt to build an initramfs with the fuse tools. I think that stands less of a chance at making it into the official Fedora then to add the ntfs kernel module. Maybe if the fuse tools make it in, I could get the sshfs in as well; then I could use it to network boot with the sshfs as the usable filesystem. That had been a thought of mine for a while. Maybe syntax something like root=live:SSHFS=<username>:<password>@<ip / hostname> and have the squashfs in a users home directory then they would have a live image from a network boot and be able to PXE boot a live image with pxelinux. Of course you would want to limit what that user could do. Maybe /sbin/nologin for the shell of that user. I thought about sshfs because httpfs was only really supported in slax and only with one particular web server as the http protocol doesn't really have filesystem support. And I wasn't sure if ftpfs would fair the same. Sshfs would use the true filesystem underneath thus avoiding the issues with httpfs. > > josh _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
