lupin merge progress

[Colin Watson]

On Tue, Jul 31, 2007 at 10:31:26PM +0100, ago wrote:
> Colin Watson wrote:
> > 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.

Yeah, I was pondering something similar while setting up my test image.

> 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. :-)

> > 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.

pidof would be fine; just needs care in the initramfs.

> In any case it might be worth to support omitting processes by name as
> well as by pid.

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.

> 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.

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.

> 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).

> >From the windows-front-end side of things, the required changes are:
> 
> A) check whether an appropriate CD is inserted, preselect the
> appropriate ubuntu flavor and change the branding accordingly. Q1: in
> this case, shall we allow to select a different flavor which will
> require an ISO download?

I wouldn't be inclined to offer that option in the build of wubi we put
on the CD; I think it muddies the waters unnecessarily. If they wanted a
different flavour, they'd probably have requested a different one from
shipit, or downloaded and burned a different ISO image. Some people will
have got that wrong, but since it's pretty obvious what's happening I
don't think it's worth the UI complication.

> 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.

Can you remind me again of why you need the ISO in image form rather
than reading the necessary files off the CD directly? I get slightly
lost with Windows' treatment of devices.

> C) extract the kernel/initrd from the ISO/CD in order to reduce the size
> of wubi.exe (now kernel and initrd are bundled within the windows
> frontend).

Makes sense.

> 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.

Cheers,

-- 
Colin Watson                                       [cjwatson at ubuntu.com]