9:07 p.m.
Welcome to the list Pilgrim,
Wow, talk about an explosion of traffic on this list. I was waiting
for a spark to light a fire around here.
Anyway, here is my response to all 30 messages,
- Welcome David.
- Pilgrim sounds cool. I have my own qemu based non-root livecd
generation system nearing a release, but I'm more than happy to see
yours, as I can just rip off your initramfs dm-snapshot code, instead
of doing exactly what you did there myself (as I had been planning).
- I also was planning on pushing my project in the OLPC/appliance
direction. Your seeding feature is totally akin to what I'm doing (and
for reference, similar to what rpath is doing, i.e. recipes for
appliance system generation).
- Regarding Jaspers disk partitioning with yum, which has been
adequately thrashed out- I'll just add- Yeah, it's a seperate problem,
fdisk is one solution, hard coded assumptions are another, and if the
anaconda interface truly is the easiest to use version, then just rip
it out and use it standalone (or fix gparted so that it's as good a
solution)
- Regarding Jasper's thread about anaconda rootpath installs being
closer to "real" installs than your yum 'hack', ACK!!! One of my
biggest complaints all along has been the utter dangerousness of doing
the install as root on a particular host system, and having faith that
your rootpath install is not pulling in dependencies on the host build
hardware config. My solution is to do the install under qemu, which
also buys you a pure non-root system, which I don't know about you, but
running kadischi on any system other than a dedicated build system
scares the crap out of me (even after jkatz fixed the bugs where
kadischi via anaconda would nuke the host build systems timezone and
network configuration)
- Toshio's shell vs python arg... Oh boy, I can't wait till my bash
scripts scare the crap out you guys. Otherwise David pretty much gave
my arguments (though my code is not exactly that small, but hopefully
once it becomes feature complete, it will be so extensible by design,
that extending the infrastructure will be a rarity)
- Regarding the Update from LiveCD controversy. I thought there was
confusion, regarding the "update install destined for munging into live
.iso" vs "update the system you just booted the live .iso on".
Regarding the latter, even though I don't think it was the original
issue, there is a potential benefit of making a livecd appliance with
integrated tripwire, and having it able to update the system. But
thats a seed/config/recipe for the future, not a main concern now.
- I like that my post made the readme file regarding the rebootless
installer. I also agree that it, and the non-rebootless version of
installing livecd+ram_changes, are interesting, but probably more far
more trouble than they are worth (at this stage in the game certainly).
- I did like the conversation about stateless. They are different
projects, but the idea of hardware agnostic physically portable system
disks, is very interesting. Dare I bring up an idea that an alan cox
post a while back made me think of... (store a qemu system state file
on the liveiso, boot it, display it into a vnc window that (all
autostart), then when you shut down, save the qemu state, do an xdelta
diff on orig sysstate, upload data diff to usb-stick or gmailfs/ftp,
such that on next boot, you get your hibernated virtual desktop back
exactly as you left it...)
Anyway, thats it, call it a dime, as that was way more than $0.02. I
look forward to seeing where this goes. I'm somewhat busy with a full
school workload, so I don't know how much work I'll be able to do for
the rest of this year. Hopefully I'll be able to force myself through
the last 5% of my qemu based project (just need to script/automate some
junk I've done manually to create working .iso's like the one I posted
long ago).
It's long past time that fedora surpass ubuntu in livecd features... I
hope this new development infusion gets us there in a hurry.
Personally I'm not afraid at all of 4 projects on this list (kadischi,
pilgrim, jkatz livecd stuffs, my stuffs). The more there are, the more
we'll copy good ideas from one another, and eventually integrate into a
great solution that will evolve out of all of this.
Peace...
-dmc/jdog
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
2:27 a.m.
On 9/21/06, Jane Dogalt <jdogalt(a)yahoo.com> wrote:
- Pilgrim sounds cool. I have my own qemu based non-root livecd
generation system nearing a release, but I'm more than happy to see
yours, as I can just rip off your initramfs dm-snapshot code, instead
of doing exactly what you did there myself (as I had been planning).
I'll be happy to have a look at it :)
Personally I'm not afraid at all of 4 projects on this list
(kadischi,
pilgrim, jkatz livecd stuffs, my stuffs). The more there are, the more
we'll copy good ideas from one another, and eventually integrate into a
great solution that will evolve out of all of this.
I think it's great, to have all fedora livecd projects' discussion to
happen here in this mailing list. The more we discuss together the
more we can create a better fedora livecd tool.
--
http://clunixchit.blogspot.com
2:58 p.m.
On Wed, 2006-09-20 at 19:07 -0700, Jane Dogalt wrote:
- Welcome David.
Thanks.
- Pilgrim sounds cool. I have my own qemu based non-root livecd
generation system nearing a release, but I'm more than happy to see
yours, as I can just rip off your initramfs dm-snapshot code, instead
of doing exactly what you did there myself (as I had been planning).
Sure, it's licensed under the GPL v2.
- Regarding Jaspers disk partitioning with yum, which has been
adequately thrashed out- I'll just add- Yeah, it's a seperate problem,
fdisk is one solution, hard coded assumptions are another, and if the
anaconda interface truly is the easiest to use version, then just rip
it out and use it standalone (or fix gparted so that it's as good a
solution)
Well, my plan for the "install livecd to harddisk", e.g. to use the
livecd for installation of Fedora includes writing the gnome-diskutil
I've been talking about.
We need it *anyway* since people are likely to need graphical tools for
partitioning / formatting / RAID / LVM / Crypto tasks. And I just don't,
for a multitude of reasons, think that gparted is the answer here.
In a way it's weird we have these UI features only at install time (e.g.
in anaconda) but not in the installed OS. I do know why though.
Anyway, gnome-diskutil is bluesky at this point - some code is slowly
dribbling into HAL to provide the backend but the only thing of
gnome-diskutil that I've published yet are screenshots
http://people.freedesktop.org/~david/gdu-2.png
http://people.freedesktop.org/~david/gdu-3.png
http://people.freedesktop.org/~david/gdu-4.png
http://people.freedesktop.org/~david/gdu-5.png
http://people.freedesktop.org/~david/gdu-6.png
My plan is to put this in gnome CVS sometime next week, I've just been
busy with 4+ different projects at the same time; it's looking to clear
up a bit.
- Regarding Jasper's thread about anaconda rootpath installs
being
closer to "real" installs than your yum 'hack', ACK!!! One of my
biggest complaints all along has been the utter dangerousness of doing
the install as root on a particular host system, and having faith that
your rootpath install is not pulling in dependencies on the host build
hardware config.
I don't buy this. First of all, installing Fedora nowadays simply
amounts to
1. Prepare target file systems
2. installing packages to target file systems
3. write out some configuration files
4. potentially do some boot loader stuff (maybe do a new initramfs)
(5. potentially relabel the OS)
and you can inspect this by looking at all the RPM's and how the OS in
general work. If anaconda is doing other magic, we simple have to fix
the OS to make anaconda not do that. That's my stance anyway, not
everyone may like it.
Btw, ideally we'd didn't have 3., I note that we're doing pretty good
here, most of the OS works without nasty configuration files nowadays.
Sure, some things you can never get away with but my suggestion is to
move that to a firstboot / selectable at run-time scheme (examples are
keyboard configuration / language selection etc.)
Anyway, I think the bottom line is that if the package set yum/rpm pulls
in depends on your hardware configuration or anything else, then it's a
bug we need to fix in yum/rpm. One such bug actually exists, I just
filed it
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207600
Maybe it's just me doing it wrong though.
My solution is to do the install under qemu, which
also buys you a pure non-root system, which I don't know about you, but
running kadischi on any system other than a dedicated build system
scares the crap out of me (even after jkatz fixed the bugs where
kadischi via anaconda would nuke the host build systems timezone and
network configuration)
Well, running things in virtualized containers is always a safe bet,
but, really, I aim for pilgrim to be robust enough to not have to do
this. Reality is that you just have to be extremely careful when doing
things as root. It seems to work pretty well so far.
Btw, do qemu support x86_64 and ppc these days?
- I did like the conversation about stateless. They are different
projects, but the idea of hardware agnostic physically portable system
disks, is very interesting. Dare I bring up an idea that an alan cox
post a while back made me think of... (store a qemu system state file
on the liveiso, boot it, display it into a vnc window that (all
autostart), then when you shut down, save the qemu state, do an xdelta
diff on orig sysstate, upload data diff to usb-stick or gmailfs/ftp,
such that on next boot, you get your hibernated virtual desktop back
exactly as you left it...)
Again, I'm not sure why this is useful.
It sounds like what the target user wants is just a portable Fedora OS,
e.g. basically just a Fedora install on a USB stick. I don't see people
carrying CD's anyway, maybe I'm just old and skeptic.
The fact that this is hard today is that we default to an ext3 file
system. If we had a good file system with built-in compression (or
compressed rw block devices), I'd just use that... and use a livecd to
install the OS onto it.
(readers by now may have discovered that I'm in general a big fan of
solving problems at the deepest possible level even though it includes
punting features.)
It's long past time that fedora surpass ubuntu in livecd
features... I
hope this new development infusion gets us there in a hurry.
Personally I'm not afraid at all of 4 projects on this list (kadischi,
pilgrim, jkatz livecd stuffs, my stuffs). The more there are, the more
we'll copy good ideas from one another, and eventually integrate into a
great solution that will evolve out of all of this.
Yeah. I share that sentiment. Sounds like what you are trying to achieve
is not completely different from what I'm trying to achieve with
pilgrim. If you have patches, please send them this way. I'm likely to
reject some features though (like most free software maintainers I'm old
and grumpy for better or worse), I really want pilgrim to be small and
maintainable. Thanks.
David
4:32 p.m.
David Zeuthen wrote:
>- Regarding Jasper's thread about anaconda rootpath installs
being
>closer to "real" installs than your yum 'hack', ACK!!! One of my
>biggest complaints all along has been the utter dangerousness of doing
>the install as root on a particular host system, and having faith that
>your rootpath install is not pulling in dependencies on the host build
>hardware config.
>
>
I don't buy this. First of all, installing Fedora nowadays simply
amounts to
I was talking about using Anaconda to do LiveCD-to-system installs.
I apologize for the interruption, it seems that we are on two different
wavelengths.
Carry on.
J. Hartline
10:57 p.m.
> - Regarding Jasper's thread about anaconda rootpath installs
being
> closer to "real" installs than your yum 'hack', ACK!!! One of my
> biggest complaints all along has been the utter dangerousness of
doing
> the install as root on a particular host system, and having faith
that
> your rootpath install is not pulling in dependencies on the host
build
> hardware config.
I don't buy this. First of all, installing Fedora nowadays simply
amounts to
1. Prepare target file systems
2. installing packages to target file systems
3. write out some configuration files
4. potentially do some boot loader stuff (maybe do a new initramfs)
(5. potentially relabel the OS)
and you can inspect this by looking at all the RPM's and how the OS
in
general work. If anaconda is doing other magic, we simple have to fix
the OS to make anaconda not do that. That's my stance anyway, not
everyone may like it.
Btw, ideally we'd didn't have 3., I note that we're doing pretty good
here, most of the OS works without nasty configuration files
nowadays.
Sure, some things you can never get away with but my suggestion is to
move that to a firstboot / selectable at run-time scheme (examples
are
keyboard configuration / language selection etc.)
Anyway, I think the bottom line is that if the package set yum/rpm
pulls
in depends on your hardware configuration or anything else, then it's
a
bug we need to fix in yum/rpm. One such bug actually exists, I just
filed it
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207600
Maybe it's just me doing it wrong though.
No, I suspect you're just running into bugs under the rug. I agree
that it seems like much progress is being made on this front (meaning
the right goals are in place).
Here's another one I don't think I bothered to file- Does libselinux's
%pre/post still do an /sbin/init invocation? Honestly after I realized
that selinux isn't transparent (I.e. I can't move around my apache
docroot without knowing some selinux crap), I stopped using it and
caring about it. (I'll just wait for you smart redhat folks to fix it
and make it truly transparent so that I can enable it and not worry
about it. Till then I'll live without it)
Anyway, tieing into what you said about shell versus python, I almost
want to send an email like this to anaconda-devel and other lists-
Subject: Is anaconda "the installer"?
I.e. it seems like python (especially after my recent pygtk/glade
project I did for school) is in fact great for event driven GUIs. But
bash/sh should be the language IMO for "the installer". And anaconda
should be the GUI interface to "the installer". From my perusing of
anaconda code, I don't think thats how things are.
It's very interesting that you basically wrote your own installer. I
probably did as much or more work getting qemu to be my install engine.
What I would *like* to see, would be a (almost surely non-python
based) installer that is seperate from anaconda, which could be used by
livecd generators. (which you would have used, rather than doing it
yourself. I like your implementation choice, but I also still feel
pretty comfortable with my process which involves doing the completely
normal anaconda path under qemu).
> My solution is to do the install under qemu, which
> also buys you a pure non-root system, which I don't know about you,
but
> running kadischi on any system other than a dedicated build system
> scares the crap out of me (even after jkatz fixed the bugs where
> kadischi via anaconda would nuke the host build systems timezone
and
> network configuration)
Well, running things in virtualized containers is always a safe bet,
but, really, I aim for pilgrim to be robust enough to not have to do
this. Reality is that you just have to be extremely careful when
doing
things as root. It seems to work pretty well so far.
Certainly your writing your own installer seperate from anaconda can
give you a better feeling that tons of code isn't being run as root in
a way that it wasn't really designed (well) from the ground up to do.
But the other major thing is general security. If it wasn't code that
you had written yourself, how comfortable would you feel trying to use
your main workstation to generate a custom livecd (when it's churning
away in root-mode for hour/s)?
If my project is successful, I forsee people feeling much more
comfortable doing a -
(as root) yum install vsys (or local per user root-less install)
(as user) vsys generate liveiso \
--config=mediacenter_appliance.xml \
--addpackages=myfavoriteeditor,meld \
mylivedvd.iso
Btw, do qemu support x86_64 and ppc these days?
If you do a yum install qemu, you'll have qemu-x86_64 and qemu-ppc in
your path. I haven't actually used them though.
> - I did like the conversation about stateless. They are different
> projects, but the idea of hardware agnostic physically portable
system
> disks, is very interesting. Dare I bring up an idea that an alan
cox
> post a while back made me think of... (store a qemu system state
file
> on the liveiso, boot it, display it into a vnc window that (all
> autostart), then when you shut down, save the qemu state, do an
xdelta
> diff on orig sysstate, upload data diff to usb-stick or
gmailfs/ftp,
> such that on next boot, you get your hibernated virtual desktop
back
> exactly as you left it...)
Again, I'm not sure why this is useful.
This was me going completely off-list-topic. Total tangent.
Persistant (network) virtual desktops (different implementation than
youos, or whatever). I might be just a little ADD :)
-dmc/jdog
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
2:23 p.m.
On Thu, 2006-09-21 at 20:57 -0700, Jane Dogalt wrote:
Certainly your writing your own installer seperate from anaconda can
give you a better feeling that tons of code isn't being run as root in
a way that it wasn't really designed (well) from the ground up to do.
But the other major thing is general security. If it wasn't code that
you had written yourself, how comfortable would you feel trying to use
your main workstation to generate a custom livecd (when it's churning
away in root-mode for hour/s)?
Probably not very comfortable. Then again, we all run pretty security
sensitive code but normally that have been vetted by several OS vendors.
I rarely run random code as root that some dude sends to a mailing list
without reading it through. Btw, I expect people to do the same.. at
this point pilgrim is just that - random (ok, not exactly random, we use
it for OLPC) code being sent by a dude (the fact I work for Red Hat may
wrongly lead people to trust me more; it really shouldn't) on a mailing
list.
But I think it's doable to actually review the pilgrim code because it's
pretty simple and somewhat linear to read.
If my project is successful, I forsee people feeling much more
comfortable doing a -
(as root) yum install vsys (or local per user root-less install)
(as user) vsys generate liveiso \
--config=mediacenter_appliance.xml \
--addpackages=myfavoriteeditor,meld \
mylivedvd.iso
Yea. Using some kind of container (qemu, xen, whatever) / jail (e.g.
chroot) is probably a good idea. I don't see that being hard to add to
pilgrim, though, the container approach raises an interesting Chinese
Box paradox: how do you build the container in the first place? :-)
David
6:20 p.m.
--- David Zeuthen <davidz(a)redhat.com> wrote:
On Thu, 2006-09-21 at 20:57 -0700, Jane Dogalt wrote:
> Certainly your writing your own installer seperate from anaconda
can
> give you a better feeling that tons of code isn't being run as root
in
> a way that it wasn't really designed (well) from the ground up to
do.
>
> But the other major thing is general security. If it wasn't code
that
> you had written yourself, how comfortable would you feel trying to
use
> your main workstation to generate a custom livecd (when it's
churning
> away in root-mode for hour/s)?
Probably not very comfortable. Then again, we all run pretty security
sensitive code but normally that have been vetted by several OS
vendors.
I rarely run random code as root that some dude sends to a mailing
list
without reading it through.
Thats an obvious issue, but even if I had all the trust in the author,
I'd still be trusting all of those %pre/%post scripts, and whatever
other stuff, as root. I know redhat/fedora have relatively stellar
quality control (I actually mean that), but still, I'd much rather run
those hundreds of pre/post scripts and whatnot from extras or less
vetted repositories, in a container as you say.
> If my project is successful, I forsee people feeling much more
> comfortable doing a -
>
> (as root) yum install vsys (or local per user root-less install)
> (as user) vsys generate liveiso \
> --config=mediacenter_appliance.xml \
> --addpackages=myfavoriteeditor,meld \
> mylivedvd.iso
Yea. Using some kind of container (qemu, xen, whatever) / jail (e.g.
chroot) is probably a good idea. I don't see that being hard to add
to
pilgrim, though, the container approach raises an interesting Chinese
Box paradox: how do you build the container in the first place? :-)
I'm a bit fuzzy on your philisophical allusion, but I'll posit a couple
of answers, which may or may not have anything to do with your point-
1) cryptic riddle answer: (use '-snapshot -hda X -hdb Y' | X==Y)
2) project genesis:
- how do you build the container? - presumably an almost unanswerable
bootstrapping issue, but my answer-
- take fc5 for now, make a lower order bootstrap later if
desired
- I.e. what I want to see:
yum install vsys
vsys generate liveiso -config=fc5_genesis.xml fc5genesis.iso
qemu-img create /tmp/fc5stuffs.img 50G
qemu-img create /tmp/scratcharea.img 50G
qemu -boot d -hda /tmp/scratcharea.img -cdrom fc5genesis.iso
tar tvzf /tmp/fc5stuffs.img
which utilizes only for input an implicit connection to the fc5 normal
installer dvd and source iso images (or simple http/ftp tree thereof)
and after some period of time (week?) ultimately produces the following
output
./fc5-x86_install_dvd.iso
# (binaries compiled from scratch, using bootstrap of orig fc5
binaries)
./fc5_sources_dvd.iso
# if you really want to get crazy and add 2 weeks of build time
./fc5-ppc_install_dvd.iso
(and/or simple http/ftp tree thereof).
(and by install_dvd, I mean the things fedora/redhat ships today)
(and if you want to add another few days of build time, you can include
a set of regression tests against the install_dvd.iso's, by
qemu/container booting them before shutting down to tell the user the
output is ready. And of course all this can churn away happily on a
headless server farm... bwa ha ha ha....)
-dmc/jdog
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
1:03 p.m.
New subject: bootstrapping/genesis, was Re: Welcome Pilgrims, please don't take our land...
A couple clarifications/typofixes, lest I confound people...
2) project genesis:
- how do you build the container? - presumably an almost
unanswerable
bootstrapping issue, but my answer-
- take fc5 for now, make a lower order bootstrap later if
desired
- I.e. what I want to see:
yum install vsys
vsys generate liveiso -config=fc5_genesis.xml
fc5genesis.iso
qemu-img create /tmp/fc5stuffs.img 50G
qemu-img create /tmp/scratcharea.img 50G
qemu -boot d -hda /tmp/scratcharea.img -cdrom
fc5genesis.iso
I forgot to type -hdb /tmp/fc5stuffs in there. And the explicit qemu
invocation was for illustrative purposes. Really I'd use
"vsys runimage <options> fc5genesis.iso", which is a wrapper with a
security enhanced version of the embedded vnc option that got added
recently to qemu (amongst other niceties).
Second, my comment below about implicit connection to sources, just
means that the default qemu invocation allows outgoing networking
through the host, thus you can pull the fedora repos from the net,
rather than providing them to the qemu system in another fashion.
Last, obviously fc5->fc5 is only illustrative. fc5->fc6 or
fc5->latest_rawhide, might be more useful. (perhaps combined with as
easy to use a method for distributing the build across many systems
running the same build hosts (in containers, via copying/sharing the
genesis .iso))
But of course all of this very much a second priority to simply besting
the featureset of ubuntu et al... (and doing the multitude of cool
stuff with a livecd generator that is much cooler for end users than
the genesis stuff)
-dmc/jdog
tar tvzf /tmp/fc5stuffs.img
which utilizes only for input an implicit connection to the fc5
normal
installer dvd and source iso images (or simple http/ftp tree thereof)
and after some period of time (week?) ultimately produces the
following
output
./fc5-x86_install_dvd.iso
# (binaries compiled from scratch, using bootstrap of orig fc5
binaries)
./fc5_sources_dvd.iso
# if you really want to get crazy and add 2 weeks of build time
./fc5-ppc_install_dvd.iso
(and/or simple http/ftp tree thereof).
(and by install_dvd, I mean the things fedora/redhat ships today)
(and if you want to add another few days of build time, you can
include
a set of regression tests against the install_dvd.iso's, by
qemu/container booting them before shutting down to tell the user the
output is ready. And of course all this can churn away happily on a
headless server farm... bwa ha ha ha....)
-dmc/jdog
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
Fedora-livecd-list mailing list
Fedora-livecd-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-livecd-list
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
6420
days inactive
6425
days old
livecd@lists.fedoraproject.org
7 comments
4 participants
participants (4)
-
Chitlesh GOORAH -
David Zeuthen -
J. Hartline -
Jane Dogalt