Gutsy inclusion progress

[ago]

One big question is what to do with partman for test3.

At the moment I disable partman and grub installation (in the alternate iso), then I create the filesystem into the loopmounted files using a custom script. Ideally partman should be able to target a loopmounted filesystem using only preseed arguments.

I am not sure what is the stage of that. Colin might be the person to ask.

[Henrik]

One big question is what to do with partman for test3.

At the moment I disable partman and grub installation (in the alternate iso), then I create the filesystem into the loopmounted files using a custom script. Ideally partman should be able to target a loopmounted filesystem using only preseed arguments.

I am not sure what is the stage of that. Colin might be the person to ask.

Yes, he is clearly not fond of the partman solution used now. He would like to see this implemented directly before we deploy it on the CD, so it probably looks like we will miss tribe 3. That's OK, we can target tribe 4 instead and in the meantime appeal for wider testing via blogs and forums. There are still quite a few other things to sort out. I'll speak with Colin and other team members at our meeting next week about partman, ntfs and artwork.


This would also be solved by integrated ntfs kernel support right?
Yes but... ...This is the answer from szaka (ntfs-3g author) about making ntfs-3g into a module:

My use of the word module might have been wrong here. The key is to get read/write support into Ubuntu: https://wiki.ubuntu.com/WriteSupportForNTFS


Another point was branding. I understood that colin wants a branded version for each Ubuntu flavor. My suggestion is this: let's keep the desktop selector, but let's preselect the appropriate desktop environment whenever a CD/ISO is detected. Selecting a desktop will change the title and the banner graphics accordingly. This way we can use the same program as stand-alone or bundled with CD.

That sounds good. You would also be able to start it with a given parameter? (distro=kubuntu, say)


Linked to the above I would add the following change: the initrd/kernel is not acutually bundled with the installer. It is extracted from the CD/iso. This will greatly reduce the size of the installer. The issue here is to find a way to mount an ISO under windows (have not investigated that). This also implies that the LiveCD initrd has to work in dual mode: whether booted from hard disk or whether booted from CD.

CD space is always at a premium so this would be great, but it potentially sounds hard and fragile. A very small custom kernel might be an alternative later.

I mentioned to colin and he agreed, that we would desire to be merged and that the project can continue to be called wubi (to show continuity with our past efforts). Of course wubi will be only an internal project name and all rebranding can take place as usual. That said at the moment the title already reads "Ubuntu Setup", and the only explicit mention of wubi is in: the version (grayed out), folder name, file name, banner.

Yes, the point here is not to obscure the origin of Wubi but just make sure we can have the slick custom artwork and tight branding we need for Ubuntu while allowing Wubi do do it's own thing in he standard version downloaded from your site. You might want to add options for Debian and Guadalinex for example.

[ago]

Yes, he is clearly not fond of the partman solution used now.

