[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Windows based installation of Fedora Linux?



King InuYasha wrote:
Perhaps then, if someone with the skill to work on the Linux side of the
stuff can figure out how to solve some of the issues, the patches could be
sent into the upstream for affected components, and I do have some knowledge
of NSIS, but Wubi code is somewhat difficult for me to sift through.... So
how does the latest version of the installer work exactly? I am somewhat
confused now....

First, you can pretty much ignore the message you replied to. Those were rather esoteric issues that would not get in the way of porting wubi.

But the installers for ubuntu and fedora are quite different. Nothing that would preclude the porting, but certainly a fair amount of work.

One thing mentioned was installing to loop files. I believe this was a feature fedora/rh had a long time ago (to vfat). Probably this would be the place to start, as this itself is probably a fair amount of work, but one which even by itself adds functionality.

I'm not exactly sure how wubi works. One way it might work would be to copy the iso of the install cd/dvd to ntfs, then setup a very custom initramfs. Then setup a bootloader (native windows bootloader, or grub that talks ntfs?) to boot the install-cd-iso-on-ntfs with the custom initramfs. The custom initramfs would handle the cd-iso-on-ntfs issue, then with an append string, or something more complicated, cause the resulting boot to launch a kickstart installation, that using the above install-to-loop file support, installs to a file on the ntfs.

That would probably(?) be the method that mirrors what wubi is doing with ubuntu. (or rather than the full livecd installer, just a minimal network installer bootiso)

Though given the differences between ubuntu livecd installer, and fedora livecd installer (slow flexible file based copy from squashfs versus fast less-flexible block based copy from squashed ext3 image), there may be other ways (still using the wubi win32 front end) to install. I sortof alluded to them in a recent thread prior to this one. I.e. how my mods to anaconda to support rebootless installation from livecd, could be used for a win32 installer.

Maybe someone else will volunteer a better outline for you. My point is that it is a rather large can of worms. Some of the stuff I am going to be working on in the coming weeks/months, may make the problem easier. But independent of that, I'd still recommend that the starting point being (re)adding support to install-to-loop files (on ntfs) to anaconda. Get that done, and in addition to it just being plain cool, you will be more or less half-way done.

-dmc




On 9/13/07, Ago <agostino russo gmail com> wrote:
Douglas McClendon <dmc.fedora <at> filteredperception.org> writes:

This is I think what I've been noticing as well in a similar situation.
  The one time I tried to recover, fsck _completely_ horked the ext3 fs.
I am no fs expert, but my understanding is:

nested filesystem => forget about the journal in the nested fs

I may be wrong, but I'd guess that VMs suffer the same problem, and the
hosted
fs journal can also get corrupted in case of a hard reboot of the hosting
system.

In short I would expect Wubi I/O behavior/performance to be on par or
better
than a VM, under all scenarios. BUT in a VM under windows you would use
windows
fs driver for the hosting system, while we use ntfs-3g/vfat. So the above
statement assumes that ntfs-3g/vfat behaviour/perfomance is equivalent to
the
windows counterpart.

This was also my first thought.  The down side, is that in my usage
scenario, the fs would be typically on a usb-flash-stick, and it seems
like an undesirable thing to be writing to it as often as possible,
rather than periodically.
You can always tweak the scripts affecting sysctl

Question- are these sysctl settings controlling the writes from the
hosted-fs-≥host-fs, or from the host-fs-≥disk, or both?
Should be both since that affects the kernel.

This sounds like it could be fixed with smarter ordering.  Do you
foresee that, or is it for some reason a more-or-less unfixable problem?
Yes Ubuntu kernel hackers have been looking into this, there was just no
time
to do it for the 7.10 release, it will probably be fixed for the next
release.
But that is beyond my skills.

Regards,

Ago


--
fedora-devel-list mailing list
fedora-devel-list redhat com
https://www.redhat.com/mailman/listinfo/fedora-devel-list



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]