On Wed, 2006-09-20 at 19:07 -0700, Jane Dogalt wrote:
- 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).
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
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
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
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
I don't buy this. First of all, installing Fedora nowadays simply
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
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
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
It's long past time that fedora surpass ubuntu in livecd
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