On Tue, Mar 3, 2015 at 11:31 AM, Jeff Sadowski <jeff.sadowski@xxxxxxxxx> wrote: > 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. > Oooh fuse even has smb maybe syntax like this as well could be supported root=live:SMB=[<username>[:<password>]]@<ip / host>/share >> >> josh _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
