On 06/03/2014 03:09 PM, Colin Walters wrote:
On Tue, Jun 3, 2014, at 10:51 AM, Gene Czarcinski wrote:
For many years I have been a big fan of kickstart installs with large
kickstart files with everything to be installed specified. Recently, I
have had the opportunity to use live installs and am impressed with what
they can do and how they basically work.
Can you elaborate on that? What specific aspects? Is it the
try-before-you-buy?
It is not a question of IF I am going to install a Fedora release but
HOW (the process) I use to install it.
1. All systems are connected to the Internet or have a local cache of
all packages needed for the install plus any post-install packages as well.
2. While the virtual (test) systems are all pretty simple and kickstart
seems to work well for that, the real large systems are far more
complicated and it is for these systems that I am considering
alternatives to kickstart. There are only three different "types" of
systems and each instance of a type has the same software installed
regardless of whether specific software normally runs on that instance
or not.
3. I already use a post-install script to install stuff from rpmfusion
as well as other stuff.
4. Specifically, I am considering using a Live Install to create a
basic system followed by running a post-install script (not anaconda
kickstart post install).
The problem:
While it might take a few attempts, once a kickstart file "works," you
can depend on the resulting system being correct. Each system is
multiboot and I never destroy a currently working system to install a
new one (I do not do fedup). The problem with the Live Install followed
by a post-install script is that there are currently some things that
must be done manually and thus subject to human error:
a) Specifying the hostname.
b) Specifying the disk, partition, and filesystem parameters.
There is also the issue of not being able to set where (which drive's
MBR) will be used for the bootloader. As far as I can tell, a liveinst
will always install the bootloader in the MBR of the first drive and
this is something I do not always want done. A realistic alternative is
to install grub2 (or extlinux) but do not configure or install it.
One problem I forsee is that re-enableing --kickstart=<xxx> for only a
limited subset may raise some false expectations in some users.
Therefore, I suggest that a new parameter be used such as
--liveconfig=<xxx>.
While I sure would appreciate it if one of you anaconda experts stepped
up an implemented this functionality, I am not above doing it myself.
If I did, how would a patch submit be received? Also, there is
fedora.next and the Fedora Atomic Initiative. Any potential or real
conflicts with them?
Comments?
I realize that what I am doing is not something that Fedora targeted,
but doing something positive, that was not an intended function, should
be expected for Fedora.
Gene
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
