5:46 a.m.
Hi.
A few seem to be interested in getting Kadischi-like stuff fused with
Anaconda.
What we are looking from my point of view is this:
Just enabling a checkbox for building a LiveCD, which would require an
existing Ext2/3 partition to write to.
In this LiveCD payload must include Anaconda which can also from the CD
install to the HDD.
This makes little sense in my opinion, since rootpath doesn't do HDD
partitioning
e.g. to even allow partitioning of a drive, to get a LiveCD written.
Can someone describe some ideas they may have for doing this?
Is there some clarity we can establish here?
J. Hartline
11:59 a.m.
New subject: 7 proposals - was Re: Kadischi - Anaconda
--- "J. Hartline" <jasperhartline(a)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
3:23 p.m.
New subject: 7 proposals - was Re: Kadischi - Anaconda
A few musings:
I've been considering how to create a LiveCD with an installer. I
see two approaches:
(1) reconstruct rpms from the LiveCD filesystem, and do the usual
one-at-a-time install. This is likely to be very slow, because
of seeking.
(2) Group rpms into transaction groups by examining installation
prerequisites and preinstall-scriptlet bounds, and then just
apply pre-install scriptlets, copy files from the live filesystem
and apply the post-install scriptlets.
[ PyRPM might be a good starting point for doing this.]
On one FC5 x86_64 install, there are 72 pre-install scriptlets in 1511
packages. Most of these are of the useradd/groupadd variety. Many
others are applicable when doing upgrades.
In order to do this, one would want the source filesystem that is
being copied to represent the pristine file trees from the RPMS.
That would argue in favor of using something like unionfs to layer
LiveCD specific file customizations over a pristine tree.
On another topic, removing the CD/DVD:
One could use (experimental?) dm-mirror to copy the CD contents in
the background. One could use dm over loop, or there's an experimental
dm-loop module that functions like loop, but requires dmsetup instead
of losetup. Using the dm-mirror module, one could set up a mirror
between a loop from the CD and a loop from some other filesystem; when
the (squashfs) filesystem is done copying, the mirror can be broken,
the CD loop removed, and the CD ejected.
-Bill
4:10 p.m.
New subject: 7 proposals - was Re: Kadischi - Anaconda
Jane Dogalt wrote:
*** proposal 1 ***
*** integrating the current functionality of kadischi directly into anaconda
a) new commandline option --output-livecd=/path/to/destination.iso
It has been suggested to just use rootpath.
What my personal focus is just:
1) Building Live media (CD or DVD)
2) Installing from Live media (CD or DVD)
This would require us to determine without intervention of the user
if we are running from an installed system to build a LiveCD or running
from a LiveCD
to install a system. Rootpath can be used in both of these instances..
if and only if
doing some conditionalizing enable or disable partitioning and
bootloader installation.
The cosmetics of this are probably the touchy part.
I can say myself, that doing some hackery I could determine if I were
being run from
an installed system and build a LiveCD, going through steps as normal,
and also if I am being
run from a LiveCD, and assuming I need to be installing to a system.
I am not so sure however "just doing" these things is going to be a
targeted way of accomplishing this.
I mentioned a check box, e.g not something you can pass to Anaconda to
build the Live media.. as
we wouldn't want this on a standard installation, say from Disc #1.
Fedora Project already has plans
to build and possibly release an Official LiveCD. This assures us the
user is getting what they want.
This requires a subset of menus however and other sections to be added
to Anaconda besides just
making the Squash image, the false root and rolling up an ISO.
On the other hand, detect if we are running from LiveCD media, and the
LiveCD option shouldn't appear.
Use rootpath, and conditionally do partitioning and bootloader setups.
In either case, to do anything that would confirm the operation we are
doing would require some extra
modules and options etc, to be within Anaconda. Otherwise no cosmetic
changes need to be made and
rootpath mode is used exclusively for CD builds, and from-CD installs,
without intervention and with little
options.
I think these are the two major points in using Anaconda solely for both
of these operations.
J. Hartline
4:44 p.m.
New subject: 7 proposals - was Re: Kadischi - Anaconda
--- "Bill Rugolsky Jr." <brugolsky(a)telemetry-investments.com> wrote:
A few musings:
I've been considering how to create a LiveCD with an installer. I
see two approaches:
(1) reconstruct rpms from the LiveCD filesystem, and do the usual
one-at-a-time install. This is likely to be very slow, because
of seeking.
(2) Group rpms into transaction groups by examining installation
prerequisites and preinstall-scriptlet bounds, and then just
apply pre-install scriptlets, copy files from the live filesystem
and apply the post-install scriptlets.
[ PyRPM might be a good starting point for doing this.]
On one FC5 x86_64 install, there are 72 pre-install scriptlets in 1511
packages. Most of these are of the useradd/groupadd variety. Many
others are applicable when doing upgrades.
In order to do this, one would want the source filesystem that is
being copied to represent the pristine file trees from the RPMS.
That would argue in favor of using something like unionfs to layer
LiveCD specific file customizations over a pristine tree.
Another brute force alternative is to just duplicate information, and store the
rpms on the livecd. As we move to dvd and hd-dvd, this may not be so bad.
Expounding on your unionfs musing, one could have many layers in the union. At
the bottom, you could have a pristine @minimal (lets pretend like that still
exists) install, then livecd customizations, then an @desktop layer, etc. Just
a musing though, as I vaguely recall there are signifigant performance
penalties as you get more and more layers in the union.
On another topic, removing the CD/DVD:
One could use (experimental?) dm-mirror to copy the CD contents in
the background. One could use dm over loop, or there's an experimental
dm-loop module that functions like loop, but requires dmsetup instead
of losetup. Using the dm-mirror module, one could set up a mirror
between a loop from the CD and a loop from some other filesystem; when
the (squashfs) filesystem is done copying, the mirror can be broken,
the CD loop removed, and the CD ejected.
I do like this idea, though trying to do serious io multitasking with a cd gets
pretty ugly with seek thrashing. I.e. try doing a dd dump of an iso while the
cd is mounted and you are trying to use it (let alone run a system from it).
Back when I did my early-boot caching, I had my mandrake-8 livecd image down to
135M, so waiting for it to copy wasn't so bad. But I do like the idea. I
suppose if you could effectively renice the mirror so that it truly didn't slow
down the foreground running system, it would work very nicely.
-jdog
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
4:46 p.m.
New subject: 7 proposals - was Re: Kadischi - Anaconda
J. Hartline wrote:
Jane Dogalt wrote:
> *** proposal 1 ***
> *** integrating the current functionality of kadischi directly into
> anaconda
I think these are the two major points in using Anaconda solely for
both of these operations.
Take a look at this patch.. this is what I see as a possibility rather
than trying to (Now) pretend to Anaconda as if we don't need rootpath in
either case.
This will give you a better idea of what I think is plausible, but do
not apply the patch.
From here I think something can be written.
J. Hartline
5:22 p.m.
New subject: 7 proposals - was Re: Kadischi - Anaconda
--- "J. Hartline" <jasperhartline(a)adelphia.net> wrote:
Jane Dogalt wrote:
>*** proposal 1 ***
>*** integrating the current functionality of kadischi directly into anaconda
>
>a) new commandline option --output-livecd=/path/to/destination.iso
>
>
It has been suggested to just use rootpath.
I don't understand this. Currently kadischi is "just using rootpath", and
then
processing the results into a livecd iso.
I'm merely proposing folding kadischi's logic into anaconda.
What my personal focus is just:
1) Building Live media (CD or DVD)
2) Installing from Live media (CD or DVD)
This would require us to determine without intervention of the user
if we are running from an installed system to build a LiveCD or running
from a LiveCD
to install a system.
I see your patch, and I see that it's looking at the host system, but I don't
really understand why.
my proposal #1 (which I'm assuming is what your comments apply to), has nothing
to do with running from a livecd to install a system. It is soley about
running anaconda on some system (fc5 install, fc7 install, debian, customized
knoppix, anything), and generating a livecd .iso output from the input of a
fc5.iso, user-input, and optionally a kickstart and/or user payload. (just like
kadischi does now)
Rootpath can be used in both of these instances..
if and only if
doing some conditionalizing enable or disable partitioning and
bootloader installation.
I'm not suggesting (even in the other props) using rootpath to install from
livecd media. Currently rootpath is the conditional which disables
partitioning.
Really, I'm not personally interested in my props 1-4, though I may try to
implement them at some point. I mainly brought them up as a response to what
the UI should be for kadischi. It seems to me that kadischi is already using
anaconda for the majority of it's UI, and it seems only natural to me to merely
extend anaconda a bit to cover the livecd specific options. I.e. anaconda is
already this huge GUI infrastructure that seems very well suited to the task at
hand. And having both pieces of the UI (traditional system installer, and new
livecd configuration) be part of one seamless app is even more of a win.
Myself, I'm more intrested, at first at least, in my props 5-7, as I intend to
use fully kickstarted GUIless installs for most of my own pursuits. Though a
long long time down the road, when I want to gooify my stuff, anaconda seems
like the obvious place to look to.
If you're still confused by what I'm aiming for, well, hopefully I can show you
what I mean with an iso in the not too distant future.
-jdog
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
12:40 a.m.
New subject: 7 proposals - was Re: Kadischi - Anaconda
Jane Dogalt wrote:
I see your patch, and I see that it's looking at the host system,
but I don't
really understand why.
Well, it was an example.
my proposal #1 (which I'm assuming is what your comments apply
to), has nothing
to do with running from a livecd to install a system. It is soley about
running anaconda on some system (fc5 install, fc7 install, debian, customized
knoppix, anything), and generating a livecd .iso output from the input of a
fc5.iso, user-input, and optionally a kickstart and/or user payload. (just like
kadischi does now)
The focus is to be able to kick out a LiveCD, and from a LiveCD do HDD
installs.
That is generally how Kadischi and Anaconda are related.
I also don't think Debian or Knoppix package Anaconda, which would make
running Anaconda from these systems a non-issue.
I seriously doubt running from a Debian system if they did package
Anaconda is even a factor.
J. Hartline
4:26 p.m.
New subject: 7 proposals - was Re: Kadischi - Anaconda
--- "J. Hartline" <jasperhartline(a)adelphia.net> wrote:
I seriously doubt running from a Debian system if they did package
Anaconda is even a factor.
Yeah, that was kind of a silly example. I was just trying to emphasize what
IMO should be a clear distinction between the system hosting the livecd
generator, and the system being created by it. Ideally I'd like to see the
livecd generator run as a user (not-root), since if you think about it,
generating the bits in the iso file shouldn't require root privs. But I admit
it will be some time before that comes to bear.
-jdog
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
5:33 p.m.
New subject: 7 proposals - was Re: Kadischi - Anaconda
On Sat, 2006-04-01 at 00:40 -0600, J. Hartline wrote:
I seriously doubt running from a Debian system if they did package
Anaconda is even a factor.
Progeny ported Anaconda to run on Debian systems. Everything is
possible.
Rahul
7:20 p.m.
New subject: 7 proposals - was Re: Kadischi - Anaconda
Jane Dogalt wrote:
Ideally I'd like to see the
livecd generator run as a user (not-root), since if you think about it,
generating the bits in the iso file shouldn't require root privs. But I admit
it will be some time before that comes to bear.
I think it would be a bit before that is possible.
There is too much within Anaconda (It's the installer, keep this in mind)
that only root should be doing. A few examples of this are reading files
in /proc/
mounting devices, making device nodes, making links in non
world-writeable directories.. etc.
I'm sure it could be done really-quick-like hacking it all to pieces,
but this will never make it into Anaconda
as a single piece.
So.. anyhow I have kadischi.py now as a module within it contains
definitions for
fromStages1_2(), livecdFromSystem() and systemFromLivecd() which depend on
the sysconfig file readonly-root and the file /.livecd to make these
distinctions.
In this can go most of the other functions that kadischi uses currently.
To keep things "familiar" we also set "kadischi" as an installclass
with
it's respective
gui and text modules called from gui.py and text.py.
The cosmetics of it I think are another issue.
We shouldn't be seeing "Would you like a live CD" screens during normal
installations, which we don't
using kadischi.fromStages1_2().
Any suggestions?
J. Hartline
4:10 a.m.
New subject: 7 proposals - was Re: Kadischi - Anaconda
Rahul Sundaram wrote:
>I seriously doubt running from a Debian system if they did package
>Anaconda is even a factor.
>
>
Progeny ported Anaconda to run on Debian systems. Everything is
possible.
mm Ok.
I still don't believe it is within the "namespace" if you will to cater
to other operating systems. If for instance Debian packagers package
new snapshots of Anaconda.. and Anaconda happens to have some Kadischi
stuff built in
if it doesn't work for Debian systems, I seriously doubt this is a priority.
On the other hand, yes.. anything is possible.
J. Hartline
12:12 p.m.
J. Hartline wrote:
The cosmetics of it I think are another issue.
We shouldn't be seeing "Would you like a live CD" screens during
normal installations, which we don't
using kadischi.fromStages1_2().
Here are a few source files I have now, and some patches.
This is bar far not a final draft, but if we can generate some heat with it
now, it will save me or anyone time in who decides to contribute to
making it happen.
I especially do not like iutil.py patch, albeit I am doing this trying
to disrupt
as little of Anaconda's code as possible.
The two functions in kadischi.py fromStages1_2() and
livecdFromSystem(),systemFromLivecd()
could probably be better. Unfortunately I'm not certain that you have
anything definite to look
for except what I have there, to determine if we are in stage 2, in
which we don't want to appear.
I also do not know Anaconda inside and out, therefore I'm sure I am
replicating some
functions it can do internally, like validifying the installation source
exists.
I did change flc_log from Kadischi to rhpl.log though.
kadischi_text.py and kadischi_gui.py still have yet to be forged.
I really haven't put much thought in kadischi.installSystemFromLiveCD()
since iutil uses /dev/ to create nodes that would already exist. Likewise
we need to have a partitioned disk and it be mounted proper under say
/mnt/sysimage
which is why we don't skip the steps in rootpath for disk partitioning.
Have a look.
Maybe someone can work off this same idea? Make it better no?
J. Hartline
11:08 p.m.
New subject: 7 proposals - was Re: Kadischi - Anaconda
Jane Dogalt wrote:
--- "J. Hartline" <jasperhartline(a)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.
I think one of the proposals was something along the lines of providing
"hd2iso" and "iso2hd" utilities. That would be a cool way to create
bootable DVDs, bootable/restorable system backups, etc.
Just my 2 c.
---
John
1:34 p.m.
New subject: 7 proposals - was Re: Kadischi - Anaconda
--- Skunk Worx <skunkworx(a)verizon.net> wrote:
I think one of the proposals was something along the lines of
providing
"hd2iso" and "iso2hd" utilities. That would be a cool way to create
bootable DVDs, bootable/restorable system backups, etc.
Actually that wasn't really one of my 7 props, or it was buried deep and not
quite in that form. But I'll take the credit if you insist ;). Backups at
least, I was not considering at all. But now that I look at your utility
names, and think about writable hd-dvd capacities, I definately want those type
of lightweight utilities (eventually).
-jdog
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
6590
days inactive
6600
days old
livecd@lists.fedoraproject.org
14 comments
5 participants
participants (5)
-
Bill Rugolsky Jr. -
J. Hartline -
Jane Dogalt -
Rahul Sundaram -
Skunk Worx