[Fedora-livecd-list] [RFC/PATCH] livecd rebootless installer

[Douglas McClendon]

Tim Wood wrote:
>> Continuing this thought- if MarkMC's dm-snapshot-merging patch was in the
>> kernel, there could be a button in the live session, such that at any
>> point
>> _long after_ the installation, the user could _opt_ to 'fold in' their
>> live-session modification.  (i.e. hitting the button triggers a
>> dm-snapshot-merge of the tmpfs overlay into the
>> install-destination-drive).
> 
> Hmmm... I'm going to play devil's advocate.  The standard linux boot
> process --at least with Redhat, CentOS and SUSE-- is for a minimal Kernel
> to start that can just do enough to mount a real filesystem and load the
> real kernel.  It then hands over control to the real kernel and dies. 
> Until this post I was assuming --silly me :-)-- that this discussion was
> about something similar.  Since the cluebat didn't get me on this one, can
> someone explain the difference?

Maybe someone needs to hit me with a cluebat if you are right.  From my 
understanding, you are confusing root filesystem with kernel.  Unless of course 
grub these days is based on an embedded linux kernel (which for all I know at 
this instant about grub internals, it might be).

I.e. the standard linux boot process, for redhat and centos (I haven't played 
with suse recently), boots grub, which then pulls /the/ kernel from 
/boot/vmlinuz...., and starts with an initial root filesystem from data stored 
in a gzipped compressed cpio (i.e. /boot/initrd-....).  That initial root 
filesystem has an /init or /sbin/init, which these days is a shell script, which 
handles the process of locating and mounting the real (or shall we just say, the 
next) root filesystem, and then switching to use that.  The switch involves 
something called pivot_root, which does not involve the kernel dying at any point.

There is of course kexec, which could be used to do what you described.  If in 
fact you are correct, that is happening tucked away somewhere that I'm oblivious 
to.  (I kind of doubt it, but I haven't looked at the nash source code recently. 
  nash being the special shell used in internal initrd scripts).


> 
> On another front, my two primary use cases for live media are:
> 
> 1) Handling specific tasks I can't easily handle with one of my existing
> systems.  Insert 10,000 versions of I saved my computer/drive/whatever
> here.  I really don't like Ubuntu _except_ that it handles Mac OS X's hfs
> filesystem brilliantly.  I don't want to run Knoppix on a daily basis but
> it's impressive what I've done to salvage stuff off a hd/floppy/whatever
> that someone's Windows box wouldn't recognize.
> 
> 2) Quick and Dirty dedicated systems.  I've created a number of custom
> live CDs in situations where someone wanted a server to do something
> fairly specific in a hostile environment.  For instance, something to
> handle basic logins and print serving for a windows computer lab.  Because
> the vast majority of the stuff is on non-modifiable media, it almost
> doesn't matter what a malicious user does, the staff can reboot.
> 
> The first case is handled nicely by existing solutions.  The second one is
> a brilliant place for Revisor.  Now that I've gotten something of a handle
> on Revisor, I believe it's going to save me a lot of time fighting Morphix
> and Knoppix.  The thought of using a respin approach to mix and match from
> previous live cds/cf cards is very very appealing.

I completely agree.  Once we have a library of dozens if not hundreds of 
recipes/kickstarts that can be trivially spun to .iso (via one simple 
commandline or gui command), I would expect all these dozens/hundreds of 
hand-built non-errata-updated unmaintainable custom livecd distros to totally 
lose popularity and disappear from significant use.

I think it ought to be possible to just walk down the list of 500+ distributions 
on http://lwn.net/Distributions, and start with the most popular livecds, and 
make kickstarts/recipes for them (equivalent functionality).  Then, they could 
be automatically respun weekly on headless build servers, and you could always 
get one with up-to-date security/bugfix updates.  Or just spun as needed by the 
user if they have the livecd-tools/revisor installed and working.

Total World(livecd) Domination, BwaHaHa...

-dmc/jdog