Jesse Keating wrote:
On Tue, 2009-07-14 at 11:19 -0400, Colin Walters wrote:
There's no such step in the live install (right?). Now, it would
likely make sense to have such a mechanism, but it would need design.
I forget offhand too how the PackageKit updater works in the live
image (do we disable it by default?).
With the Anaconda live installer, it's the raw unmodified live
filesystem that is "copied" to the newly partitioned disk(s). Ergo any
rpm updating you do on the LiveOS before you start the installer will be
lost.
It appears that Doglas' installer uses the in use LiveOS so that the
changes you make while running the LiveOS before starting the install
will be carried over into the install.
Douglas, JDog, whatever... But correct characterization, with the added
'changes you make while running the LiveOS before, during, and after
starting the install will be carried over into the install'.
That in itself seems interesting enough to explore and see if we can't
get the same functionality, to some extent into Anaconda.
Yes, this is a subtle distinction you have made. An entirely different
feature, could be to simply run the current LiveOS installer as is,
except instead of using the pristine (i.e. pre-boot, no changes from the
running LiveOS) image, you could use a snapshot of the image as it is at
the time of the start of installation. That would go back to your
wording above instead of my correction, i.e. only changes made prior to
the start of installation would get copied over, _and_ you would then
need to reboot into the new OS as is currently normal.
As for rebootless, that's interesting too. I'm glad you were able to
demo the technology within your installer, but I'd worry about the
duplication of effort/code to have yet another program that is designed
to discover disks,... There is a lot of logic code in
Anaconda to get the partitioning correct ....
This is all I believe 100% in line with what I said in the
progenitor/top post. If this feature is to remain in Fedora in the
longterm, Anaconda is absolutely the right place for it, for all the
reasons you mentioned.
However, even though over a year ago I had skimmed all the relevant
parts of anaconda, the reason I chose to go the route I did were
a) lack of complexity. The first iteration of my installer was just a
100 line bash script. Thus narrowing my task to just writing a GUI
front end for it, simplified things.
b) educational value- This was a great, relatively simple, pygtk-glade
exercise for me.
c) the whole unionfs issue. There is *very real possibility* that
Fedora may decide to go the ubuntu LiveOS architecture once a solid
unionfs is in mainline. Depending on implementation- if going with the
ubuntu native squashfs for instance, it may then be impossible to have
RebootlessInstallation as an additional optional feature on the same
LiveOS.
I will be more than happy making or helping to make the anaconda
implementation of this feature, if I can be assured that it will have
some longevity. I really think going with zyx-liveinstaller (my thing)
for F12 is the right answer to put this feature out there before people,
to determine if it is something that we want to really start doing some
serious additions to anaconda for.
Perhaps jkatz or others can and don't mind just whipping up an anaconda
implementation in the next few weeks. But I didn't see much(any)
interest on fedora-livecd-list, and I'm making a wild guess here- that
everybody (especially those getting paychecks) have plenty on their
plate in the near future already.
I think your work is great and useful though!
That means a lot. Back at you 10X, I know you and others here have done
vast amounts of very hard, often unrewarding work keeping Fedora in shape.
peace...
-dmc
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
