Merging Live and Install CDs (cloops built from .deb's)

[Matt Zimmerman]

On Sat, Feb 12, 2005 at 01:51:17PM +0000, Paul Sladen wrote:

> On Fri, 11 Feb 2005, Matt Zimmerman wrote:
> > - Somewhat increased memory requirements compared to the traditional
> >   installer (though very close to those of the installed system)
> 
> It shouldn't be much more if it's done from a separate boot-option (the main
> overhead being just dealing with the cloop);  unless you *wanted* the whole
> stack there to get X, sound, lights, network connection---which I can see as
> a considerable advantage.

Yes, that's quite an important benefit.

> > - Could not be used for upgrades
> 
> The issue here is not having the .deb's because they've already been
> unpacked.
> 
> Binary Diffs    [skip down to the next section for LiveCD stuff]
> ============
> 
> I've been continue to think about this area in relation to binary/delta
> updates (If a 10MB .deb differs by 20kB, only download the difference).

This approach still misses important use cases, I think.  Being able to
insert an Ubuntu install CD in a server, export it via a web server, and
have a network-accessible repository is simple and powerful, and we want to
preserve that functionality.

I see it as orthogonal; incremental downloads between .debs have been a
requested feature for some time, and might eventually be implemented, but
constructing .debs on the fly for installation would cost a lot of
complexity, and lose flexibility for the user.

> Because a LiveCD is a snapshot after install, once the initial filesystem
> image is built, it would need to be mounted and ''executed'' with all the
> changes introduced by the configuration control files tagged on at the
> end.  If you like, ''appending another tarball to the end'';  this bit
> would be tricky since otherwise this technique lends itself to producing a
> read-only filesystem---the difference to cloop is that the 'read-only'
> part is performed at post-install.  This could be done in a similar way to
> the current LiveCD dm-layer use to provide copy-on-write support into RAM.

I'm not sure I follow you here.  Are you talking about trying to copy the
live CD configuration data to a .deb-based install?  If so, I think that
need would be better served by sharing the debconf database and re-executing
the configuration steps.

> The actual hard-linking of sectors between the cloop-image and the main
> iso9660 filesystem would be done by mkisofs/jigdo both of which currently
> know about this sort of thing to a point, but would need more a bit more
> loving on each part.

I thought about sharing blocks within the filesystem, but in point of fact I
doubt that the iso9660 format would support this.  I haven't checked the
specification, but since all its files are stored contiguously, it has no
reason to store block lists at all.  Also, in any traditional writable
filesystem, files sharing blocks would be considered corruption by any
reasonable implementation.

To clarify my original proposal, what I was discussing was an option for a
Knoppix knx-hdinstall-style installation, based on copying a pre-installed
system.  I think this provides a nice balance of features and simplicity.

-- 
 - mdz