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
--
Fedora-livecd-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/fedora-livecd-list