I do not like it either, I had a bug reprot to remind me to improve on it (https://bugs.launchpad.net/lupin/+bug/87846 ), but I never bothered since the proper solution is to use partman as opposed to skip it and so far the code, even if it is ugly, did not create any issues.

He would like to see this implemented directly before we deploy it on the CD, so it probably looks like we will miss tribe 3.

I think we should still start importing as much code as possible. The idea is that any code insertion should be a complete pass-through under normal installation, so that is still a good test. Moreover we can keep the current hacks on a conditional basis: if we are doing a wubi-type installation use ugly hacks otherwise use normal code. Then we replace the ugly hacks by tribe 4. Pls let me know what is colin view on this.

I'll speak with Colin and other team members at our meeting next week about partman, ntfs and artwork.

The full list of issues worth mentioning is:

• Rebooting issues (fuse should be taken care of properly by killall5), colin already knows about it
• Hard reboot issues. This is very important! Users do hard reboot since they do not know how to handle new situations, corruption might make the hosted fs unrecoverable (if journaling data is lost) and the hosting fs corrupted (requiring chkfs). This makes for some annoying pubblicity. At the moment I have "safe" values in sysctl.conf. But this is up to the kernel devs to decide what set of options are safe (given performance constraints) and up to the ntfs-3g devs to make sure that hard reboots are handled reasonably well (I'll see if szaka can do something about it).
• Apparently hibernation is impossible (since swap is inside another partition) and suspend is difficult whenever fuse is used (since fuse might get frozen before other processes that use the disk), so that both might have to be disabled. mjg59 might be able to make suspend to ram work in time for Gutsy.
• Partman: I think that it is up to colin to include support for loopmounted file targets, it's probably not worth to change the old code.
• Lots of disk device modules are now pre-loaded into the initrd (in order to mount the host fs at full speed), there should be a mechanism such that root is mounted r/o and then remounted r/w after modules are loaded. (/etc/init.d/checkroot & co might be affected).
• host folder has to be pre-mounted r/w and it's not a good idea to umount that.
• ntfs-3g has to be in by default and uninstalling that will create problems (basically the machine will be unbootable).
• /boot folder has to be a folder on the hosting filesystem with r/w access or it would not be possible to upgrade the kernel. One issue is that menu.lst entries will appear under a path in Linux and a different path when booted from the host OS. For instance at the moment the boot folder is mounted under /media/host/wubi/boot which is symlinked to /boot. This means that under linux the kernel is visible as /boot/vlinuz... but under windows (when menu.lst is actually used) it is visible under C:\wubi\boot\vlinux. Hence update-grub does not get it right... I have no good way to make this process work under both a normal installation and a wubi installation.
• There is no fsck in ntfs-3g and you cannot mount r/w (and hence boot) from a system that is flagged as "dirty". You have to fix it up from windows first.

My use of the word module might have been wrong here. The key is to get read/write support into Ubuntu: https://wiki.ubuntu.com/WriteSupportForNTFS

There are 2 separate issues:

1. Having write support by default for the hosting fs (namely ntfs). We do need that otherwise we have to ship the ntfs-3g package inside the initrd as we are doing now (which would be ugly).

2. Having write support offered as a kernel module as opposed to have it in userspace. Having the root filesystem on top of a userspace process creates problems. Hibernation and rebooting pop to mind, but you could also simply kill the fuse userspace processes by mistake... Fuse is very nice, but IMO not for root. Unfortunately we do not have much choice.

EDIT: talked also with mjg59 and he agrees with szaka: #2 is not going to happen, so we'd better learn to live with fuse.

That sounds good. You would also be able to start it with a given parameter? (distro=kubuntu, say)

Yes we do support parameters. For the moment only "debug", but we could of course do that. If we support that there is not much point to look for a CD/ISO at startup (we still look for ISO during installation).

This raises another question:

What do we do when a Ubuntu CD is used? Do we extract the ISO or do we assume that the CD is going to be inserted once you reboot (we might have a message for that)?

CD space is always at a premium so this would be great, but it potentially sounds hard and fragile. A very small custom kernel might be an alternative later.

That serves several purposes not just space savings. For instance at the moment you can only install an ISO that uses the same kernel of the one shipped with wubi. This means that you need to ship as many wubi versions as there are architectures/kernel builds. Which is fine for a version bundled with the ISO but it is an unnecessary complication for the stand-alone version. I do not think that such a solution would be fragile, but I am not sure how to handle the ISO mounting in windows. Any hint here would be handy.

Yes, the point here is not to obscure the origin of Wubi but just make sure we can have the slick custom artwork and tight branding we need for Ubuntu while allowing Wubi do do it's own thing in he standard version downloaded from your site. You might want to add options for Debian and Guadalinex for example.

I would rather have our project completely incorporated, then Debian and Guadalinex are more than welcome to do their own rebranding. We would be unlikely to have more than 4-5 desktop environments anyway, since that would be considered confusing, therefore there would be little point to keep wubi as a separate branch once it is used in Ubuntu. And personally I would welcome the opportunity to help with official ubuntu code.

[ago]

That serves several purposes not just space savings. For instance at the moment you can only install an ISO that uses the same kernel of the one shipped with wubi. This means that you need to ship as many wubi versions as there are architectures/kernel builds. Which is fine for a version bundled with the ISO but it is an unnecessary complication for the stand-alone version. I do not think that such a solution would be fragile, but I am not sure how to handle the ISO mounting in windows. Any hint here would be handy.

Hmm a quick google search shows that 7zip (LGPL) is capable or extracting from an ISO. That's all we need...

Assuming that lupin patches are already within the ISO initrd, we can either copy kernel/initrd from a mounted CD or from the target ISO.

Henrik, do you have any reason to think that this might not be appropriate?

[ago]

Another idea is to have the drive dropdown to also include an option to simply boot the iso/cd:

Installation Drive:
C:
D:
Don't install, just run the CD.

Handy for persons with no CD rom that still want to do a full installation, also handy to go around bios problems and to spare people the trouble of burning the ISO. Uninstalling removes the boot.ini menu entry and the kernel and initrd (extracted from CD/ISO, see above).

Other option still is to add a direct installation options within the GUI:

Installation Drive:
C: (do not modify existing partitions)
C: (resize and create a new partition)
D: (do not modify existing partitions)
D: (resize and create a new partition)
Use available free space (shown if enough free/unpartitioned space is detected)
Don't install, just run the CD.

The interface is still clean and simple, and the operation is fairly safe (there is no option to format a partition actually containing data). The main issues against that are:

1. if you use a dedicated partition you cannot guarantee a "full uninstallation",
2. many people will be scared off even if the operation is fairly safe
3. if you can boot the live ISO, you can use that to do a full installation
4. the "language" above is too complex for the target audience

[tuxcantfly]

If anybody's still tracking this, the discussions on inclusion progress have moved to the ubuntu-installer mailing list. Also, the tool to transfer the loopmounted partitions to dedicated partitions (LVPM) could also be integrated into Gutsy's Ubiquity or be used as a small, standalone app installed once Ubuntu has been installed to a loopmounted partition.

[ago]

If anyone is curious, here is an update on what we have been working on.

What to expect:

* Lupin functionality (back-end code) has been merged by Ubuntu devs within the LiveCD and regular Ubuntu initrd
* Two new installation options have been added: "Dedicated Partition", and "Read Only Mode". The first will ask about partitioning info after reboot (via ubiquity), the second will simply boot the LiveCD/ISO (from there you can run the classic installer as well). Handy if you have adverse bios settings or no CD player.
* ntfs-3g, which is required by Wubi, will be installed by default in Ubuntu (so, as a side benefit, r/w access to your Windows partitions should be easier)
* Wubi will work with the LiveCD ISO as opposed to the alternate ISO
* It will be possible to run Wubi with a physical CD as well
* The blue text-based installation screens you used to see after first reboot got a face-lift, you will now get a fully graphical interface based on ubiquity.
* Hampus is working to improve the downloader adding segmented downloads (much faster), but not sure when that will be ready.
* Wubi has been put on diet, it now weights only 600K (down from 10000K!).

What _not_ to expect:

* Suspend/Hibernation will not work, suspend might be fixed in Hardy, but it's not going to happen in Gutsy.
* Filesystem robustness to hard reboots is not going to be much better than what we have at the moment
* When "dedicated partition" is selected, the above issues will be addressed, but you will only be able to uninstall the windows files, not to remove grub and the installed partition.
* Resizable disk images will not be available for the time being

As mentioned above, Tuxcantfly started discussing the possibility of having LVPM as an official Ubuntu product, its functionalities might get incorporated within Ubiquity and will allow you to upgrade smoothly from a loopfile installation to a dedicated partition installation.

You can expect a wubi-gutsy pre-release version in the coming days, so stay tuned since we will need heavy testing, your feedback is highly welcome (as usual).

[trommas]

So is this a different iso, or should we just download the daily build?

[ago]

So is this a different iso, or should we just download the daily build?

The backend is still broken at the moment and requires quite a bit of manual intervention to make it work, I'll let you know as soon as there is something you can play with. If you are curious the builds are in

http://wubi-installer.org/devel/minefields/

[ago]

In fact to make it work try that:

1. Download the daily build and burn a CD
2. Run wubi and select 4Gb installation
3. Before rebooting edit c:/ubuntu/install/grub/menu.lst and delete find_iso=XYZ
4. Reboot without the CD inserted
5. When asked instert the CD

Let me know how it goes. Probably not very far...