7 proposals - was Re: [Fedora-livecd-list] Kadischi - Anaconda

[Jane Dogalt]

--- "J. Hartline" <jasperhartline at adelphia.net> wrote:

> Hi.
> A few seem to be interested in getting Kadischi-like stuff fused with 
> Anaconda.

This sounds like me and one of my recent posts :)  From what you wrote, I don't
think you understood what I meant, but then, thats why you asked for clarity. 
So here is an attempt to outline what I meant, which actually covers a few
different proposals which don't need to all be taken together.

*** proposal 1 ***
*** integrating the current functionality of kadischi directly into anaconda

a) new commandline option --output-livecd=/path/to/destination.iso
b) optionally, --livecd-config=/path/to/livecdkickstart.config

(b) is optional because the tokens/config/info contained there could also be
put directly into the normal kickstart or additional anaconda gui installation
steps
 
One way to implement this, would be to have anaconda create it's own temporary
rootpath, and temporary kadischi build directories that the user needn't ever
know exist, other than anaconda complaining about lack of disk space.

Only the absolute minimum of (kadischi like) post install scripts would be run
by anaconda.  Anything else could be user specified/provided by the livecd
kickstart options.

the hard drive partitioning phase of anaconda would be skipped in this
scenario, just as it currently is in kadischis --rootpath invocation

*** proposal 2 ***
*** usage of kadischi, or anaconda+kadischi(proposal1), during a normal
anaconda install.

The output of this, would be perhaps /root/anaconda-livecd.iso in a newly
installed system.  One which perhaps would ideally be identical to what would
be produced by invoking kadischi with the /root/anaconda-ks.cfg which is
currently left by anaconda during a normal install.

The user interface to this, for the first beta/development version of this,
could depend on booting the fedora install cd/dvd with the flag livecdoption
(i.e. isolinux boot: "linux livecdoption", as opposed to say "linux
mediacheck")

If the user enabled this functionality in that way, they would be provided with
an additional anaconda gui step/screen, which had a checkbox for "go ahead and
create livecd image", as well as a selection for the output filename, where
default was /root/anaconda-livecd.iso (or whatever).

Additionally, the user would then see the same additional livecd configuration
steps listed in proposal 1, or would specify them in kickstart.

Implementation-wise, anaconda would go through and do the normal install, and
then, just before rebooting, would use tmp space on the newly installed system
to assemble the livecd iso.

This functionality would involve hdd partitioning, as it is a traditional
fedora install onto harddisk (merely with livecd.iso bonus)

*** proposal 3 ***
*** allow proposal 2 to work, with the normal system installation as an option

This was probably where I started to create confusion.

prop2 requires that anaconda use quite a bit of additional disk space on the
installation system for the assembly, and output of the livecd image.  It is
also using the actual installed system as the image base to produce that livecd
image.

One possibility, is that if sufficient free space exists on the system (say, on
a vfat C:\ filesystem), then the whole process for creating the
/root/anaconda-livecd.iso could be carried in temporary space on C:\, and the
output left in C:\anaconda-livecd.iso.

In this scenario, fedora is not really installed onto the target system.  And
as par the description, no hdd partitioning need ever be done.  The only thing
with the hdd that might need to be done is asking the users permission to use
space on their C:\ partition (or their debian /usr partition, or temporarily
using unpartitioned space, but leaving it that way, ...)

*** proposal 4 ***
*** allow prop2 and/or prop3 to work, and to even burn a copy of the new iso
before ever rebooting

If the user has a cd/dvd burner available that is unused by the installer, then
the output iso could be burned immediately after it is created.

Additionally and optionally, steps could be taken to free up the burner if it
was used to boot the install cd/dvd.  I.e. cache the iso (or needed parts of
it) to ram or disk, so it can be remounted from there, and freeing the drive.

*** proposal 5 ***
*** add a --stateless option to anaconda, to produce output(installations)
which make no assumptions about system hardware, and instead depend on runtime
autoconfiguration of hardware.

Currently I've noticed by default that kadischi output enables firstboot.  I'm
guessing that this is what chitlesh's cd uses for hardware configuration.  I.e.
let the user boot the livecd, and then babysit the hardware configuration every
time.  As opposed to knoppix and other livecds, which attempt to autoconfigure
hardware on every boot, and have stuff 'just work'.

One way to think of this proposal, is to view it as creating fedora
installations that are "physically portable".  I.e. the two big examples are a
target media of a livecd, or a target media of a removable drive (usb
thumbdrive, ipod, etc...).  Then you take this physically portable media, and
boot any system with it, and it autoconfigures hardware at runtime.

Basically the goal of this is to put your workstation on your ipod(or
livecd+ipod, or livecd+thumbdrive), and take it around with you, turning any
system in front of you into a "thick client".

On implementation detail, is that hardware configurations could be cached. 
I.e. no need to probe everything if you can identify the system (say with an
lspci, or looking at the eth mac addr, or both), and have already done the HW
config in the past, and saved that info (naturally wouldn't work on livecd only
media).  This is very much like the microsoft hardware profiles, if of course,
microsoft included all the drivers for all the hardware and automatically
installed and configured them every boot, and never needed to be rebooted to
get drivers to work. (haha)

Another implementation detail, is that this may require tweaking individual
packages, and not only anaconda.  I currently have a bug outstanding with
anaconda --rootpath causing my system to reconfigure it's network and timezone.
 It may be that some individual rpm's postinstall script is tweaking the system
during install.  I would suggest that all rpms obey a convention that if they
see a file /stateless, that they install under the above assumptions.  Actually
this is confusing and should be 2 things.  If they see /rootpath, they should
assume that they are not in a native install, and perhaps are not even running
on a system of the same release.  (i.e. this might be an installation of a fc7
system running on a fc5, or even debian system, therefore they shouldn't try to
do anything to the hardware).  Then, seperate from the rpm being aware if it is
a rootpath install, the rpm should be aware if it is a stateless install, and
if so, should set itself up so that if any hardware configuration needs to be
done, it should be done during every boot.

Note: this is a quite different (but not entirely) usage of the term
'stateless', from the official stateless project of fedora.  It's extending the
concept from the user and system data, into the hardware configuration data
realm.  Of course, note I haven't followed that project closely, so I could be
wrong about that.

*** proposal 6 ***
*** give livecd systems ability to install(or perhaps just cache) themselves to
harddrive

I haven't looked at mandriva one, but they say they do this.

What I have done in the past, is to have linuxrc (early early boot), dump the
iso from the cdrom drive onto temp space on the harddrive (say
C:\dontmindme\foo.iso), and then remount from there.  This frees up the cd
drive for the user, and drastically speeds boot.

If you additionally dump some loadlin stuff in there (or even grub), then the
livecd is now "installed/cached" on the harddrive, and the user can boot it
again without the actual cdrom.

If you are careful, you could even "install/cache" it to a newly created ext3
fs on unpartitioned space, and have what appears to be (and in fact actually
is) a normal installed fedora system.  This is what I would guess mandriva one
is doing.

*** proposal 7 ***
*** use unionfs

This is completely seperate from all the above, and has many wonderous benefits
in countless ways.

-jdog


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com