Hi all,
I am Wubi's author. I'd be happy to help you out if you wish to implement something like Wubi for Fedora. I will not have much time to do actual coding but at least I can point you out to the relevant code snippets (which is spread over different projects and files).
As you are probably aware Wubi is now included within Ubuntu 7.10. The interface will change slightly to reflect that. Notably it is now also possible to boot a LiveCD/ISO from HD (handy to go around bios issues and helping out people with no CD). The frontend can be used almost as is, you need to change the branding, version.nsh, IsoList.ini, and preseed.nsh (to generate appropriate preseeding information for an automatic installation). There should be little Ubuntu/Debian specific code in there. The relevant code is in: https://launchpad.net/~ubuntu-installer/wubi/gutsy. If you want to submit patches to "isolate" even more the frontend from Ubuntu specific code, you are most welcome.
On the backend side, you need to have ntfs-3g pre-installed by default (https://blueprints.launchpad.net/ubuntu/+spec/write-support-for-ntfs), have an installer that can work in non-interactive mode (https://blueprints.launchpad.net/ubuntu/+spec/ubiquity-automation), modify the standard initrd (grep loop in https://launchpad.net/ubuntu/+source/initramfs- tools) and the liveCD initrd (https://launchpad.net/~ubuntu- installer/lupin/gutsy). And of course have the installer be aware of loopfile targets (https://code.launchpad.net/~ubuntu-core-dev/partman-auto-loop/ubuntu). If you kill all userspace processes at shutdown you have to skip fuse/ntfs-g (https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/87763).
Note: if you poked with the old installer, things have changed quite a bit. We used to embed the initrd within the frontend, and that initrd used to override the ISO initrd/standard installer which in turns used to override the installed (normal boot) initrd. It does not work like that anymore, all initrd changes (liveCD initrd and normal-boot initrd) have been moved upstream and the frontend extracts the initrd directly from the CD/ISO.
Hope it helps.
Regards,
Ago
Ago wrote:
Hi all,
I am Wubi's author. I'd be happy to help you out if you wish to implement something like Wubi for Fedora. I will not have much time to do actual coding but at least I can point you out to the relevant code snippets (which is spread over different projects and files).
Since I've advocated a win32 installer for Fedora in the past, I'll at least say - cool. Unfortunately I also don't forsee myself having time to dedicate to this in the near future(nor the desire, as I am and hope to stay winblowz free ;). But I hope someone else finds the time :)
Out of curiosity, I notice on your page mention of the ntfs-loopback method being somewhat brittle, as you suggest "don't yank the plug if you can avoid it". Can you point me to any further info on this issue. (mail list archive threads...) I think something similar is causing me trouble in a different scenario.
Thanks again, very cool stuff.
-dmc
As you are probably aware Wubi is now included within Ubuntu 7.10. The interface will change slightly to reflect that. Notably it is now also possible to boot a LiveCD/ISO from HD (handy to go around bios issues and helping out people with no CD). The frontend can be used almost as is, you need to change the branding, version.nsh, IsoList.ini, and preseed.nsh (to generate appropriate preseeding information for an automatic installation). There should be little Ubuntu/Debian specific code in there. The relevant code is in: https://launchpad.net/~ubuntu-installer/wubi/gutsy. If you want to submit patches to "isolate" even more the frontend from Ubuntu specific code, you are most welcome.
On the backend side, you need to have ntfs-3g pre-installed by default (https://blueprints.launchpad.net/ubuntu/+spec/write-support-for-ntfs), have an installer that can work in non-interactive mode (https://blueprints.launchpad.net/ubuntu/+spec/ubiquity-automation), modify the standard initrd (grep loop in https://launchpad.net/ubuntu/+source/initramfs- tools) and the liveCD initrd (https://launchpad.net/~ubuntu- installer/lupin/gutsy). And of course have the installer be aware of loopfile targets (https://code.launchpad.net/~ubuntu-core-dev/partman-auto-loop/ubuntu). If you kill all userspace processes at shutdown you have to skip fuse/ntfs-g (https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/87763).
Note: if you poked with the old installer, things have changed quite a bit. We used to embed the initrd within the frontend, and that initrd used to override the ISO initrd/standard installer which in turns used to override the installed (normal boot) initrd. It does not work like that anymore, all initrd changes (liveCD initrd and normal-boot initrd) have been moved upstream and the frontend extracts the initrd directly from the CD/ISO.
Hope it helps.
Regards,
Ago
Since I've advocated a win32 installer for Fedora in the past, I'll at least say - cool. Unfortunately I also don't forsee myself having time to dedicate to this in the near future(nor the desire, as I am and hope to stay winblowz free ;). But I hope someone else finds the time :)
Good questions. There are in fact 2 separate issues.
1) Hosting filesystem corruption (ntfs). We had a few reports where people were not able to boot into Windows after an hardreboot in Wubi. Filesystem corruption does happen when you hardreboot, whether you use Wubi or not. Sometimes you get lucky (also with Wubi) sometimes you do not. The real question is whether Wubi (ntfs-3g in this case) makes things any worse. On average, we have 1 such report every 10K downloads. Add that Wubi users tend to reboot more often than usual, since they are in a new environment and often they do not know how to get out of a real or apparent deadlock. So are the numbers we see physiological? Honest answer is that I have no clue. I discussed that with Szaka (ntfs-3g author) and according to him, ntfs-3g does not make things any worse and there is little to be done on his side. If you have a different opinion on this I would like to hear from you.
2) Hosted filesystem corruption (ext3). When Ext3 writes the journal, the data does not end up on the HD but gets handled by ntfs, which in turns may or may not write the data to the HD. So if you hard reboot, data loss in the hosting filesystem may cause journal corruption of the hosted filesystem, which makes recovery quite challenging. This is not an ntfs/ext3 specific issue, you would have that in any nested filesystem configuration (or at least this is my understanding). What we have done was to tweak sysctl dirty settings, so that dirty pages are flushed to disk as often as possible. That seems to have done the trick. Since we did that, I cannot recall any complaint due to ext3 data loss, but of course that does not eliminate the issue.
On top of that we cannot hibernate/suspend. Suspend-to-ram is a problem because of the ordering in which userspace processes are terminated/resumed which becomes an issue if you use a userspace filesystem (if the loopfile is hosted on vfat, suspend works fine). With hibernation you also have to handle the issue of having swap on a file.
My take on all this is that Wubi is a "short term" installation. It's good enough for a few days and far more captivating than a live CD or a VM. But it's not ok for data-sensitive situations or for long term use. I would use the word "demo" if it did not have a try-then-pay connotation. And yes, because of the above, some users will be left with a bitter taste in their mouth, and the reputation for reliability will be negatively affected. On the other hand you will be able to reach many users that would not dare to try Linux otherwise, you will provide Joe Average (read 90% of the users out there) with a one-click installer and that helps a lot when you have to bear the stigmata of being seen as a "difficult OS".
It's a trade-off.
Regards,
Ago
Well, I have actually used Wubi a few days ago on a recently purchased family Vista (blech) laptop, and I really haven't experienced any issues with it. Actually those FS issues in NTFS have nothing to do with Wubi in particular, but rather with the way fragmentation in NTFS is and how it affects disk images and vice versa (at least from a user PoV I can explain it, i know no technical details about it). Whenever you have an NTFS partition with files that are large compressed filesystems (any form of compressed tree, e.g. tarballs, disk images, ISO, zip), fragmentation occurs more rapidly and FS degeneration seems to become more likely. This issue is less likely on ext3 in my experience, but it is still possible. This issue is probably why FAT32 has the filesize limitation it does. NTFS probably was supposed to fix that, but obviously didn't. Though those are merely speculations (regarding the whys about design). Anyways, that is my educated uneducated opinion :)
And anaconda does support completely automated installation (kickstart files!), for the others, someone else needs to answer....
On 9/12/07, Ago agostino.russo@gmail.com wrote:
Since I've advocated a win32 installer for Fedora in the past, I'll at least say - cool. Unfortunately I also don't forsee myself having time to dedicate to this in the near future(nor the desire, as I am and hope to stay winblowz free ;). But I hope someone else finds the time :)
Good questions. There are in fact 2 separate issues.
- Hosting filesystem corruption (ntfs). We had a few reports where people
were not able to boot into Windows after an hardreboot in Wubi. Filesystem corruption does happen when you hardreboot, whether you use Wubi or not. Sometimes you get lucky (also with Wubi) sometimes you do not. The real question is whether Wubi (ntfs-3g in this case) makes things any worse. On average, we have 1 such report every 10K downloads. Add that Wubi users tend to reboot more often than usual, since they are in a new environment and often they do not know how to get out of a real or apparent deadlock. So are the numbers we see physiological? Honest answer is that I have no clue. I discussed that with Szaka (ntfs-3g author) and according to him, ntfs-3g does not make things any worse and there is little to be done on his side. If you have a different opinion on this I would like to hear from you.
- Hosted filesystem corruption (ext3). When Ext3 writes the journal, the
data does not end up on the HD but gets handled by ntfs, which in turns may or may not write the data to the HD. So if you hard reboot, data loss in the hosting filesystem may cause journal corruption of the hosted filesystem, which makes recovery quite challenging. This is not an ntfs/ext3 specific issue, you would have that in any nested filesystem configuration (or at least this is my understanding). What we have done was to tweak sysctl dirty settings, so that dirty pages are flushed to disk as often as possible. That seems to have done the trick. Since we did that, I cannot recall any complaint due to ext3 data loss, but of course that does not eliminate the issue.
On top of that we cannot hibernate/suspend. Suspend-to-ram is a problem because of the ordering in which userspace processes are terminated/resumed which becomes an issue if you use a userspace filesystem (if the loopfile is hosted on vfat, suspend works fine). With hibernation you also have to handle the issue of having swap on a file.
My take on all this is that Wubi is a "short term" installation. It's good enough for a few days and far more captivating than a live CD or a VM. But it's not ok for data-sensitive situations or for long term use. I would use the word "demo" if it did not have a try-then-pay connotation. And yes, because of the above, some users will be left with a bitter taste in their mouth, and the reputation for reliability will be negatively affected. On the other hand you will be able to reach many users that would not dare to try Linux otherwise, you will provide Joe Average (read 90% of the users out there) with a one-click installer and that helps a lot when you have to bear the stigmata of being seen as a "difficult OS".
It's a trade-off.
Regards,
Ago
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Ago wrote:
Good questions. There are in fact 2 separate issues.
- Hosted filesystem corruption (ext3). When Ext3 writes the journal, the data
does not end up on the HD but gets handled by ntfs, which in turns may or may not write the data to the HD. So if you hard reboot, data loss in the hosting filesystem may cause journal corruption of the hosted filesystem, which makes recovery quite challenging.
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.
This is not an ntfs/ext3 specific issue, you would
have that in any nested filesystem configuration (or at least this is my understanding). What we have done was to tweak sysctl dirty settings, so that dirty pages are flushed to disk as often as possible.
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.
Question- are these sysctl settings controlling the writes from the hosted-fs->host-fs, or from the host-fs->disk, or both?
That seems to have done
the trick. Since we did that, I cannot recall any complaint due to ext3 data loss, but of course that does not eliminate the issue.
On top of that we cannot hibernate/suspend. Suspend-to-ram is a problem because of the ordering in which userspace processes are terminated/resumed which becomes an issue if you use a userspace filesystem (if the loopfile is hosted on vfat, suspend works fine). With hibernation you also have to handle the issue of having swap on a file.
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?
My take on all this is that Wubi is a "short term" installation. It's good
...
It's a trade-off.
That's engineering ;)
thx...
-dmc
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
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....
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
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
Douglas McClendon <dmc.fedora <at> filteredperception.org> writes:
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.
Yeah, to summarize the hardreboot issues in one sentence: there is not much that we can do! If anything, ntfs-3g might be improved, but ntfs-3g author does not think there is anything to be done there either (other than fschk...).
But the installers for ubuntu and fedora are quite different. Nothing that would preclude the porting, but certainly a fair amount of work.
I would encourage to split the backend work from the windows frontend. The frontend has to do +/- the same stuff whatever distro you use, so cooperation should be more straightforward. I'd be pleased if the wubi frontend code had to be used by other distros (feel free to rebrand as you like). Some common tasks include:
* Detect all windows settings that may be useful during installation * Show user interface for the few settings left * Detect a physical CD and if found copy it to the HD * If no appropriate physical CD is found, look for an ISO on the HD * Run the checksum * Download the ISO if one is not found or checksum is wrong * Install grub4dos * Extract initrd/kernel from the ISO and copy it to the HD * Write preseed/kickseed/younameit * Add an entry to the windows bootloader * Create the uninstaller
The only distro-specific piece is the one that writes the preseed/kickseed. It should not be too difficulto to make it easy to "swap". The ISOs information is embedded in a single text file, so adding/changing ISOs is fairly straightforward. Rebranding involves replacing a few bitmap files and editing version.nsh.
As mentioned, if anyone is interested in helping with the frontend code and make it distro-neutral, I'd be highly receptive... If instead of nsis you'd rather use some cross platform framework (within resaonable size constraints) I'd be also quite keen to jump ship.
The backend though is distro-specific, you can have a look at the work involved in Ubuntu, and implement something similar within Fedora. I provided the links to the relevant Ubuntu files, it might save you some time and at the very least should give you a better understanding of the work involved.
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.
Something like that, see above. Note that we do not use anymore a custom initrd, instead the kernel/initrd is extracted from the ISO and saved to disk. Such initrd must accept 2 optional arguments: find_iso and find_preseed, so that the initrd can in turn load the ISO (as opposed to load the CD) and the preseed file. Then grub4dos is installed, this grub4dos tries first to load an installed version of the distro (/distroname/disks/boot), otherwise it tries to launch the installer (/distroname/install/boot).
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.
I'd be interested to know more about it.
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.
The equivalent Ubuntu file you really want to look at is partman-auto-loop. That adds the capabilities of targeting a loopfile to the old-school Ubuntu installer. You'd have to implement something similar within anaconda.
Regards,
Ago
Ago wrote:
Douglas McClendon <dmc.fedora <at> filteredperception.org> writes:
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.
I'd be interested to know more about it.
rebootless installer -
originally-
http://www.redhat.com/archives/fedora-livecd-list/2006-August/msg00000.html
http://www.redhat.com/archives/rhl-devel-list/2007-July/msg00768.html
as of a couple days ago - (now with GUI and no patch to F7 required)
http://gzyx.org (screenshots even- ooh! ahh!)
059fbb7736cccc30f23162ee3411c27639e061f7 gzyx-0.5.004.2k70908a.iso
As it relates to a win32 installer, see my discussion at the beginning of the current thread-
http://www.redhat.com/archives/rhl-devel-list/2007-September/msg00099.html
(really the differentiation from current wubi, would be not needing a 2nd reboot. But to do it for ubuntu, you'd have to get them to go back to their early 2005 devicemapper-snapshot copy-on-write livecd mechanism)
Enjoy... ;)
-dmc
P.S. - I'll try to have a yum repo up soon for the "ZyX Rebootless Installer" so that anyone who wants to can just boot up the F7 livecd like normal, do a yum install of it, and enjoy the primitive coolness. ;)
Douglas McClendon <dmc.fedora <at> filteredperception.org> writes:
http://www.redhat.com/archives/fedora-livecd-list/2006-August/msg00000.html
http://www.redhat.com/archives/rhl-devel-list/2007-July/msg00768.html
as of a couple days ago - (now with GUI and no patch to F7 required)
http://gzyx.org (screenshots even- ooh! ahh!)
Thanks looks very interesting, I'll pass it on to other ubuntu devs in case they missed that. I've always liked the idea to eliminate the last reboot, but never had time to look into that closely so far.
Ago wrote:
Douglas McClendon <dmc.fedora <at> filteredperception.org> writes:
http://www.redhat.com/archives/fedora-livecd-list/2006-August/msg00000.html
http://www.redhat.com/archives/rhl-devel-list/2007-July/msg00768.html
as of a couple days ago - (now with GUI and no patch to F7 required)
http://gzyx.org (screenshots even- ooh! ahh!)
Thanks looks very interesting, I'll pass it on to other ubuntu devs in case they missed that. I've always liked the idea to eliminate the last reboot, but never had time to look into that closely so far.
Actually, it wouldn't be that unreasonable an idea for ubuntu to create a devicemapper based 'spin' whose sole purpose would be for use with wubi.
Honestly this is on my own personal todo list(until now, minus the 'for use with wubi' part)... But odds are I won't get around to it for quite some time.
-dmc
Douglas McClendon wrote:
Ago wrote:
Thanks looks very interesting, I'll pass it on to other ubuntu devs in case they missed that. I've always liked the idea to eliminate the last reboot, but never had time to look into that closely so far.
Actually, it wouldn't be that unreasonable an idea for ubuntu to create a devicemapper based 'spin' whose sole purpose would be for use with wubi.
Honestly this is on my own personal todo list(until now, minus the 'for use with wubi' part)... But odds are I won't get around to it for quite some time.
PRE-EMPTIVE SELF FLAME - that reply should not have been posted to this list. Completely non-relevant to list.
-dmc
King InuYasha <ngompa13 <at> gmail.com> writes:
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....
Please see the other post for how it works. Feel free to ask if you need more details.
Some front-end related projects:
* Find a reliable way to map windows drives to linux devices * Make wubi code distro-neutral and easy to rebrand * Improve detection of relevant windows settings (detect screen readers/accessibility options, improve timezone detection, current screen settings...) * Improve downloader. The current metadl library already supports download resume, metalinks and partial checksums. But the mirror selector is too basic (random choice). The library is being rewritten in c++ to add segmented downloads. Hampus Wessman is working on it, but he could probably do with some help. * Improve skin (ExperienceUI?) * Code clean-up / refactoring * Change interface language at runtime * Change branding at runtime ...
On 13/09/2007, Ago agostino.russo@gmail.com wrote:
nested filesystem => forget about the journal in the nested fs
Host the journal as a separate "device" (= file on the external fs) and fsync() or equivalent that before the data file? I'm sure the journal is sync'd when transactions are committed anyway ...
See mke2fs(8), option -J device=
-
Ago -
Bill Crawford -
Douglas McClendon -
Neal Gompa