Windows based installation of Fedora Linux?

Douglas McClendon dmc.fedora at
Thu Sep 13 12:01:09 UTC 2007

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.


> On 9/13/07, Ago <agostino.russo at> wrote:
>> Douglas McClendon <dmc.fedora <at>> 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 at

More information about the fedora-devel-list mailing list