12:13 a.m.
I just noticed that fedora projects weekly says jasper provided a patch for the
hdd installs. Was this a typo? The link only points to a message about the
possibility of creating one, not an actual patch.
-jdog
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
3:56 a.m.
Jane Dogalt wrote:
I just noticed that fedora projects weekly says jasper provided a
patch for the
hdd installs. Was this a typo? The link only points to a message about the
possibility of creating one, not an actual patch.
I did go through the process of creating one, but it was very obtuse and
wouldn't have been accepted
by Anaconda dev. The problems lie within Anaconda, if you would like I
can briefly go over them in a message
to the list, perhaps someone wants to help submit patches to Anaconda
dev and/or file RFEs?
J. Hartline
3:26 a.m.
--- Jasper O'neal Hartline <jasperhartline(a)adelphia.net> wrote:
Jane Dogalt wrote:
>I just noticed that fedora projects weekly says jasper provided a patch for
the
>hdd installs. Was this a typo? The link only points to a message about the
>possibility of creating one, not an actual patch.
>
>
>
I did go through the process of creating one, but it was very obtuse and
wouldn't have been accepted
by Anaconda dev. The problems lie within Anaconda, if you would like I
can briefly go over them in a message
to the list, perhaps someone wants to help submit patches to Anaconda
dev and/or file RFEs?
Yes.
I'm guessing what we're talking about here is something akin to whats on the
ubuntu live desktop cd, as the 'install' icon on the desktop (haven't
actually
clicked it yet, so I can only speculate as to what it does).
The basic gist would seem to be an anaconda that was happy running under a
window in X (like kadischi currently uses, but not rootpath, i.e. it does do
partitioning, but like rootpath in that it is more hands-off WRT the running
system).
An alternative to that (and I think both alternatives have their usefulness)
would be something which just does GUI partitioning, and then installs the
livecd system itself to the harddrive (mkfs's the new partition, copies the
squashfs contents, undoes the changes that were made specifically for the
livecd environment).
A third alternative which I'd like to see is the "rebootless installer
livecd".
I.e.-
livecd system is implemented as a read-only ext3 filesystem image,
copy-on-write is provided by devicemapper snapshot using a sparse ext3 image
file created in tmpfs, and both of those things being devicemapper mirrors
which are initially created and used as broken. Then if the user decides to
install to disk, the mirrors are unbroken/fixed by duping them onto the
harddisk the user configured to use. Then they are rebroken from the cd&tmpfs,
and what you are left with is the livecd environment migrated onto the
harddisk, and a fully usable system, with ejectable/usable cddrive, which has
been fully installed without the need to ever reboot.
(yes, I'm going off the deep end of ambition again...)
-jdog
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
6:02 a.m.
Jane Dogalt wrote:
I'm guessing what we're talking about here is something akin
to whats on the
ubuntu live desktop cd, as the 'install' icon on the desktop (haven't
actually
clicked it yet, so I can only speculate as to what it does).
The basic gist would seem to be an anaconda that was happy running under a
window in X (like kadischi currently uses, but not rootpath, i.e. it does do
partitioning, but like rootpath in that it is more hands-off WRT the running
system).
Not particularly. It would use rootpath method, just with partitioning.
Partitioning and mounting the system under /mnt/sysimage is no problem
for Anaconda.
(Provided the work is done to make that happen).
Just so you aren't hanging on by the edge of your seat, I was able to
get Anaconda,
running from te LiveCD with Kadischi/Anaconda payload installed to right
at installing packages.
The place I stopped was during an exception in grabber.py in urlgrabber
module for Python while
trying to read the header files in /tmp/cache/headers saying xxx.hdr
doesn't exist in /tmp/cache.
I'm unsure if the Anaconda devs are interested in the porblems I've run
over also.
In any case hang tight, and I'll try to put together a concise list of
items needing fixing in Anaconda
for harddrive installations from the LiveCD.
J. Hartline
8:17 a.m.
On Thu, 2006-07-13 at 01:26 -0700, Jane Dogalt wrote:
An alternative to that (and I think both alternatives have their
usefulness) would be something which just does GUI partitioning, and
then installs the livecd system itself to the harddrive (mkfs's the
new partition, copies the squashfs contents, undoes the changes that
were made specifically for the livecd environment).
Doing this is an extremely bad and dangerous proposition. There are way
too many things that you can't really just "undo" from a live CD. I've
been through this before, I think even on this list...
Jeremy
9:28 a.m.
On Thu, 2006-07-13 at 09:17 -0400, Jeremy Katz wrote:
On Thu, 2006-07-13 at 01:26 -0700, Jane Dogalt wrote:
> An alternative to that (and I think both alternatives have their
> usefulness) would be something which just does GUI partitioning, and
> then installs the livecd system itself to the harddrive (mkfs's the
> new partition, copies the squashfs contents, undoes the changes that
> were made specifically for the livecd environment).
Doing this is an extremely bad and dangerous proposition. There are way
too many things that you can't really just "undo" from a live CD.
I've
been through this before, I think even on this list...
Jeremy, are there plans to produce any sort of combination live
CD/installer for Fedora 6 (preferably on a DVD)? For those of us who
want to redistribute Fedora, it would be great to be able to show a live
CD, then have the user install from the same medium.
Out of necessity, I put together a live CD that I distributed with the
Fedora 5 Bible (obviously experimental and unsupportedTM). From the boot
prompt, they could either run the live CD or launch the installer to do
a permanent install from the network or other medium.
While having a live CD and install DVD sit side-by-side on the same
medium is not as interesting from a technical standpoint, it could be
useful (as a minimum goal) from a marketing standpoint.
Thoughts?
-- Chris Negus
1:56 a.m.
Hello LiveCD-Folks,
Am Donnerstag, den 13.07.2006, 09:28 -0500 schrieb Chris Negus:
Jeremy, are there plans to produce any sort of combination live
CD/installer for Fedora 6 (preferably on a DVD)? For those of us who
want to redistribute Fedora, it would be great to be able to show a live
CD, then have the user install from the same medium.
Of course it would be great.
Best would be to be able to start anaconda directly from the running
live system. Kadischi is doing this already when producing livecd
images, so why should this not be possible from the running livecd
system?
One benefit of this is: the livecd kernel is exactly the same kernel
which will be installed - so every piece of hardware available to this
kernel will be found on boot, too.
(So the common problem of e.g. hard drive controllers which are
recognized by the install kernel and not by the boot kernel is done in
this case)
One could even load additional drivers, creating/resizing partitions,
backup data a.s.o. during/before installation. This would be a major
benefit compared to actual installation procedure.
My idea would be to include a modified version of the kickstart file on
the cd, which should allow an exact (part-time-interactive) installation
of all things on the livecd (except kadischi extras and things installed
in later stages of livecd production). Part-time-interactive means, that
partitioning, security and policy configuration etc. have to be
interactive, package selection not.
And if we ship anaconda already, this could be used for some kind of
"normal" installation, too (without using the kickstart file)
Of course the preferred and in some cases only possible installation
method must be network based.
Out of necessity, I put together a live CD that I distributed with
the
Fedora 5 Bible (obviously experimental and unsupportedTM). From the boot
prompt, they could either run the live CD or launch the installer to do
a permanent install from the network or other medium.
This is another option I don't like so much.
Regards,
Ingo
--
"Milchreis schmeckt hervorragend, wenn man ihn kurz vor dem Verzehr
durch ein saftiges Steak ersetzt."
gefunden bei frag-mutti.de
3:02 a.m.
On Fri, 2006-07-14 at 08:56 +0200, Ingo Schaefer wrote:
Hello LiveCD-Folks,
Am Donnerstag, den 13.07.2006, 09:28 -0500 schrieb Chris Negus:
> Out of necessity, I put together a live CD that I distributed with the
> Fedora 5 Bible (obviously experimental and unsupportedTM). From the boot
> prompt, they could either run the live CD or launch the installer to do
> a permanent install from the network or other medium.
This is another option I don't like so much.
I agree. Yours, and other people's, suggestion to start the installer
from the running live CD is a much better idea. This is why I was hoping
that there was a plan to make an official version of such a DVD. I'm
guessing that the fact that there isn't even an official Fedora live CD
yet might be an inhibiting factor.
-- Chris Negus
10:31 a.m.
Jeremy Katz wrote:
On Thu, 2006-07-13 at 01:26 -0700, Jane Dogalt wrote:
>An alternative to that (and I think both alternatives have their
>usefulness) would be something which just does GUI partitioning, and
>then installs the livecd system itself to the harddrive (mkfs's the
>new partition, copies the squashfs contents, undoes the changes that
>were made specifically for the livecd environment).
>
>
Doing this is an extremely bad and dangerous proposition. There are way
too many things that you can't really just "undo" from a live CD. I've
been through this before, I think even on this list...
Right. First of all it is SquashFS which is only appendable, not writeable.
Second, Fedora Core is too robust of an operating system to just "copy
the LiveCD to disk".
Fedora Core isn't *known* to be a LiveCD, it is known for it's
full-fledgedness.. so..
this warrants nothing less than a fully featured, as in with Anaconda,
harddrive installation.
J. Hartline
3:20 p.m.
--- Jasper O'neal Hartline <jasperhartline(a)adelphia.net> wrote:
Jeremy Katz wrote:
>On Thu, 2006-07-13 at 01:26 -0700, Jane Dogalt wrote:
>
>
>>An alternative to that (and I think both alternatives have their
>>usefulness) would be something which just does GUI partitioning, and
>>then installs the livecd system itself to the harddrive (mkfs's the
>>new partition, copies the squashfs contents, undoes the changes that
>>were made specifically for the livecd environment).
>>
>>
>
>Doing this is an extremely bad and dangerous proposition. There are way
>too many things that you can't really just "undo" from a live CD.
I've
>been through this before, I think even on this list...
>
>
Right. First of all it is SquashFS which is only appendable, not writeable.
That really has nothing to do with the issue. You would make an ext3
filesystem on the disk, and copy the files (not the filesystem image) to the
new filesystem.
Second, Fedora Core is too robust of an operating system to just
"copy
the LiveCD to disk".
That statement lacks any technical meaning.
Fedora Core isn't *known* to be a LiveCD, it is known for
it's
full-fledgedness.. so..
this warrants nothing less than a fully featured, as in with Anaconda,
harddrive installation.
Just because a user of such a theoretical livecd installer could install a
specific type of fedora system (the type the livecd creator put on the livecd),
does not restrict the user from installing fedora as fully or minimally as they
like using the traditional methods. I was not proposing a replacement for the
official fedora installation procedure. Rather I was proposing an additional
feature for a livecd generation tool. (and thereby some subset of the livecds
produced with said tool).
-jdog
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
3:15 p.m.
--- Jeremy Katz <katzj(a)redhat.com> wrote:
On Thu, 2006-07-13 at 01:26 -0700, Jane Dogalt wrote:
> An alternative to that (and I think both alternatives have their
> usefulness) would be something which just does GUI partitioning, and
> then installs the livecd system itself to the harddrive (mkfs's the
> new partition, copies the squashfs contents, undoes the changes that
> were made specifically for the livecd environment).
Doing this is an extremely bad and dangerous proposition. There are way
too many things that you can't really just "undo" from a live CD.
Not if the livecd generation tools are designed well. (including the
appropriate 'undo' information).
-jdog
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
3:22 p.m.
On Thu, 2006-07-13 at 13:15 -0700, Jane Dogalt wrote:
--- Jeremy Katz <katzj(a)redhat.com> wrote:
> On Thu, 2006-07-13 at 01:26 -0700, Jane Dogalt wrote:
> > An alternative to that (and I think both alternatives have their
> > usefulness) would be something which just does GUI partitioning, and
> > then installs the livecd system itself to the harddrive (mkfs's the
> > new partition, copies the squashfs contents, undoes the changes that
> > were made specifically for the livecd environment).
>
> Doing this is an extremely bad and dangerous proposition. There are way
> too many things that you can't really just "undo" from a live CD.
Not if the livecd generation tools are designed well. (including the
appropriate 'undo' information).
The entire reason you do huge chunks of the changes is due to the fact
that you have limited space with a live CD. It's hard to include undo
information for things you remove without including them, thus negating
the entire point of removing them.
Jeremy
3:25 p.m.
--- Jeremy Katz <katzj(a)redhat.com> wrote:
On Thu, 2006-07-13 at 13:15 -0700, Jane Dogalt wrote:
> --- Jeremy Katz <katzj(a)redhat.com> wrote:
> > On Thu, 2006-07-13 at 01:26 -0700, Jane Dogalt wrote:
> > > An alternative to that (and I think both alternatives have their
> > > usefulness) would be something which just does GUI partitioning, and
> > > then installs the livecd system itself to the harddrive (mkfs's the
> > > new partition, copies the squashfs contents, undoes the changes that
> > > were made specifically for the livecd environment).
> >
> > Doing this is an extremely bad and dangerous proposition. There are way
> > too many things that you can't really just "undo" from a live CD.
>
> Not if the livecd generation tools are designed well. (including the
> appropriate 'undo' information).
The entire reason you do huge chunks of the changes is due to the fact
that you have limited space with a live CD. It's hard to include undo
information for things you remove without including them, thus negating
the entire point of removing them.
I was actually thinking more in terms of live-dvd's or live-blu-rays. I agree,
there are situations where for space considerations you remove certain files,
and in such situations, said files could not be included as 'undo' information
(except perhaps as url references to be downloaded should a net connection be
available).
But again, I was not suggesting that such a theoretical installation mechanism
be a *mandatory feature of all kadischi output*. But rather it be an
*optional* feature used by some particular livecd configurations, when
operational/design considerations warrant that it would be a useful feature.
-jdog
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
10:48 a.m.
--- Jeremy Katz <katzj(a)redhat.com> wrote:
On Thu, 2006-07-13 at 01:26 -0700, Jane Dogalt wrote:
> An alternative to that (and I think both alternatives have their
> usefulness) would be something which just does GUI partitioning, and
> then installs the livecd system itself to the harddrive (mkfs's the
> new partition, copies the squashfs contents, undoes the changes that
> were made specifically for the livecd environment).
Doing this is an extremely bad and dangerous proposition. There are way
too many things that you can't really just "undo" from a live CD.
I've
been through this before, I think even on this list...
Believe me that I realize the impact of using Microsoft to bolster my argument,
but that being said...
It appears Vista is taking my approach, and IMO it's the smartest thing they've
ever done-
http://slashdot.org/article.pl?sid=06/07/24/1250220
Personally I can't wait until this becomes standard for the major linux
distros, with perhaps the extension of the rebootless version (i.e. just a
livedvd that boots, and can optionally be live-migrated to the hard disk, using
dm snapshot and mirror tricks, along with ext3 online resizing).
-jdog
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
8:39 a.m.
Here is the outline below for Anaconda on LiveCD to install from HDD:
1) Don't use rootpath method at all, Anaconda handles this already
during a real installation
2) Setup Kadischi patches for running using --hddinstall flags
3) Setup Anaconda to use --livecd or --hddinstall flags (--livecd method
already in development)
4) In fsset.py utilities are in /sbin not /usr/bin or /usr/sbin like
mke2fs and mkfs.jfs or tune2fs
5) Anaconda shows only Ext2 to be available from LiveCD installs
6) Let Kadischi run in --hddinstall mode only if /.livecd file is
present (This is an Kadischi internal problem)
7) (This may be fixed in CVS) During mkDMNode() we fail if devices
already exist in /dev
8) Syslogd.py module is invoked with the wrong filepath. (/sbin vs.
/usr/sbin problems etc.)
This is in particular order in which problems were encountered.
I have rectified the problems yet I still get a failure on "usermod
cannot be run" during fsset.py and right before installing packages.
Thanks
J. Hartline
Jane Dogalt wrote:
--- Jasper O'neal Hartline <jasperhartline(a)adelphia.net>
wrote:
>Jane Dogalt wrote:
>
>
>
>>I just noticed that fedora projects weekly says jasper provided a patch for
>>
>>
>the
>
>
>>hdd installs. Was this a typo? The link only points to a message about the
>>possibility of creating one, not an actual patch.
>>
>>
>>
>>
>>
>I did go through the process of creating one, but it was very obtuse and
>wouldn't have been accepted
>by Anaconda dev. The problems lie within Anaconda, if you would like I
>can briefly go over them in a message
>to the list, perhaps someone wants to help submit patches to Anaconda
>dev and/or file RFEs?
>
>
Yes.
6475
days inactive
6490
days old
livecd@lists.fedoraproject.org
14 comments
5 participants
participants (5)
-
Chris Negus -
Ingo Schaefer -
J. Hartline -
Jane Dogalt -
Jeremy Katz