lupin merge progress

[xivulon]

> > 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.
>
> Feels too hacky for me; people want to set sysctls for all sorts of
> reasons, so why should loop be so special? I'd just ship another init
> script.
>
> > 3) disable of hibernation/suspend (can it be moved upstream?)
>
> I haven't thought about this yet. Phase two unless somebody wants to
> beat me to it. :-)

probably easier to have 2 and 3 in lupin.deb then

> I disagree. Omitting processes from sendsigs can be dangerous; if you
> omit too many, Ubuntu will be unable to unmount the root filesystem and
> filesystem damage may result. (Consider if the user mounts some more
> NTFS filesystems other than the host one.) I far prefer specifying
> processes precisely.

hmm, if the user mounts more NTFS filesystems other than the host,
shouldn't they be unmounted by the subsequent init scripts (which run
before root is unmounted) as opposed to be killed by sendsigs?

> I think Ubuntu's main focus ought to be shipping wubi on the CD. Of
> course I imagine you guys would want to keep offering this installation
> method separately.

The main reason to have the stand alone version is that users may run
into troubles when burning the ISO (no burner, do not know how to use
burning software, bad medium, wrong bios boot order...), many do not
know about shipit and/or do not want to wait, and there are quite a
few with no cdrom at all.

> > 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.
>
> This is what I was imagining, though I'd recommend just telling the user
> to eject the CD (although the CD boot menu does include a "Boot from
> first hard disk" option in case they forget).

What I mean is that after running wubi, it will normally install
grub4dos + kernel + initrd on the HD. At the moment that is used both
to launch the installer and to launch the installed system. You can
use grub4dos only to launch the installed system and assume that the
user will reboot via CD, but also launching the installer (live CD)
can come handy if the bios makes CD booting complicated.

The main issue thought is that if you boot from CD, you need to
understand whether you have to run in unattended mode targeting a
loopfile or simply boot the live CD as usual. You probably will have
to scan for a preseed.cfg file.

The alternative is to always boot the live CD desktop, get rid of the
windows frontend, and only use ubiquity, adding the option to target a
loopfile to the GUI. Ubiquity will then also have to install grub4dos
and change boot.ini (editing vista bootloader from within ubuntu might
be quite challenging though).

> I wouldn't be inclined to offer that option in the build of wubi we put
> on the CD;

Makes sense

> > B) before downloading the ISO, check again if the desired CD is inserted
> > (assuming yes to Q1) and avoid download. Q2: shall we extract the ISO
> > from the CD or assume that the CD-Rom will be inserted after a reboot?
>
> I'm not sure I entirely understand the question here.

As mentioned above, you might also use grub4dos to go around bios
problems and launch the installer (not just the installed system).
This implies that when you reboot you may boot using the initrd
installed on the HD and hence you may be able to start the boot
process even if the CD is not inserted in the tray. That would not go
too far... Even so I think that extracting the ISO is not worth the
trouble and it's simple enough to ask the user to insert the CD.

> > There are a few more implications regarding the initrd used in the
> > live/alternate CD which depend on what of the 4 scenarios above are to
> > be supported.
>
> Note that we can't afford the CD space for a separate initrd for this
> installation method; it's got to use the regular initrd, which is why
> I've been trying to find relatively small changes to initramfs-tools and
> the like which encapsulate what lupin does.

I was thinking about adding some functionality to the initrd of the
alternate/live CD as opposed to have a separate initrd.


Ago