12:51 a.m.
Hey,
I've spend a little bit of time adapting the OLPC build system to be
able to spit out Fedora livecd's. First some background on what we do in
OLPC
o OLPC is an OS built on Core but also includes bits from Extras and
a dedicated OLPC repository
o Rather than using an installer, we deliver the OS in two ways
- for USB sticks we provide an image that can be copied onto the
whole disk. This image includes a partition table, boot loader
and so forth. This image is also used for qemu.
- For installation to the OLPC hardware, we provide a JFFS2 file
system image that can be put on the flash using nandwrite from
mtd-utils
o The build system must be easy for downstream to use for creating
a derived build of the upstream OLPC distribution. The thinking here
is that OLPC customers (which are governments, countries) are
able to very easily tweak the package selection, provide alternative
packages and change how the system is configured.
o (for more info on OLPC development, see http://dev.laptop.org )
As such, the goals are pretty similar to Live CD: Assemble an OS and put
it on bootable media. So I spent a few days a few weekends ago to do
exactly that; the how's, why's etc. are here
http://gitweb.freedesktop.org/?p=users/david/pilgrim.git;a=blob_plain;h=a...
Specifically, I've made it a goal to make live cd's built with this
infrastructure possible to install to hard disks such as to provide a
nice user experience: you download the livecd and if you like it, you
simply press the "Install" icon on the desktop and the OS is installed
in a matter of minutes. No need to go through anaconda here. The
README.fedora file linked to above contains some pretty specific
information of what we need here. With some hard work perhaps we can
make this happen for FC7.
Another important goal is that it should be easy to create derived CD's.
So if you are into the whole Java and Fedora things, maybe you want to
easily create a Fedora Eclipse livecd. You know, to show off to your
friends. I've included an example here, fedora-eclipse
http://gitweb.freedesktop.org/?p=users/david/pilgrim.git;a=blob;h=e79cc0e...
note how fedora-eclipse is derived from fedora-gnome
http://gitweb.freedesktop.org/?p=users/david/pilgrim.git;a=blob;h=f709bc9...
which in turn is derived from fedora-base
http://gitweb.freedesktop.org/?p=users/david/pilgrim.git;a=blob;h=5d9cb98...
and also that fedora-desktop
http://gitweb.freedesktop.org/?p=users/david/pilgrim.git;a=blob;h=8eac448...
is derived from fedora-base. Ie. we have
fedora-base
|
fedora-gnome
|
+------------+------------+
| |
fedora-eclipse fedora-desktop
There is nothing to prevent us from having
fedora-base
|
+---------------------------------+------------+------...
| |
fedora-gnome fedora-kde
| |
+------------+------------+----------------+---... ....
| | |
fedora-eclipse fedora-desktop fedora-music
in the future. For example, it's not far fetched, I think, to have
people from the tools group in Red Hat maintain the fedora-eclipse live
cd bits (in fact, I'm not even sure if that image builds any more, it
did some weeks ago. But y'all get the point, yes?)
The very nice thing is that downstream, for example fedora-eclipse and
fedora-eclipse-kde, would benefit from general improvements in
fedora-gnome and fedora-kde. The barrier to entry is pretty low, just
look at the simplicity of of the current fedora-eclipse and
fedora-desktop stream definition files.
Anyway, enough talk, it's getting late and I'm too old to miss sleep
these days :-) - Here's a screenshot of the fedora-desktop livecd
http://people.freedesktop.org/~david/fedora-desktop-livecd-20060920.png
and here is an ISO, weighing 618MB, of fedora-desktop
http://olpc.download.redhat.com/olpc/fedora-desktop-davidz-stream-develop...
Have fun,
David
3:05 a.m.
David Zeuthen wrote:
As such, the goals are pretty similar to Live CD: Assemble an OS and
put
it on bootable media. So I spent a few days a few weekends ago to do
exactly that; the how's, why's etc. are here
http://gitweb.freedesktop.org/?p=users/david/pilgrim.git;a=blob_plain;h=a...
Specifically, I've made it a goal to make live cd's built with this
infrastructure possible to install to hard disks such as to provide a
nice user experience: you download the livecd and if you like it, you
simply press the "Install" icon on the desktop and the OS is installed
in a matter of minutes. No need to go through anaconda here. The
README.fedora file linked to above contains some pretty specific
information of what we need here. With some hard work perhaps we can
make this happen for FC7.
You really should use the stock Fedora Core utilities however.
If you are making an installer to system from LiveCD, why not use Anaconda?
Another important goal is that it should be easy to create derived
CD's.
So if you are into the whole Java and Fedora things, maybe you want to
easily create a Fedora Eclipse livecd. You know, to show off to your
friends. I've included an example here, fedora-eclipse
Not really a fan of Java, I'm not sure a Fedora Eclipse LiveCD is the
first item on everyone's Christmas list'
this year. Good work though.
Anyway, enough talk, it's getting late and I'm too old to miss
sleep
these days :-) - Here's a screenshot of the fedora-desktop livecd
http://people.freedesktop.org/~david/fedora-desktop-livecd-20060920.png
and here is an ISO, weighing 618MB, of fedora-desktop
http://olpc.download.redhat.com/olpc/fedora-desktop-davidz-stream-develop...
If OLPC is a "derived" from Redhat or Fedora Core distribution, I really
do not see how this pertains to this list.
On another note, what functionality does this LiveCD stuff you mention
provide over Fedora Core's Kadischi?
If you are unfamiliar with Kadischi, you can find it here:
http://fedoraproject.org/wiki/Kadischi
Available via CVS.
J. Hartline
3:18 a.m.
On 9/20/06, Jasper Hartline <jasperhartline(a)adelphia.net> wrote:
If OLPC is a "derived" from Redhat or Fedora Core
distribution, I really
do not see how this pertains to this list.
On another note, what functionality does this LiveCD stuff you mention
provide over Fedora Core's Kadischi?
If you are unfamiliar with Kadischi, you can find it here:
http://fedoraproject.org/wiki/Kadischi
Available via CVS.
I have asked David to describe a little bit here, so that maybe we
might have some common interest somewhere, and perhaps work together
at some point !
Chitlesh
--
http://clunixchit.blogspot.com
9:43 a.m.
Jasper Hartline wrote:
If OLPC is a "derived" from Redhat or Fedora Core
distribution, I really
do not see how this pertains to this list.
Did you read the README file? This is a LiveCD effort for Fedora. How
does this not pertain to this list?
On another note, what functionality does this LiveCD stuff you
mention
provide over Fedora Core's Kadischi?
David Zeuthen mentioned one feature atleast. Ability to perform a hard
disk installation from the LiveCD.
Rahul
10:44 a.m.
Rahul wrote:
Jasper Hartline wrote:
> If OLPC is a "derived" from Redhat or Fedora Core distribution, I
> really do not see how this pertains to this list.
Did you read the README file? This is a LiveCD effort for Fedora. How
does this not pertain to this list?
No sorry, I just read it was derived on Fedora, and then read "OLPC
LiveCD" in about 10 sentences, I did not read the README first.
Thanks for clarifying.
> On another note, what functionality does this LiveCD stuff you
> mention provide over Fedora Core's Kadischi?
David Zeuthen mentioned one feature atleast. Ability to perform a hard
disk installation from the LiveCD.
You can't partition a disk in any elaborate or elegant way with Yum.
J. Hartline
10:51 a.m.
Jasper Hartline wrote:
>
> David Zeuthen mentioned one feature atleast. Ability to perform a hard
> disk installation from the LiveCD.
You can't partition a disk in any elaborate or elegant way with Yum.
Sorry but you are arguing something nobody has claimed. Again please
just read the README file to understand the plans better.
http://gitweb.freedesktop.org/?p=users/david/pilgrim.git;a=blob_plain;h=a...
Several live cd's support installation to hard disks. It doesnt require
any changes in the package manager to provide this functionality.
Rahul
11:05 a.m.
Rahul wrote:
Jasper Hartline wrote:
>>
>> David Zeuthen mentioned one feature atleast. Ability to perform a
>> hard disk installation from the LiveCD.
>
>
> You can't partition a disk in any elaborate or elegant way with Yum.
>
Sorry but you are arguing something nobody has claimed. Again please
just read the README file to understand the plans better.
http://gitweb.freedesktop.org/?p=users/david/pilgrim.git;a=blob_plain;h=a...
Several live cd's support installation to hard disks. It doesnt
require any changes in the package manager to provide this functionality.
I apologize. I have neglected to boast features that are not ready for
deployment to this list.
I have a LiveCD install;er disc prototype that uses Kadischi and
Anaconda sitting on my hard disk.
I've had several people test it for me, and have reported success, but
it sure is not polished, and is not in the state ready for discussion.
Kadischi is much closer than pilgrim with LiveCD installs to systems,
_trust me_ when I say this.
It also uses Anaconda, so partitioning elaborately, and upgrading, is a
non-issue.
Thanks for the information however, I personally do not mind if Kadischi
falls off the face of the earth.
However I think it is illogical to boast features that are noit even in
development yet.
Just my 2 cents.
J. Hartline
12:02 p.m.
Rahul wrote:
Jasper Hartline wrote:
> Thanks for the information however, I personally do not mind if
> Kadischi falls off the face of the earth.
> However I think it is illogical to boast features that are noit even
> in development yet.
A roadmap != boasting.
I understand, I meant boasting, as in discussing, not having pride over
something already, which doesn't exist.
Bad choice of words on my part. completely.
Sorry for the confusion.
J. Hartline
10:09 a.m.
(adding back fedora-desktop-list as that Cc: field mysteriously
vanished.)
On Wed, 2006-09-20 at 03:05 -0500, Jasper Hartline wrote:
You really should use the stock Fedora Core utilities however.
If you are making an installer to system from LiveCD, why not use Anaconda?
I'd rather ask; Why use anaconda? At the end of the day, installation is
a pretty basic task
- yum install what you want
- write out some configuration files
- perform other post-installation configuration.
So, you know, I'd hate to replace < 100 lines of code by depending on
anaconda, which, I might add, is designed to do far more than the
relatively straightforward task of doing live cd's. I'm not even sure it
makes sense to carry around code in anaconda to facilitate live cd
installs but I'll leave that judgement call to the Anaconda developers.
FWIW, yum works perfectly fine and one goal of the pilgrim effort is to
make the process as robust as possible as well as being able to run on
host OS'es that are not super current. For example, the image I linked
to are built on an x86_64 RHEL4 box (though I had to put yum 2.9.* on
it).
There's also an historical angle here - pilgrim is the successor to the
now defunt olpc-image tools. Anaconda simply didn't allow to be used in
this way.
If OLPC is a "derived" from Redhat or Fedora Core
distribution, I really
do not see how this pertains to this list.
I think Rahul answered this already. I'll also note that this is not a
kadishchi specific list (or at least that's my impression) and several
people have asked me to specifically post my work here.
On another note, what functionality does this LiveCD stuff you
mention
provide over Fedora Core's Kadischi?
If you are unfamiliar with Kadischi, you can find it here:
http://fedoraproject.org/wiki/Kadischi
Available via CVS.
I think there are some key differences
- specifically designed to be able to install the livecd payload on
your hard disk. I've read through the archives of this list and
seen objections from Jeremy and others about the feasibility
of changing Kadischi to facilitate this. Pretty sure there are
few objections to the approach I've taken with pilgrim but I'll
leave Jeremy to comment.
- designed specifically with downstream consumers in mind, e.g. it
must be extremely simple to put together an Fedora Eclipse,
Fedora Music, Fedora Livna Desktop, whatever live cd. This is what
I tried to describe in my original mail.
- r/w root so the OS actually works like it's supposed to (with
the live cd ISO that I linked to you can easy yum install what
you want or perhaps even use pirut)
- Use selinux - ok, so I ran into some issues with enabling this
(see the README.fedora file) so it's disabled in the ISO I linked to.
However, if your build environment matches the target environment
this works nicely. I'll be working on fixing this, certainly OLPC
needs this feature anyway.
- the codebase pilgrim is based on have been used successfully to build
OLPC images for many months now. Pilgrim have now replaced this and
is a critical component of the OLPC release infrastructure. As such,
I and others are committed to maintaining pilgrim for at least this
task.
So these are the key differences I think.
You probably know how it is with software development. People will use
your software in unforeseen ways. As such, as software developers we
tend to make our software prepared to do this. I just happened to
identify a huge overlap between what we're doing in OLPC and what a nice
livecd infrastructure should look like. So I spent a day or two making
pilgrim doing just this.
Hope this clarifies.
David
10:13 a.m.
David Zeuthen wrote:
(adding back fedora-desktop-list as that Cc: field mysteriously
vanished.)
On Wed, 2006-09-20 at 03:05 -0500, Jasper Hartline wrote:
> You really should use the stock Fedora Core utilities however.
> If you are making an installer to system from LiveCD, why not use Anaconda?
I'd rather ask; Why use anaconda? At the end of the day, installation is
a pretty basic task
- yum install what you want
- write out some configuration files
- perform other post-installation configuration.
So, you know, I'd hate to replace < 100 lines of code by depending on
anaconda, which, I might add, is designed to do far more than the
relatively straightforward task of doing live cd's. I'm not even sure it
makes sense to carry around code in anaconda to facilitate live cd
installs but I'll leave that judgement call to the Anaconda developers.
FWIW, yum works perfectly fine and one goal of the pilgrim effort is to
make the process as robust as possible as well as being able to run on
host OS'es that are not super current. For example, the image I linked
to are built on an x86_64 RHEL4 box (though I had to put yum 2.9.* on
it).
There's also an historical angle here - pilgrim is the successor to the
now defunt olpc-image tools. Anaconda simply didn't allow to be used in
this way.
David,
How do you plan on performing upgrades when the live cd gets a install
to hard disk feature?
Rahul
10:53 a.m.
On Wed, 2006-09-20 at 20:43 +0530, Rahul wrote:
How do you plan on performing upgrades when the live cd gets a
install
to hard disk feature?
Well, I've written about that in the README.fedora file. Lemme
cut'n'paste so people can rip it apart. It's basically just a braindump,
I haven't written code for this just yet (patches welcome!).
So.. my plan basically just involves running 'yum -y update' in the
chroot you install to. Not sure we need any UI, some progress feedback
would be nice, not sure if yum can do that already. Seth?
Specifically this means that once you boot into the installed OS all
updates will have been applied. Clearly this requires network
connectivity but such is life. I also expect that it's feasible to do
e.g weekly livecd respins we in four months ppl downloading the "FC6
Desktop" livecd will already get the updates minus perhaps a week. But
they'll be able to update.
- Can probably start writing the scripts and UI that will wrap
libraries
from gnome-diskutil. Suggest this script
This script should
- take some parameters
--target-partition=/dev/sda1
--install-bootloader-at-mbr=true|false
--fs-label=LabelToUseForFS
[--swap-device=/dev/sda2]
--i18n=da_DK.UTF-8
--root-passwd (probably safer to pass it on stdin)
- verify that target partition given is large enough
- dd the ext3 fs over to the target partition
- resize2fs the fs
- mount this at /mnt/target
- delete files specific to livecd; that is
- /mnt/target/etc/udev/rules.d/00-livecd.rules
- /mnt/target/etc/init.d/livecd
- /mnt/target/etc/rc5.d/livecd
- (TODO: keep this list in sync with script and with what junk
we put in the pristine ext3 fs.)
- rewrite /mnt/target/etc/sysconfig/i18n
- rewrite /mnt/target/etc/fstab (if no swap device is given use
a swap file on the target fs. No, Swap Files Are Not Evil(tm),
get over it :-)
- run /sbin/mkinitrd in the /mnt/target chroot
- set the root password
- touch a file on /mnt/target so firstboot is run (TODO: need to
either put firstboot on the live cd or make firstboot redundant.)
- write /mnt/target/boot/grub/grub.conf
- run /sbin/grub-install from /mnt/target/ chroot
- run 'yum update' in the /mnt/target chroot if we have network
connectivity. This is to update the installed OS with the latest
security / feature patches etc. etc.
- probably need to include yum-updatesd but disable at livecd usage
since the install system will need it
Also
- script should be invoked via a D-BUS system bus service so the
GUI bits for doing the install become trivial
- provide reasonable progress feedback / error reporting
- need to write this tool with paranoia in mind; we're talking about
messing with people's data here
Cheers,
David
12:19 p.m.
On Wed, 2006-09-20 at 11:53 -0400, David Zeuthen wrote:
On Wed, 2006-09-20 at 20:43 +0530, Rahul wrote:
> How do you plan on performing upgrades when the live cd gets a install
> to hard disk feature?
Well, I've written about that in the README.fedora file. Lemme
cut'n'paste so people can rip it apart. It's basically just a braindump,
I haven't written code for this just yet (patches welcome!).
So.. my plan basically just involves running 'yum -y update' in the
chroot you install to. Not sure we need any UI, some progress feedback
would be nice, not sure if yum can do that already. Seth?
Specifically this means that once you boot into the installed OS all
updates will have been applied. Clearly this requires network
connectivity but such is life. I also expect that it's feasible to do
Right; we certainly can't fit all Fedora Core packages on one LiveCD,
since a LiveCD is obviously only _one_ CD. So you'd never be able to
upgrade off packages from a CD. Furthermore with Extras its highly
likely that people have packages from Extras, and that doesn't fit on a
CD either.
About the only reasons you might _ever_ want to update from a LiveCD are
(a) to test your hardware with the new kernel, and to (b) see what new
apps and features are around, before you actually do the update. I
don't see what is all that useful about doing the actual update from
from the LiveCD itself though, versus rebooting and running a small tool
to pull down new .repo files and doing the equivalent of 'yum update'
which other tools already do for us.
What's the use-case here for update from a LiveCD anyway? Why?
Dan
e.g weekly livecd respins we in four months ppl downloading the
"FC6
Desktop" livecd will already get the updates minus perhaps a week. But
they'll be able to update.
> - Can probably start writing the scripts and UI that will wrap libraries
> from gnome-diskutil. Suggest this script
> This script should
> - take some parameters
> --target-partition=/dev/sda1
> --install-bootloader-at-mbr=true|false
> --fs-label=LabelToUseForFS
> [--swap-device=/dev/sda2]
> --i18n=da_DK.UTF-8
> --root-passwd (probably safer to pass it on stdin)
> - verify that target partition given is large enough
> - dd the ext3 fs over to the target partition
> - resize2fs the fs
> - mount this at /mnt/target
> - delete files specific to livecd; that is
> - /mnt/target/etc/udev/rules.d/00-livecd.rules
> - /mnt/target/etc/init.d/livecd
> - /mnt/target/etc/rc5.d/livecd
> - (TODO: keep this list in sync with script and with what junk
> we put in the pristine ext3 fs.)
> - rewrite /mnt/target/etc/sysconfig/i18n
> - rewrite /mnt/target/etc/fstab (if no swap device is given use
> a swap file on the target fs. No, Swap Files Are Not Evil(tm),
> get over it :-)
> - run /sbin/mkinitrd in the /mnt/target chroot
> - set the root password
> - touch a file on /mnt/target so firstboot is run (TODO: need to
> either put firstboot on the live cd or make firstboot redundant.)
> - write /mnt/target/boot/grub/grub.conf
> - run /sbin/grub-install from /mnt/target/ chroot
> - run 'yum update' in the /mnt/target chroot if we have network
> connectivity. This is to update the installed OS with the latest
> security / feature patches etc. etc.
> - probably need to include yum-updatesd but disable at livecd usage
> since the install system will need it
> Also
> - script should be invoked via a D-BUS system bus service so the
> GUI bits for doing the install become trivial
> - provide reasonable progress feedback / error reporting
> - need to write this tool with paranoia in mind; we're talking about
> messing with people's data here
Cheers,
David
12:34 p.m.
Dan Williams wrote:
On Wed, 2006-09-20 at 11:53 -0400, David Zeuthen wrote:
> On Wed, 2006-09-20 at 20:43 +0530, Rahul wrote:
>> How do you plan on performing upgrades when the live cd gets a install
>> to hard disk feature?
> Well, I've written about that in the README.fedora file. Lemme
> cut'n'paste so people can rip it apart. It's basically just a braindump,
> I haven't written code for this just yet (patches welcome!).
>
> So.. my plan basically just involves running 'yum -y update' in the
> chroot you install to. Not sure we need any UI, some progress feedback
> would be nice, not sure if yum can do that already. Seth?
>
> Specifically this means that once you boot into the installed OS all
> updates will have been applied. Clearly this requires network
> connectivity but such is life. I also expect that it's feasible to do
Right; we certainly can't fit all Fedora Core packages on one LiveCD,
since a LiveCD is obviously only _one_ CD. So you'd never be able to
upgrade off packages from a CD. Furthermore with Extras its highly
likely that people have packages from Extras, and that doesn't fit on a
CD either.
About the only reasons you might _ever_ want to update from a LiveCD are
(a) to test your hardware with the new kernel, and to (b) see what new
apps and features are around, before you actually do the update. I
don't see what is all that useful about doing the actual update from
from the LiveCD itself though, versus rebooting and running a small tool
to pull down new .repo files and doing the equivalent of 'yum update'
which other tools already do for us.
This method is not widely documented or easy to use yet AFAIK.
What's the use-case here for update from a LiveCD anyway? Why?
Basically. My interest in having a install/upgrade from a Live CD is
directly related to http://fedoraproject.org/wiki/Distribution/FreeMedia.
Fedora is currently 5 CD's/ One DVD and this is expected to grow once
when have Fedora Extras on the media too which might be as soon as FC7
since its kind of a prerequisite for this -
http://fedoraproject.org/wiki/UnleashKDE. In effect we might see the
number of CD's double or even more.
A useful desktop set requires the first two CD's in Fedora through the
Anaconda method and you can only perform a minimalistic installation
from a single CD. Currently we are distributing DVD's in Free media
program instead which is a problem in many regions where DVD drivers and
media is costly and not widely used. Magazines and books prefer to
distribute distributions which have a single CD more often to reduce
their costs. There is also a perception of "bloat" related to the number
of CD's.
In events and for Freemedia distributions it would much more effective
to hand out a single live CD with a hard disk installation feature. Of
course people might want more software and they would have to grab it
off the internet or some other distribution mechanism but a single
installalable live CD covers the typical use case and promotional needs.
Once this method is propagated and commonly used, users would already
have installations which they would want to upgrade later. Having this
functionality in a Live CD would mean that I could just forget about
Anaconda in Fedora and stick with a Live CD for all my needs which is
confined to a desktop and grabbing stuff on demand off the network.
Rahul
1:40 p.m.
On Wed, 2006-09-20 at 23:04 +0530, Rahul wrote:
Dan Williams wrote:
> On Wed, 2006-09-20 at 11:53 -0400, David Zeuthen wrote:
>> On Wed, 2006-09-20 at 20:43 +0530, Rahul wrote:
>>> How do you plan on performing upgrades when the live cd gets a install
>>> to hard disk feature?
>> Well, I've written about that in the README.fedora file. Lemme
>> cut'n'paste so people can rip it apart. It's basically just a
braindump,
>> I haven't written code for this just yet (patches welcome!).
>>
>> So.. my plan basically just involves running 'yum -y update' in the
>> chroot you install to. Not sure we need any UI, some progress feedback
>> would be nice, not sure if yum can do that already. Seth?
>>
>> Specifically this means that once you boot into the installed OS all
>> updates will have been applied. Clearly this requires network
>> connectivity but such is life. I also expect that it's feasible to do
>
> Right; we certainly can't fit all Fedora Core packages on one LiveCD,
> since a LiveCD is obviously only _one_ CD. So you'd never be able to
> upgrade off packages from a CD. Furthermore with Extras its highly
> likely that people have packages from Extras, and that doesn't fit on a
> CD either.
>
> About the only reasons you might _ever_ want to update from a LiveCD are
> (a) to test your hardware with the new kernel, and to (b) see what new
> apps and features are around, before you actually do the update. I
> don't see what is all that useful about doing the actual update from
> from the LiveCD itself though, versus rebooting and running a small tool
> to pull down new .repo files and doing the equivalent of 'yum update'
> which other tools already do for us.
This method is not widely documented or easy to use yet AFAIK.
>
> What's the use-case here for update from a LiveCD anyway? Why?
>
Basically. My interest in having a install/upgrade from a Live CD is
directly related to http://fedoraproject.org/wiki/Distribution/FreeMedia.
Fedora is currently 5 CD's/ One DVD and this is expected to grow once
when have Fedora Extras on the media too which might be as soon as FC7
since its kind of a prerequisite for this -
http://fedoraproject.org/wiki/UnleashKDE. In effect we might see the
number of CD's double or even more.
Right; I'm not questioning the use of a LiveCD _install_. I completely
agree there. I'm questioning the use of a LiveCD _upgrade_.
dan
A useful desktop set requires the first two CD's in Fedora
through the
Anaconda method and you can only perform a minimalistic installation
from a single CD. Currently we are distributing DVD's in Free media
program instead which is a problem in many regions where DVD drivers and
media is costly and not widely used. Magazines and books prefer to
distribute distributions which have a single CD more often to reduce
their costs. There is also a perception of "bloat" related to the number
of CD's.
In events and for Freemedia distributions it would much more effective
to hand out a single live CD with a hard disk installation feature. Of
course people might want more software and they would have to grab it
off the internet or some other distribution mechanism but a single
installalable live CD covers the typical use case and promotional needs.
Once this method is propagated and commonly used, users would already
have installations which they would want to upgrade later. Having this
functionality in a Live CD would mean that I could just forget about
Anaconda in Fedora and stick with a Live CD for all my needs which is
confined to a desktop and grabbing stuff on demand off the network.
But it's not clear to me why you'd want to upgrade from a LiveCD rather
than just boot into your already-installed image and do a 'yum upgrade'.
There's _nothing_ that a LiveCD-based install process would consist of
other than a 'yum upgrade', except that you're running off the livecd.
I guess there is a 'seamless' aspect to this, such that you can use the
same CD for both the update payload (the new .repo files) and test the
hardware in the same bootup. I'm not sure if the small benefit of doing
everything in the same boot outweighs the disadvantage of complicating
the CD with update logic which could just as easily be done in the real
system, since both LiveCD and real system would end up running 'yum
upgrade' anyway.
Dan
1:45 p.m.
Dan Williams wrote:
But it's not clear to me why you'd want to upgrade from a
LiveCD rather
than just boot into your already-installed image and do a 'yum upgrade'.
There's _nothing_ that a LiveCD-based install process would consist of
other than a 'yum upgrade', except that you're running off the livecd.
I guess there is a 'seamless' aspect to this, such that you can use the
same CD for both the update payload (the new .repo files) and test the
hardware in the same bootup. I'm not sure if the small benefit of doing
everything in the same boot outweighs the disadvantage of complicating
the CD with update logic which could just as easily be done in the real
system, since both LiveCD and real system would end up running 'yum
upgrade' anyway.
Yum upgrading from Core to Core is not recommended without using Anaconda.
This among other things not apparent to most users of this list at this
time, is my major
reasoning for asking why not use Anaconda.
An upgrade from LiveCD with Anaconda is seemless.
I don't have to make sense of it however. I just know what does make sense.
J. Hartline
1:50 p.m.
Dan Williams wrote:
But it's not clear to me why you'd want to upgrade from a
LiveCD rather
than just boot into your already-installed image and do a 'yum upgrade'.
There's _nothing_ that a LiveCD-based install process would consist of
other than a 'yum upgrade', except that you're running off the livecd.
Well you to have go grab fedora-release from the latest Fedora, install
it and then run yum upgrade and pray that it works. We havent made it
very simple nor do we test it explicitly for every release that things
work well after a yum upgrade.
If we make this very simple for a new user to follow, then maybe we
wouldnt need a upgrade through live cd option. Currently, thats not the
case.
Rahul
2:46 p.m.
On Wed, 2006-09-20 at 13:19 -0400, Dan Williams wrote:
What's the use-case here for update from a LiveCD anyway? Why?
I think the question was about upgrading the packages _from_ the livecd
when they are installed (if you have an old livecd); not about using the
livecd to upgrade an existing installation. For the latter you'd just be
using yum [1].
David
[1] : Or anaconda... until we fix Fedora etc. to support upgrades from
e.g. FC5 -> FC6 using yum - something we badly need anyway and hardly
any news
3:40 a.m.
New subject: Question on bootable Mac Images.
Hello,
I have a question that may seem very basic for you. I am having
trouble on
my PowerBook G4 Mac to burn a mac bootable CD for Fedora.
I checked the sha1sum and it was correct. I tried to reload from
another site
and it still did not work. The iso image simply does not seem to be
bootable.
I was advised to look for a dedicated ppc maillist for fedora but was
unable
to find such a list or entry point, so I am asking if someone on this
maillist
knows an entry point to such a list.
Thank you
Sincerely,
Jean Casteres
4:01 a.m.
New subject: Question on bootable Mac Images.
On 9/23/06, Jean Casteres <jeancasteres(a)free.fr> wrote:
Hello,
I have a question that may seem very basic for you. I am having
trouble on
my PowerBook G4 Mac to burn a mac bootable CD for Fedora.
My question will be is it a live CD build with kadischi? In the past,
some ISOs built with kadischi were not bootable .
I checked the sha1sum and it was correct. I tried to reload from
another site
and it still did not work. The iso image simply does not seem to be
bootable.
Can you try with qemu or vmware to see whether it boots or not ?
Chitlesh
--
http://clunixchit.blogspot.com
10:29 a.m.
On Wed, 20 Sep 2006, David Zeuthen wrote:
> If OLPC is a "derived" from Redhat or Fedora Core
distribution, I really
> do not see how this pertains to this list.
I think Rahul answered this already. I'll also note that this is not a
kadishchi specific list (or at least that's my impression) and several
people have asked me to specifically post my work here.
Yes. In fact, I hounded David relentlessly for a couple of weeks to
publicize his work here, because I think it's excellent.
It's natural to be skeptical of new code, but bear these facts in mind:
1. PRIORITY.
Kadischi is heavily reliant upon Anaconda. Anaconda's functionally is a
large superset of Kadischi's. Anaconda also has significant *business*
pressures on its roadmap. Kadischi patches are, therefore, low priority
for Anaconda developers.
Pilgrim, on the other hand, performs *extremely* similar tasks for OLPC.
OLPC must be imaged very simply, and very uniformly. A Live CD/Live DVD
is the same.
2. INSTALL FUNCTIONALITY.
If there's one place where Ubuntu has an *actual* lead on us, it's in
their ability to install a Live CD directly to a system. From what I've
seen, we're closer to closing that gap with Pilgrim than we are with
Kadischi.
3. COMMUNITY DEVELOPMENT.
I'd like to see the prominent developers on this list -- Chitlesh, Jasper,
jdog, and others I've surely left out -- have commit access. With
Anaconda, that simply can't happen. With Pilgrim, it might.
===
These three facts, in my mind, are reason enough to ask the Fedora Live CD
community to consider the benefits of Pilgrim. If we want to develop the
two technologies side-by-side, that's fine too. But this is the
fedora-livecd-list -- *not* the kadischi list.
--g
-------------------------------------------------------------
Greg DeKoenigsberg || Fedora Project || fedoraproject.org
Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors
-------------------------------------------------------------
3:40 p.m.
On Wed, 2006-09-20 at 11:29 -0400, Greg DeKoenigsberg wrote:
I'd like to see the prominent developers on this list --
Chitlesh, Jasper,
jdog, and others I've surely left out -- have commit access. With
Anaconda, that simply can't happen. With Pilgrim, it might.
Sure, I'm all for that and am hopeful to get contributors besides
myself. Would have to review patches etc. on list since other projects
such as OLPC depends on pilgrim. But that's no different from other open
source projects.
The first step towards that, and something I'd like anyway, is moving
the pilgrim git repository from my home directory on freedesktop.org to
Fedora infrastructure. Any pointers to how I do that? Thanks.
David
5:31 p.m.
On 9/20/06, David Zeuthen <davidz(a)redhat.com> wrote:
Sure, I'm all for that and am hopeful to get contributors
besides
myself. Would have to review patches etc. on list since other projects
such as OLPC depends on pilgrim. But that's no different from other open
source projects.
After reading all these mails :), i'll tend to say that pilgrim's yum
approach sounds great. Yum's new metaparser might play a great role as
well. However, anaconda provides kickstart file feature to kadischi
and this is greatly used by people in the fedora-livecd list.
Sure, I'm not saying that kadischi has to adapt itself to pilgrim's
theory. But since, kadischi is only maintained for the moment by
Jasper and I at a very slow rate, it would be best to consider on what
* what is Kadischi, by the Fedora Project
* which one should be a Fedora Live image Creator/Installer
* how both pilgrim and kadischi can benefit.
Ill try pilgrim this weekend.
The first step towards that, and something I'd like anyway, is
moving
the pilgrim git repository from my home directory on freedesktop.org to
Fedora infrastructure. Any pointers to how I do that? Thanks.
is it possible to have under svn ? :p i've cvs access blocked over my place.
David, is your presentations available for download ? I'll like to
have a look at them :)
Chitlesh
--
http://clunixchit.blogspot.com
3:16 p.m.
On Thu, 2006-09-21 at 00:31 +0200, Chitlesh GOORAH wrote:
Ill try pilgrim this weekend.
Thanks!
> The first step towards that, and something I'd like anyway,
is moving
> the pilgrim git repository from my home directory on freedesktop.org to
> Fedora infrastructure. Any pointers to how I do that? Thanks.
>
is it possible to have under svn ? :p i've cvs access blocked over my place.
Oh, I'm suggesting to use git. That, AFAIK, can be tunneled over ssh
which shouldn't be a problem from your place? (I think it can also be
tunneled over http, not sure.)
David, is your presentations available for download ? I'll like
to
have a look at them :)
Presentations? Do you mean the ISO, that one is here
http://olpc.download.redhat.com/olpc/fedora-desktop-davidz-stream-develop...
or anything else?
Cheers,
David
5:07 p.m.
On 9/20/06, Greg DeKoenigsberg <gdk(a)redhat.com> wrote:
These three facts, in my mind, are reason enough to ask the Fedora
Live CD
community to consider the benefits of Pilgrim. If we want to develop the
two technologies side-by-side, that's fine too. But this is the
fedora-livecd-list -- *not* the kadischi list.
This was the main reason why I've asked Fedora Board to ping David for
more info about pilgrim in this list ! :)
Chitlesh
--
http://clunixchit.blogspot.com
8:19 a.m.
On 9/20/06, Greg DeKoenigsberg <gdk(a)redhat.com> wrote:
These three facts, in my mind, are reason enough to ask the Fedora
Live CD
community to consider the benefits of Pilgrim. If we want to develop the
two technologies side-by-side, that's fine too. But this is the
fedora-livecd-list -- *not* the kadischi list.
Great words :)
Yes, this is not a kadischi list, and I welcome David or pilgrim users
to continue discuussions here, in this list.
Actually, i'll think 2 different mechanisms output the same product,
is a waste !
For the past 3 days, we have talked and talked. SO WHAT IS NEXT ?
The kadischi's development community isn't that huge, 3 at most. And
soon we will have 4 mechanism for creating fedora livecds.
- Kadischi
- pilgrim
- Jeremy's code
- Jane Dogalt's work
To my guess, the last three has one developper ? That makes us around
6 working for the same output, a fedora livecd!
Thus, why not work together to make something _centralized_ ? Just
like fedora likes to do.
I've been to the Kadischi Project since January, and I feel our goals
are fading away due to lack of communcation with other fedora
projects.
Rahul did reveal something, a LiveCD can be used for:
- Freemedia, lower the expenses (Max would be happy)
- unleashKDE, more contributors to KDE (i'll be happy and Rex too:) )
Can we make kadischi a centralized tool for livecd generation but with plugins ?
By plugins, I mean
kadischi package:
- /usr/bin/kadischi-pilgrim
- /usr/bin/kadischi-anaconda
- kadischi core
- post install scripts
Both certainly have the same core and similar post -install scripts,
but the methods vary.
/usr/bin/kadischi-pilgrim calls for core and uses yum and doesn't
depends on anaconda and finally uses common post install scripts .
Output a livecd image
if /usr/bin/kadischi-anaconda calls for core and uses anaconda and
finally uses common post install scripts . Output a livecd image.
Hence, we all can work on "kadischi core" and both David and Jasper
will be happy (I guess).
David, do you think that this may be posssible with the OLPC project.
Jasper, what do you think about it ?
Just like anaconda, kadischi does have some *business* interest :) by
its users. Some of kadischi's users use it for their own small
business and they are subcribed to this list.
What you guys think about it ?
Chitlesh
--
http://clunixchit.blogspot.com
8:33 a.m.
Chitlesh GOORAH wrote:
David, do you think that this may be posssible with the OLPC
project.
Jasper, what do you think about it ?
I can't comment at this point because I know nothing about pilgrim.
I don't know it's code, just it's design goals, which is duplicated by
Kadischi.
I don't remember who said it, that pilgrim is closer to a
LiveCD-to-system installer
but of course that statement comes from my lack of notifying the list of
new Kadischi breakthroughs.
I am working with pnasrat currently to straighten out a threading bug I
assume is what it is in Anaconda
and as soon as this is fixed, if it is fixed a real installer disc will
be deployable with the intention to polish it.
In many ways sand in the LiveCD case, pilgrim duplicates Kadischi
functionality.
I see no sense in writing your own tools to do LiveCD-to-System installs
when you could use Anaconda.
We should have a Kadischi built, with Kadischi and Anaconda as payload
LiveCD-to-system installer disc shortly.
Just like anaconda, kadischi does have some *business* interest :) by
its users. Some of kadischi's users use it for their own small
business and they are subcribed to this list.
Well as you know we've been contacted on teh list at least two times one
by a business owner and one by
a school board member or other educational entity in the hopes to build
mirror image LiveCD systems.
Kadischi being able to install to these systems if someone likes it by
"Pressing the install button" is close on the horizon.
J. Hartline
3:11 p.m.
On Sat, 2006-09-23 at 08:33 -0500, Jasper Hartline wrote:
I don't know it's code, just it's design goals, which is
duplicated by
Kadischi.
Not to flame or anything, but I think the design goals of pilgrim is a
strict superset of the Kadischi goals. Sure, your goals can change, I'm
not too interested in discussing semantics so...
Btw, I also posted a link to the git repo
http://gitweb.freedesktop.org/?p=users/david/pilgrim.git
It's not really that much code.
We should have a Kadischi built, with Kadischi and Anaconda as
payload
LiveCD-to-system installer disc shortly.
Sounds interesting, can you elaborate a bit on what the user experience
will be? For example,
- Will I be able to partition the system using LVM / Raid / etc.?
- Do you support SELinux? Or the livecd? On the installed payload? If
yes, does this require a relabel post-install?
- Will Kadischi use a rw rootfs on the livecd?
David
4:18 p.m.
David Zeuthen wrote:
Sounds interesting, can you elaborate a bit on what the user
experience
will be? For example,
- Will I be able to partition the system using LVM / Raid / etc.?
You will be able to partition your disks in every way Anaconda currently
does.
LVM, RAID, Ext2/3 SWAP, however you want.
- Do you support SELinux? Or the livecd? On the installed payload?
If
yes, does this require a relabel post-install?
SELinux is not an option in Anaconda as far as I know it is a default.
No, the LiveCD will not be copied to the installed system. It would be
unnecessary.
- Will Kadischi use a rw rootfs on the livecd?
It'll use teh currentl Kadischi code which is to bind mount required
directories.
You don't need a rw rootfs to do system installs.
J. Hartline
5:20 p.m.
On Sat, 2006-09-23 at 16:18 -0500, Jasper Hartline wrote:
> - Do you support SELinux? Or the livecd? On the installed
payload? If
> yes, does this require a relabel post-install?
>
SELinux is not an option in Anaconda as far as I know it is a default.
No, the LiveCD will not be copied to the installed system. It would be
unnecessary.
So, I'm unsure exactly how this works. Do you simply invoke anaconda to
do an install?
Where do you get the RPM's you install on the hard disk from?
Does this require network connectivity?
> - Will Kadischi use a rw rootfs on the livecd?
>
>
It'll use teh currentl Kadischi code which is to bind mount required
directories.
You don't need a rw rootfs to do system installs.
Nope, but having a rw rootfs is pretty nice for other reasons.
Such as being able to install software while running from the livecd,
not having to maintain a magic list of where existing software wants to
write to etc. etc.
David
5:27 p.m.
David Zeuthen wrote:
On Sat, 2006-09-23 at 16:18 -0500, Jasper Hartline wrote:
>> - Do you support SELinux? Or the livecd? On the installed payload? If
>> yes, does this require a relabel post-install?
>>
>>
> SELinux is not an option in Anaconda as far as I know it is a default.
> No, the LiveCD will not be copied to the installed system. It would be
> unnecessary.
>
So, I'm unsure exactly how this works. Do you simply invoke anaconda to
do an install?
Where do you get the RPM's you install on the hard disk from?
Does this require network connectivity?
Yes, simply invoking Anaconda brings up Anaconda.
The RPMs can come from the network if it is a LiveCD, and presumably
from the network
or from the DVD if it is a LiveDVD.
It requires network connectivity in the LiveCD case, yes.. and for the
LiveDVD unless
Fedora Core repository is provided on disc.
>> - Will Kadischi use a rw rootfs on the livecd?
>>
>>
>>
> It'll use teh currentl Kadischi code which is to bind mount required
> directories.
> You don't need a rw rootfs to do system installs.
>
Nope, but having a rw rootfs is pretty nice for other reasons.
Such as being able to install software while running from the livecd,
not having to maintain a magic list of where existing software wants to
write to etc. etc.
As far as I know UnionFS is the only thing feasible for doing this.
Bill Nottingham has already stated testing has produced deadlocks and
crashes in the simplest of cases.
What were you planning on doing to create a read-write rootfs?
J. Hartline
5:45 p.m.
On Sat, 2006-09-23 at 17:27 -0500, Jasper Hartline wrote:
> Does this require network connectivity?
>
Yes, simply invoking Anaconda brings up Anaconda.
The RPMs can come from the network if it is a LiveCD, and presumably
from the network
or from the DVD if it is a LiveDVD.
It requires network connectivity in the LiveCD case, yes.. and for the
LiveDVD unless
Fedora Core repository is provided on disc.
I see. Sorry, but I think this is a little backwards, I mean, why
wouldn't I just download the install CD's; it's pretty much the same
amount of traffic.
Also keep in mind that many consumers of live cd's (typically in poor
countries) have zero network connectivity - all they have is a live cd
that some benevolent organization sent them. Like Ubuntu's ship it.
The approach I have in mind includes just reusing the ext3 file system
we have already prepared and just dd that onto the target installation
block device. That way an install would take very little time and the
only thing you need to make this work is the live cd itself.
The very reason this will work is that I make almost zero changes to the
live cd rootfs to get the livecd approach going:
- I don't modify any files
- I only add a three files
/etc/init.d/livecd
/etc/rc5.d/S00livecd
/etc/udev/rules.d/00-livecd.rules
The reason I can get away with making _only_ these changes is that the
rootfs is rw - the bulk of the work is in the livecd init script.
So, I think this is a vastly superior approach - what do you think?
> Nope, but having a rw rootfs is pretty nice for other reasons.
>
> Such as being able to install software while running from the livecd,
> not having to maintain a magic list of where existing software wants to
> write to etc. etc.
>
>
As far as I know UnionFS is the only thing feasible for doing this.
You can use dm-snapshot, see the README.fedora file in the pilgrim
repository here
http://gitweb.freedesktop.org/?p=users/david/pilgrim.git;a=blob;hb=HEAD;f...
specifically the section "LIVECD, HOW IT WORKS" around line 40.
It works extremely well.
See the pilgrim sources for details.
Bill Nottingham has already stated testing has produced deadlocks and
crashes in the simplest of cases.
Yea, unionfs has some issues. Despite that it appears Ubuntu is using
that so I think Bill just used an old version. I haven't bothered to try
myself.
What were you planning on doing to create a read-write rootfs?
So, pilgrim does this already (as described above) and is in the ISO I
linked to in my first mail to the list. From the live cd, you can easily
do 'yum install xyz' and it just works. You should try it out!
David
6:40 p.m.
David Zeuthen wrote:
On Sat, 2006-09-23 at 17:27 -0500, Jasper Hartline wrote:
>> Does this require network connectivity?
>>
>>
> Yes, simply invoking Anaconda brings up Anaconda.
> The RPMs can come from the network if it is a LiveCD, and presumably
> from the network
> or from the DVD if it is a LiveDVD.
>
> It requires network connectivity in the LiveCD case, yes.. and for the
> LiveDVD unless
> Fedora Core repository is provided on disc.
>
I see. Sorry, but I think this is a little backwards, I mean, why
wouldn't I just download the install CD's; it's pretty much the same
amount of traffic.
I'll leave you to debate the difference between a router style 550MB
install and a full blown everything
chosen 7GB install. I'm sure a calculator isn't necessary to see the
difference.
Also keep in mind that many consumers of live cd's (typically in
poor
countries) have zero network connectivity - all they have is a live cd
that some benevolent organization sent them. Like Ubuntu's ship it.
The approach I have in mind includes just reusing the ext3 file system
we have already prepared and just dd that onto the target installation
block device. That way an install would take very little time and the
only thing you need to make this work is the live cd itself.
This is extremely unflexible and the user is limited to what you've
mastered onto the LiveCD
without yum installing xyz all day long, which they don't even know exists.
With Anaconda it is a familiar, flexible, choosable option, package
selectable interface
along with that upgrading the system from Core to Core is a snap, using
Anaconda.
J. Hartline
7:19 p.m.
On Sat, 2006-09-23 at 18:40 -0500, Jasper Hartline wrote:
> I see. Sorry, but I think this is a little backwards, I mean,
why
> wouldn't I just download the install CD's; it's pretty much the same
> amount of traffic.
>
I'll leave you to debate the difference between a router style 550MB
install and a full blown everything
chosen 7GB install. I'm sure a calculator isn't necessary to see the
difference.
I'm not sure what point you are trying to make here.
> Also keep in mind that many consumers of live cd's
(typically in poor
> countries) have zero network connectivity - all they have is a live cd
> that some benevolent organization sent them. Like Ubuntu's ship it.
>
> The approach I have in mind includes just reusing the ext3 file system
> we have already prepared and just dd that onto the target installation
> block device. That way an install would take very little time and the
> only thing you need to make this work is the live cd itself.
>
This is extremely unflexible and the user is limited to what you've
mastered onto the LiveCD
Excuse me? How is this different from Kadishchi built live CD's? CD
space is limited.
(Oh, sure, it's different insofar that you don't support installing
software while the live cd is running - and, you know, this may be the
crucial point of people deciding to install Fedora - that they can try
and see if their favorite piece of software is actually available before
installing Fedora onto their hard disk.)
without yum installing xyz all day long, which they don't even
know exists.
Pirut is included on my live CD and will, as such, be included on the
hard disk when doing OS installs.
With Anaconda it is a familiar, flexible, choosable option, package
selectable interface
along with that upgrading the system from Core to Core is a snap, using
Anaconda.
Oh, I see, it sounds like you're making the point that the Anaconda
package selector is better than Pirut. If so the Pirut authors better
fix this.
I'm not really sure who you are designing for here and it sounds like
you are not sure yourself either. I think that important goals of a live
CD should be
1. Installable without requiring a network
(since many potential users will have little or no network
connectivity, cf. distributions to poor countries.)
2. Ability to install / try out software before installing the livecd
to their hard disk.
(to let people see if the apps they need are available)
3. Contains all software the user base you are trying to target wants
(why it's good to easily be able to build different flavors, e.g.
GNOME desktop, KDE desktop, Eclipse, Music, Games, whatever)
all this while fitting on a single 700MB CD. Besides point 1. I've got
this covered in pilgrim and in a few weeks I should have command line
utilities at least to do the live installs. The UI will follow once the
bespoke gnome-diskutil is ready.
Jasper, why you (obviously) disagree that these are important for Live
CD infrastructure is quite frankly hard to grasp especially when we have
competitors (Ubuntu) that do this already and is kicking our ass in this
department. I also think it's a really bad idea to try to fix this by
using technology (Kadischi) that is inferior to theirs.
Have a nice day.
David
7:56 p.m.
David Zeuthen wrote:
On Sat, 2006-09-23 at 18:40 -0500, Jasper Hartline wrote:
>> I see. Sorry, but I think this is a little backwards, I mean, why
>> wouldn't I just download the install CD's; it's pretty much the same
>> amount of traffic.
>>
>>
> I'll leave you to debate the difference between a router style 550MB
> install and a full blown everything
> chosen 7GB install. I'm sure a calculator isn't necessary to see the
> difference.
>
I'm not sure what point you are trying to make here.
The point is that, you wouldn't download the entire distribution of X
many discs
when there is a LiveCD you can install from, that provides the same
interface as the real installer discs.
This would be Anaconda. There is a big difference in downloading 3.2GB
of data than installing a 1.6GB system with X from
a LiveCD installer interface and not needing to know which discs are
required, this requires the network unless it is a DVD
in which case the 3.2GB could be provided on disc. This doesn't change
the installer interface, Kadischi and Anaconda are still
able to use a local repository for installation.
>> Also keep in mind that many consumers of live cd's
(typically in poor
>> countries) have zero network connectivity - all they have is a live cd
>> that some benevolent organization sent them. Like Ubuntu's ship it.
>>
>> The approach I have in mind includes just reusing the ext3 file system
>> we have already prepared and just dd that onto the target installation
>> block device. That way an install would take very little time and the
>> only thing you need to make this work is the live cd itself.
>>
>>
> This is extremely unflexible and the user is limited to what you've
> mastered onto the LiveCD
>
Excuse me? How is this different from Kadishchi built live CD's? CD
space is limited.
Exactly. Using Anaconda to install to system defeats this barrier.
> With Anaconda it is a familiar, flexible, choosable option,
package
> selectable interface
> along with that upgrading the system from Core to Core is a snap, using
> Anaconda.
>
Oh, I see, it sounds like you're making the point that the Anaconda
package selector is better than Pirut. If so the Pirut authors better
fix this.
Pirut was made for installing packages, not installing complete systems.
Yes, we know Pirut doesn't partition disks using LVM, or RAID or making
SWAP where you want it
which is compensated by your rogue disk tools.. this is also going to be
wary at first as people are familiar with
Anaconda and it is an already existing Fedora Core tool, not a rogue
disk partitioner that you wrote up in a weekend.
I'm not really sure who you are designing for here and it sounds
like
you are not sure yourself either. I think that important goals of a live
CD should be
1. Installable without requiring a network
(since many potential users will have little or no network
connectivity, cf. distributions to poor countries.)
2. Ability to install / try out software before installing the livecd
to their hard disk.
(to let people see if the apps they need are available)
3. Contains all software the user base you are trying to target wants
(why it's good to easily be able to build different flavors, e.g.
GNOME desktop, KDE desktop, Eclipse, Music, Games, whatever)
all this while fitting on a single 700MB CD. Besides point 1. I've got
this covered in pilgrim and in a few weeks I should have command line
utilities at least to do the live installs. The UI will follow once the
bespoke gnome-diskutil is ready.
Jasper, why you (obviously) disagree that these are important for Live
CD infrastructure is quite frankly hard to grasp especially when we have
competitors (Ubuntu) that do this already and is kicking our ass in this
department. I also think it's a really bad idea to try to fix this by
using technology (Kadischi) that is inferior to theirs.
Again, Kadischi builds LiveCDs. Anaconda is the system installer.
Anaconda is by far not inferior for installing from a LiveCD.
J .Hartline
8:10 p.m.
On Sat, 2006-09-23 at 19:56 -0500, Jasper Hartline wrote:
Anaconda and it is an already existing Fedora Core tool, not a rogue
disk partitioner
You blatantly ignore the fact that we need such a tool anyway. Only
giving the users UI for for LVM / RAID setup in the installer is just
weird. Btw, the reason I'm writing this tool has nothing to do with Live
CD's - it's something we're working together on in upstream projects
like freedesktop.org, GNOME and KDE to do anyway.
that you wrote up in a weekend.
There's no need to be nasty here. You're welcome to review my list of
contributions to the open source community if you doubt if I'm capable
of writing such a thing.
Again, Kadischi builds LiveCDs. Anaconda is the system installer.
Anaconda is by far not inferior for installing from a LiveCD.
Of course it is. You make the users download the bits twice and makes it
impossible to deliver an usable live CD in 700 MB.
I have no idea who you are designing for.
Good luck,
David
8:23 p.m.
David Zeuthen wrote:
On Sat, 2006-09-23 at 19:56 -0500, Jasper Hartline wrote:
> Anaconda and it is an already existing Fedora Core tool, not a rogue
> disk partitioner
>
You blatantly ignore the fact that we need such a tool anyway. Only
giving the users UI for for LVM / RAID setup in the installer is just
weird. Btw, the reason I'm writing this tool has nothing to do with Live
CD's - it's something we're working together on in upstream projects
like freedesktop.org, GNOME and KDE to do anyway.
Yes, but it doesn't exist yet. This is the point you're missing.
> that you wrote up in a weekend.
>
There's no need to be nasty here. You're welcome to review my list of
contributions to the open source community if you doubt if I'm capable
of writing such a thing.
You are the one implying I'm being nasty.
In my opinion coming form a military background you have a totally
different mindset
than I, talking about competitions and inferiority, and superiority and
other distributions.
> Again, Kadischi builds LiveCDs. Anaconda is the system
installer.
> Anaconda is by far not inferior for installing from a LiveCD.
>
Of course it is. You make the users download the bits twice and makes it
impossible to deliver an usable live CD in 700 MB.
The only bits you'd have downloaded was the LiveCD.
There is no duplication of downloading of material in this use case.
If I'm overlooking your point or where there is some duplicity please
inform me.
J. Hartline
8:49 p.m.
On Sat, 2006-09-23 at 20:23 -0500, Jasper Hartline wrote:
> You blatantly ignore the fact that we need such a tool anyway.
Only
> giving the users UI for for LVM / RAID setup in the installer is just
> weird. Btw, the reason I'm writing this tool has nothing to do with Live
> CD's - it's something we're working together on in upstream projects
> like freedesktop.org, GNOME and KDE to do anyway.
>
Yes, but it doesn't exist yet. This is the point you're missing.
It will. It's sometimes good in software design to take a few steps back
and look at the bigger picture.
> Of course it is. You make the users download the bits twice and
makes it
> impossible to deliver an usable live CD in 700 MB.
>
The only bits you'd have downloaded was the LiveCD.
There is no duplication of downloading of material in this use case.
If I'm overlooking your point or where there is some duplicity please
inform me.
The live cd contains the installed bits already, e.g. for example all
the X.org stuff, the GNOME stuff, /bin/bash or whatever is already
available and can be copied over to the hard disk.
David
8:58 p.m.
David Zeuthen wrote:
>> Of course it is. You make the users download the bits twice
and makes it
>> impossible to deliver an usable live CD in 700 MB.
>>
>>
> The only bits you'd have downloaded was the LiveCD.
> There is no duplication of downloading of material in this use case.
> If I'm overlooking your point or where there is some duplicity please
> inform me.
>
The live cd contains the installed bits already, e.g. for example all
the X.org stuff, the GNOME stuff, /bin/bash or whatever is already
available and can be copied over to the hard disk.
That's just splendid.
You're sacrificing flexibility and user choice for what you think is the
right way to do things
and accommodate for the least common denominator which is someone
without any network, and if they
had a network, not enough bandwidth to surf the web for a month in
general use cases.
This simply is not Kadischi's goal.
Kadischi will allow you to build and install from a LiveCD with a
diverse package set.
As much as Anaconda allows.
In the LiveDVD case there is no downloading anything duplicate.
J. Hartline
10:02 p.m.
On Sat, 2006-09-23 at 20:58 -0500, Jasper Hartline wrote:
> The live cd contains the installed bits already, e.g. for
example all
> the X.org stuff, the GNOME stuff, /bin/bash or whatever is already
> available and can be copied over to the hard disk.
>
That's just splendid.
I think so.
You're sacrificing flexibility and user choice
There is no loss of flexibility and user choice.
for what you think is the
right way to do things
and accommodate for the least common denominator
Both Kadischi and pilgrim are live CD's. The live cd created will always
have to make a choice what to put on the CD's. People installing the
live CD to hard disk can always use Pirut
which is someone
without any network, and if they
had a network, not enough bandwidth to surf the web for a month in
general use cases.
Not at all. It's just an added bonus users don't need a network to
actually install the OS to a hard disk.
This simply is not Kadischi's goal.
Kadischi will allow you to build and install from a LiveCD with a
diverse package set.
So will pilgrim. Users can simply use Pirut to install software
afterwards.
As much as Anaconda allows.
... and there is no need to have constraints imposed by anaconda in
pilgrim.
In the LiveDVD case there is no downloading anything duplicate.
Of course there is as you'll include the binary both as an RPM and in
the squashfs (or whatever). Also, DVD media is more expensive than CD
media. So are DVD writers.
I think this thread isn't useful anymore. Suggest we just put our
differences aside.
Good luck,
David
7:35 a.m.
David Zeuthen wrote:
Oh, I see, it sounds like you're making the point that the
Anaconda
package selector is better than Pirut. If so the Pirut authors better
fix this.
No. Anaconda uses Pirut. It was designed for this explicitly. So as far
as package selection is concerned, there is zero difference between
doing it in Anaconda or post installation.
Rahul
7:50 p.m.
On Sat, 2006-09-23 at 15:19 +0200, Chitlesh GOORAH wrote:
For the past 3 days, we have talked and talked. SO WHAT IS NEXT ?
Right :-)
The kadischi's development community isn't that huge, 3 at most. And
soon we will have 4 mechanism for creating fedora livecds.
- Kadischi
- pilgrim
- Jeremy's code
- Jane Dogalt's work
To my guess, the last three has one developper ? That makes us around
6 working for the same output, a fedora livecd!
Yea.
Btw, technically I'm more aiming for something that can be described as
tools for easily rolling bootable (and optionally installable) images of
software from yum repositories. This is a bit more abstract... but I'm
aiming for something that projects like OLPC can use too. It's ambitious
but, I think, doable.
I think one key point here is that I want to make it extremely simple to
do (derived) distributions based on Fedora. With pilgrim this simply
becomes
1. provide a yum repo with the packages you fork (including one
package mydistro-release that Provides: fedora-release).
2. write a pilgrim stream definition file.
3. roll an installable cd / dvd
4. ???
5. profit
Thus, why not work together to make something _centralized_ ? Just
like fedora likes to do.
I've been to the Kadischi Project since January, and I feel our goals
are fading away due to lack of communcation with other fedora
projects.
Rahul did reveal something, a LiveCD can be used for:
- Freemedia, lower the expenses (Max would be happy)
- unleashKDE, more contributors to KDE (i'll be happy and Rex too:) )
Can we make kadischi a centralized tool for livecd generation but with plugins ?
By plugins, I mean
kadischi package:
- /usr/bin/kadischi-pilgrim
- /usr/bin/kadischi-anaconda
- kadischi core
- post install scripts
Both certainly have the same core and similar post -install scripts,
but the methods vary.
/usr/bin/kadischi-pilgrim calls for core and uses yum and doesn't
depends on anaconda and finally uses common post install scripts .
Output a livecd image
if /usr/bin/kadischi-anaconda calls for core and uses anaconda and
finally uses common post install scripts . Output a livecd image.
Hence, we all can work on "kadischi core" and both David and Jasper
will be happy (I guess).
David, do you think that this may be posssible with the OLPC project.
Jasper, what do you think about it ?
Well, I'm not sure it's a good idea to have two code paths for two
different kinds of configuration. In general one should try to minimize
the amount of options in the sake of at least keeping the code simple.
Also, I hate to sound like an asshole, but I pretty much think pilgrim
is done (except for the install use case but that's really outside of
pilgrim) and fits the bill for at least the OLPC and Fedora live CD use
cases. To be honest, I'm just not sure how it can be combined in a
meaningful way with Kadischi or Anaconda or even what the benefits would
be. Any takers?
There's also the point that at least Jasper and I have differing views
on what an "installable livecd" is cf. the earlier mails today... and as
such this great affects how the architecture of the tool set is going to
look like.
But, sure, having multiple similar competing projects sucks badly but,
then again... such is open source. Anyone can write what they want and
new projects can surface which might jeopardize existing projects. IN a
bizarre way it's also a bit healthy and helps keep people on guard and
productive :-) - but now I'm digressing...
David
8:08 p.m.
David Zeuthen wrote:
Well, I'm not sure it's a good idea to have two code paths
for two
different kinds of configuration. In general one should try to minimize
the amount of options in the sake of at least keeping the code simple.
The Kadischi LiveCD build case takes any of 2 to 3 arguments.
1) --text or --graphical or none which defaults to graphical and falls
back to text.
2) The repository you are installing from to build the LiveCD
3) The path and filename of the result product ISO image.
The Kadischi/Anaconda LiveCD-to-system install takes exactly one argument:
1) The repository you are installing from
But, sure, having multiple similar competing projects sucks badly
but,
then again... such is open source.
Kadischi is in no sort of competition with
anyone, not you not pilgrim,
and certainly not
other distribution's LiveCDs or applications.
From day one I have had my own idea of what Kadischi could be and as
the days go by
it is slowly making it to that point. This is not driven by competition.
The idea to have an installable LiveCD has been on my plate for a while
and day to day I keep on my toes to keep Anaconda and Kadischi operating
properly
to reach this goal, and to simply maintain Kadischi's functionality.
Who are you in competition with again?
To me it sounds like you are chasing ghosts.
J. Hartline
8:18 p.m.
On Sat, 2006-09-23 at 20:08 -0500, Jasper Hartline wrote:
Kadischi is in no sort of competition with anyone, not you not
pilgrim,
and certainly not
other distribution's LiveCDs or applications.
One reality you cannot escape is the fact that there is no good live cd
for Fedora yet. Chitlesh made the point that we should start working
together. I don't see this happening as at least you and I have very
different goals.
Good luck,
David
8:26 p.m.
David Zeuthen wrote:
On Sat, 2006-09-23 at 20:08 -0500, Jasper Hartline wrote:
> Kadischi is in no sort of competition with anyone, not you not pilgrim,
> and certainly not
> other distribution's LiveCDs or applications.
>
One reality you cannot escape is the fact that there is no good live cd
for Fedora yet. Chitlesh made the point that we should start working
together. I don't see this happening as at least you and I have very
different goals.
As I've stated, we have two different mindsets, yes maybe different goals.
I don't have to "escape a reality" as I've been hacking on Kadischi
I'm
creating a reality.
There is a fundamental difference.
J. Hartline
10:41 a.m.
David Zeuthen wrote:
(adding back fedora-desktop-list as that Cc: field mysteriously
vanished.)
On Wed, 2006-09-20 at 03:05 -0500, Jasper Hartline wrote:
>You really should use the stock Fedora Core utilities however.
>If you are making an installer to system from LiveCD, why not use Anaconda?
>
>
I'd rather ask; Why use anaconda? At the end of the day, installation is
a pretty basic task
- yum install what you want
- write out some configuration files
- perform other post-installation configuration.
So, you know, I'd hate to replace < 100 lines of code by depending on
anaconda, which, I might add, is designed to do far more than the
relatively straightforward task of doing live cd's. I'm not even sure it
makes sense to carry around code in anaconda to facilitate live cd
installs but I'll leave that judgement call to the Anaconda developers.
Ok. Good luck partitioning a disk in any sort of way with Yum.
J. Hartline
11:23 a.m.
On Wed, 2006-09-20 at 10:41 -0500, Jasper Hartline wrote:
David Zeuthen wrote:
>(adding back fedora-desktop-list as that Cc: field mysteriously
>vanished.)
Doing this again. Please don't munge the To: or Cc: headers. Thanks.
>So, you know, I'd hate to replace < 100 lines of code by
depending on
>anaconda, which, I might add, is designed to do far more than the
>relatively straightforward task of doing live cd's. I'm not even sure it
>makes sense to carry around code in anaconda to facilitate live cd
>installs but I'll leave that judgement call to the Anaconda developers.
>
>
Ok. Good luck partitioning a disk in any sort of way with Yum.
Well, I take it that you are aware that cd media is not normally
partitioned (it is for bizarre things like Apple Mac OS X install CD's
using Apple Partition Map; but that is totally not relevant for a Fedora
Live CD on any architecture we want to support).
So I assume you are talking about creating Live USB images, e.g. an
image people can dd(1) to the USB key e.g.
# dd if=some-image.img of=/dev/sdb
where /dev/sdb is the block device for your USB stick.
First, pilgrim supports this (partitioning is not hard), it was the
first installation target since that is what we use for OLPC; see
http://wiki.laptop.org/go/OS_images_for_USB_disks
for details.
Second, a Fedora system on a USB stick / hard disk is useful.. Heck,
this can be done today with the pilgrim system by simple changes to
streams.d/fedora-base.stream in the pilgrim source tree (just define a
new variant, liveusb, where PILGRIM_FS_liveusb=ext3). The reason I
haven't done this is just lack of time. And motivation.
The lack of motivation has to do with the fact that I'm not sure how
useful it is since ext3 basically is pretty wasteful and have no
compression [1]. To have any kind of useful system you'd need a 2GB or
bigger stick. Second, I think once we get the "install to hard disk"
feature done people can just install the OS to a USB stick / hard disk
from the livecd and be done with it. That will also ensure that we fix
up the UUID of the file system and other stuff.
We can easily add variants for "usb stick" builds until we have the
"install to hard disk" feature. But I'd rather that we worked on the
latter, that feature is so much more important for Fedora as gdk so
eloquently points out.
We could also add a new hack to use squashfs / ext3 / dm-snapshot hacks
to the live USB image where the overlay lives in a file on a different
partition of the USB stick. That way we'd have a semi-useful system that
would fit on a 512MB stick. Again, not sure how useful live USB is, I'd
rather focus on getting the "install to hard disk" feature done and just
tell people to install to a USB stick / harddisk if they want a portable
Fedora OS.
David
[1] : though I did read something about "compressed block devices" being
added to Linux. Dunno where that is going.
11:42 a.m.
David Zeuthen wrote:
>>So, you know, I'd hate to replace < 100 lines of code
by depending on
>>anaconda, which, I might add, is designed to do far more than the
>>relatively straightforward task of doing live cd's. I'm not even sure it
>>makes sense to carry around code in anaconda to facilitate live cd
>>installs but I'll leave that judgement call to the Anaconda developers.
>>
>>
>>
>>
>Ok. Good luck partitioning a disk in any sort of way with Yum.
>
>
Well, I take it that you are aware that cd media is not normally
partitioned (it is for bizarre things like Apple Mac OS X install CD's
using Apple Partition Map; but that is totally not relevant for a Fedora
Live CD on any architecture we want to support).
Welcome to the list. I enjoy all aspects of LiveCD creation, I was just
confused at first about the relevance of pilgrim to Fedora-livecd-list.
I see now it is an effort for Fedora Core. As I stated, I was just confused.
J, Hartline
12:38 p.m.
On Wed, 2006-09-20 at 12:23 -0400, David Zeuthen wrote:
On Wed, 2006-09-20 at 10:41 -0500, Jasper Hartline wrote:
> David Zeuthen wrote:
>
> >(adding back fedora-desktop-list as that Cc: field mysteriously
> >vanished.)
Doing this again. Please don't munge the To: or Cc: headers. Thanks.
You may need to hit reply-to-all instead of reply (mailman for this list
is setting "reply-to:" which can cause this issue)
> >So, you know, I'd hate to replace < 100 lines of code
by depending on
> >anaconda, which, I might add, is designed to do far more than the
> >relatively straightforward task of doing live cd's. I'm not even sure
it
> >makes sense to carry around code in anaconda to facilitate live cd
> >installs but I'll leave that judgement call to the Anaconda developers.
> >
> >
> Ok. Good luck partitioning a disk in any sort of way with Yum.
Well, I take it that you are aware that cd media is not normally
partitioned (it is for bizarre things like Apple Mac OS X install CD's
using Apple Partition Map; but that is totally not relevant for a Fedora
Live CD on any architecture we want to support).
I was confused when I first read autopsy's comment as well. Autopsy,
are you talking about partitioning when creating the liveCD/liveX image?
Or talking about paritioning when installing from liveMedia to a hard
drive?
[snip]
The lack of motivation has to do with the fact that I'm not sure
how
useful it is since ext3 basically is pretty wasteful and have no
compression [1]. To have any kind of useful system you'd need a 2GB or
bigger stick. Second, I think once we get the "install to hard disk"
feature done people can just install the OS to a USB stick / hard disk
from the livecd and be done with it. That will also ensure that we fix
up the UUID of the file system and other stuff.
I think we want a liveUSB system that mirrors the liveCD ideas.
Comparing liveUSB to Install to hard drive is problematic for exactly
the issue you identify here: a standard ext3 image takes up lots of
space. Both USB and CDRom are space constrained media. Having the
ability to create <256MB images is the use case I have for the livecd
creating system (which will fit on cheaply available USB drives, compact
flash, and disk-on-module's.)
Installing a full Fedora OS on USB 2GB+ is a separate issue that
naturally falls out of liveMedia => hard drive installs as you say
below.
We can easily add variants for "usb stick" builds until we
have the
"install to hard disk" feature. But I'd rather that we worked on the
latter, that feature is so much more important for Fedora as gdk so
eloquently points out.
install to hard disk has no use to me so I'm afraid I know nothing about
what autopsy has been working on and how it compares to pilgrim.
We could also add a new hack to use squashfs / ext3 / dm-snapshot
hacks
to the live USB image where the overlay lives in a file on a different
partition of the USB stick. That way we'd have a semi-useful system that
would fit on a 512MB stick.
This could be an interesting next step.
I like pilgrim's simplicity. I'm a little hesitant that it's written in
shell (Shell doesn't scale to larger projects nearly as well as python.
Although the original kadischi code had a lot of
reimplementation-of-the-wheel problems.) Kadischi's dependence on
anaconda is a mixed bag -- when it works, it's nice to have a way to
select packages that even the non-technical people at my work can figure
out but when it doesn't work we're often waiting for patches to make it
into anaconda or cannot build on FC-stable, we have to update the
cd-building machine to rawhide to run the development anaconda. I don't
know if pilgrim will have similar upstream issues (since it's first
priority is OLPC) or not (because davidz is here talking to us
enthusiastically about what he's done so far :-). pilgrim's inheritance
system for package lists looks nice. Kadischi's ability to use
kickstart files is nice.
I'll have to run pilgrim to see how kadischi and pilgrim differ in real
usage.
-Toshio
3:16 p.m.
On Wed, 2006-09-20 at 10:38 -0700, Toshio Kuratomi wrote:
> Well, I take it that you are aware that cd media is not
normally
> partitioned (it is for bizarre things like Apple Mac OS X install CD's
> using Apple Partition Map; but that is totally not relevant for a Fedora
> Live CD on any architecture we want to support).
>
I was confused when I first read autopsy's comment as well. Autopsy,
are you talking about partitioning when creating the liveCD/liveX image?
Or talking about paritioning when installing from liveMedia to a hard
drive?
I might add that for the latter, we want to allow the user to create
LVM / swap / crypto whatever to install to. That's why we need something
like gnome-diskutil that I mentioned in the README.fedora.
I like pilgrim's simplicity. I'm a little hesitant that
it's written in
shell (Shell doesn't scale to larger projects nearly as well as python.
Although the original kadischi code had a lot of
reimplementation-of-the-wheel problems.)
Shell was chosen as that's the natural language you want to use when
defining derivatives. It's simple, lots of people know it and it's very
expressive.
Btw, I don't expect pilgrim to grow a lot in size and complexity, it's
pretty much feature complete except for a few features.
For the record, I've written quite a bit of stuff in python but always
ended up disliking it - I guess I'm one of the types of programmers that
pick extremes. I love writing code in C and think I'm good at it. Shell
is pretty useful for stuff like pilgrim. Python always been in the
middle for me, I like to call it a "cute" language, but not really
useful for the stuff I wanted to do. It always ended up letting me down
one way or another. Of course, YMMV, I understand and see that some
people use Python in wonderful ways, more power to them. I just don't
like it.
I'll have to run pilgrim to see how kadischi and pilgrim differ
in real
usage.
Let me know if you need help. I tend to hang out on #fedora-desktop on
GimpNet and #freedesktop on freenode as davidz. I suppose this list if
fine to use too.
David
12:48 p.m.
New subject: Pilgrim, kadischi, and stateless (was Re: pilgrim livecd work)
David,
Does pilgrim make an attempt to integrate any of stateless's work? In
my mind integrating stateless with livecd creation just makes sense.
But I don't think there's been much work done on that front since
Jeremy's proof of concept fork of kadischi which I don't think he's been
updating.
-Toshio
3:07 p.m.
New subject: Pilgrim, kadischi, and stateless (was Re: pilgrim livecd work)
Hi,
On Wed, 2006-09-20 at 10:48 -0700, Toshio Kuratomi wrote:
Does pilgrim make an attempt to integrate any of stateless's
work? In
my mind integrating stateless with livecd creation just makes sense.
But I don't think there's been much work done on that front since
Jeremy's proof of concept fork of kadischi which I don't think he's been
updating.
Nope, I think it's much more elegant to just use dm-snapshot to provide
a real rw rootfs. Not sure what Bill Nottingham (Cc'ed) or people
working on stateless team thinks of this, they might have a number of
good reasons that I haven't thought out. I still think stateless makes
sense for non-livecd work however.
Btw, If someone could talk davej into including unionfs into the Fedora
kernel, we'd use that instead of dm-snapshot and we'd have persistence
more easily solved [1].
David
[1] : we can already do this for our livecd but it will be tied to the
specific build you're using, e.g. in practice it's tied to the physical
media you created it with.
With unionfs things might look much better and we'd easily be able to do
a harddisk install of "livecd + your changes made" instead of harddisk
install becomes contents of "stock livecd", ie. without your changes.
That said, I'm not sure that this really matters in real life.
3:13 p.m.
New subject: Pilgrim, kadischi, and stateless (was Re: pilgrim livecd work)
David Zeuthen (davidz(a)redhat.com) said:
Nope, I think it's much more elegant to just use dm-snapshot to
provide
a real rw rootfs. Not sure what Bill Nottingham (Cc'ed) or people
working on stateless team thinks of this, they might have a number of
good reasons that I haven't thought out. I still think stateless makes
sense for non-livecd work however.
The reason we didn't use dm-snapshot is that it removes the security
benefits of readonly-root (after all, you don't need 99% of the system
to actually be read-write); moreover, you can't selectively apply it
(it has to be done at the whole block device level.)
Btw, If someone could talk davej into including unionfs into the
Fedora
kernel, we'd use that instead of dm-snapshot and we'd have persistence
more easily solved [1].
Flaming death. Deadlocks, oopses, etc. (it might be better now)
Bill
3:25 p.m.
New subject: Pilgrim, kadischi, and stateless (was Re: pilgrim livecd work)
On Wed, 2006-09-20 at 16:13 -0400, Bill Nottingham wrote:
> Btw, If someone could talk davej into including unionfs into the
Fedora
> kernel, we'd use that instead of dm-snapshot and we'd have persistence
> more easily solved [1].
Flaming death. Deadlocks, oopses, etc. (it might be better now)
So, more correctly
stated. If someone could *fix* unionfs, then
get it included, then we'd use it.
jeff
3:30 p.m.
New subject: Pilgrim, kadischi, and stateless (was Re: pilgrim livecd work)
On Wed, 2006-09-20 at 16:07 -0400, David Zeuthen wrote:
Hi,
On Wed, 2006-09-20 at 10:48 -0700, Toshio Kuratomi wrote:
> Does pilgrim make an attempt to integrate any of stateless's work? In
> my mind integrating stateless with livecd creation just makes sense.
> But I don't think there's been much work done on that front since
> Jeremy's proof of concept fork of kadischi which I don't think he's
been
> updating.
Nope, I think it's much more elegant to just use dm-snapshot to provide
a real rw rootfs. Not sure what Bill Nottingham (Cc'ed) or people
working on stateless team thinks of this, they might have a number of
good reasons that I haven't thought out. I still think stateless makes
sense for non-livecd work however.
Bill touched on a couple issues here. I'd
like to add another.
The code we're developing to allow for low-overhead distribution
of updates to the root filesystem from the server to its stateless
clients would probably break if we were using dm-snapshot on the
clients. It's vital to the update model that the client's root
filesystem not change at the block level. ie, the image on the
client must match block for block the master image on the server.
Jeff
5:43 p.m.
New subject: Pilgrim, kadischi, and stateless (was Re: pilgrim livecd work)
----- Original Message ----
From: David Zeuthen <davidz(a)redhat.com>
To: fedora-livecd-list(a)redhat.com
Cc: fedora-desktop-list(a)redhat.com
Sent: Wednesday, September 20, 2006 3:07:12 PM
Subject: Re: Pilgrim, kadischi, and stateless (was Re: [Fedora-livecd-list] pilgrim livecd
work)
Hi,
On Wed, 2006-09-20 at 10:48 -0700, Toshio Kuratomi wrote:
Does pilgrim make an attempt to integrate any of stateless's
work? In
my mind integrating stateless with livecd creation just makes sense.
But I don't think there's been much work done on that front since
Jeremy's proof of concept fork of kadischi which I don't think he's been
updating.
Nope, I think it's much more elegant to just use dm-snapshot to provide
a real rw rootfs. Not sure what Bill Nottingham (Cc'ed) or people
working on stateless team thinks of this, they might have a number of
good reasons that I haven't thought out. I still think stateless makes
sense for non-livecd work however.
Btw, If someone could talk davej into including unionfs into the Fedora
kernel, we'd use that instead of dm-snapshot and we'd have persistence
more easily solved [1].
There's a new compression filesystem LZMA compression. According to some it is even
better than unionfs and it makes the compressed items smaller than with normal squashfs
and unionfs. Let's see how it is implemented in other distributions and try to use it
as an advantage over what we already have.
Regards,
Antonio
David
[1] : we can already do this for our livecd but it will be tied to the
specific build you're using, e.g. in practice it's tied to the physical
media you created it with.
With unionfs things might look much better and we'd easily be able to do
a harddisk install of "livecd + your changes made" instead of harddisk
install becomes contents of "stock livecd", ie. without your changes.
That said, I'm not sure that this really matters in real life.
--
Fedora-livecd-list mailing list
Fedora-livecd-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-livecd-list
5:23 p.m.
----- Original Message ----
From: Jasper Hartline <jasperhartline(a)adelphia.net>
To: fedora-livecd-list(a)redhat.com
Sent: Wednesday, September 20, 2006 10:41:23 AM
Subject: Re: [Fedora-livecd-list] pilgrim livecd work
David Zeuthen wrote:
(adding back fedora-desktop-list as that Cc: field mysteriously
vanished.)
On Wed, 2006-09-20 at 03:05 -0500, Jasper Hartline wrote:
>You really should use the stock Fedora Core utilities however.
>If you are making an installer to system from LiveCD, why not use Anaconda?
>
>
I'd rather ask; Why use anaconda? At the end of the day, installation is
a pretty basic task
- yum install what you want
- write out some configuration files
- perform other post-installation configuration.
So, you know, I'd hate to replace < 100 lines of code by depending on
anaconda, which, I might add, is designed to do far more than the
relatively straightforward task of doing live cd's. I'm not even sure it
makes sense to carry around code in anaconda to facilitate live cd
installs but I'll leave that judgement call to the Anaconda developers.
Ok. Good luck partitioning a disk in any sort of way with Yum.
Sorry to come in,
But you can use another livecd to partition the disk (gparted,systemrescue,knoppix,etc)
and pre-partition it and then use the new livecd and just install it to a preformatted
partition, ext2,ext3, etc. Anyway with Anaconda, one cannot resize NTFS partitions, we
still another type of cd to perform these actions.
Regards,
Antonio
J. Hartline
--
Fedora-livecd-list mailing list
Fedora-livecd-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-livecd-list
5:35 p.m.
Antonio Olivares wrote:
Ok. Good luck partitioning a disk in any sort of way with Yum.
Sorry to come in,
But you can use another livecd to partition the disk (gparted,systemrescue,knoppix,etc)
and pre-partition it and then use the new livecd and just install it to a preformatted
partition, ext2,ext3, etc. Anyway with Anaconda, one cannot resize NTFS partitions, we
still another type of cd to perform these actions.
This is hardly desireable to millions of potential new users.
They won't know how to use gparted, or fdisk or mke2fs.
Anaconda fits this niche completely and is also a familiar installer
interface.
J. Hartline
6422
days inactive
6426
days old
livecd@lists.fedoraproject.org
57 comments
11 participants
participants (11)
-
Antonio Olivares -
Bill Nottingham -
Chitlesh GOORAH -
Dan Williams -
David Zeuthen -
Greg DeKoenigsberg -
J. Hartline -
Jean Casteres -
Jeffrey A Law -
Rahul Sundaram -
Toshio Kuratomi