lupin merge progress

[ago]

> OK. I think it may well make sense for lupin to continue to exist to
> take care of differences that are specific to running Linux inside a
> Windows filesystem (as opposed to just loop-mounting in general).

As mentioned, there are 3 main differences that can either go into a
lupin.deb or be changed upstream:

1) the paths in menu.lst: at the moment, at each reboot/shutdown we run
update-grub and then "sed" the paths. A proper patch to update-grub
might be preferable. E.G. using an optional #host-boot-folder parameter in
menu.lst to specify how to adjust the paths.

2) sysctl.conf: one solution might be to edit /etc/init.d/procps.sh so
that if it detects a loop installation and if it finds
sysctl.loop.conf, will use that instead of sysctl.conf. Or something similar.
So that too can be moved upstream.

3) disable of hibernation/suspend (can it be moved upstream?)

> I have nothing against lupin, but that was the general idea. :-)

Don't worry I am not attached to it, I am well aware that lupin must
die, that was the plan behind the lupin-merge blueprint, I am glad that
myself and the other wubi/lupin devs have been able to help.

> Right. If I can figure out a way to test that adequately, I may well
upload it in advance of Phillip's NTFS work.

The setup I am using is the following: I have a VM disk formatted with
ntfs, inside of ntfs I have the loop file
(/ubuntu/disks/system.virtual.disk), booting initrd+kernel
(/ubuntu/boot), installation stuff initrd+kernel+preseed+iso
(/ubuntu/install) and grub4dos (in mbr) + menu.lst. The virtual disk
is also mountable
from the host os, so that I can update the files.

> The only tricky bit is extracting the pid of the ntfs-3g process

I would naively use pidof, since you don't, I assume there is something
wrong with it. In any case it might be worth to support omitting
processes by name as well as by pid.

> I've applied the os-prober change upstream.

As a note, a couple of patches to ma-ask were due to the fact that
sometimes the windows folder was not found even if the username was
correctly inputed (http://ubuntuforums.org/showthread.php?t=480114),
apparently because NTUSER.DAT was not in upper case, I just quitted
m-a as opposed to properly fix the issue at the root. I know, I should
have filed a bug, I forgot, doing it now.

On a side note, how is the loop installation going to be used exactly?
I can envisage 4 scenarios:

1) The user downloads and runs the installer (windows frontend) in
stand-alone mode, which then downloads the necessary ISO and installs
Grub4dos. Pretty much what wubi does right now.

2) The user has a LiveCD, and he runs the CD-Rom from within windows, he
then runs wubi which ships within the CD in order to install to a file
as opposed to install to a partition. Grub4dos is installed, a preseed
is generated, no ISO is downloaded (see Q2). After a reboot the user may
boot from CD or HD according to bios settings, in both cases the same
thing should happen.

3) The user has a LiveCD, and he runs the CD-Rom from within windows, he
then runs wubi which ships within the CD in order to boot the LiveCD
without having to worry about bios issues. Grub4dos is installed, a
preseed is generated containing language/keyboard info. After a reboot
the user may boot from CD or HD according to bios settings, in both
cases the same thing should happen.

4) The user boots from the Live CD as usual.