Re: moving kickstart forward

+1 for partitioning work and better boot disk selection/configuration.
The majority of our %pre is taken up with device-mapper/python code to determine what the OS disk should be across different HW models.

Internal raid 
JBOD
Boot from SAN
Boot from FLASH/SD

I will add, and possibly just us not doing our homework, that networking with rhel7 kickstart is a bit of learning curve. We are having trouble getting kickstart to only plumb and configure the nic that the PXE/DHCP request came over. It kickstarts, installs, reboots and now eth0 is configured but the nic with the public interface is now eth2 or eth3 .





On 3/8/16, 4:33 PM, "[email protected] on behalf of Chris Lumens" <[email protected] on behalf of [email protected]> wrote:

>> We use %pre to obtain info about the system like:
>> Which NIC to configure
>> Hostname
>> IP
>> MASK
>> Primary user
>> Admin user
>> What OU the host should be added
>> And the original proc/cmdline (so I can get some info like what kickstart
>> file was originally used in the PXE boot)
>> 
>> These are all placed in /tmp/installVars as key=value
>
>This is yet another vote for doing this in kickstart.  It seems like
>probably the #1 thing everyone wants, and then maybe #2 is either user
>interaction/logging or better partitioning.  I'll put this on my todo
>list accordingly.
>
>> It would be GREAT if we could get user input a little easier than using our
>> own scripts in %pre
>> 
>> I would like to +1 on the getting "%pre --log /tmp/ks-pre.log" working,
>> currently my work around is
>> exec < /dev/tty3 > /dev/tty3 2>&1
>> chvt 3
>> (
>> ...
>> ) 2>&1 | /usr/bin/tee -a /tmp/ks-pre.log
>
>Every time I see this exec/chvt/tty stuff my eyes just glaze over.
>
>But yes, it does seem like everyone's built their own method for either
>prompting for bits of data or for doing progress reporting.  I think we
>were initially hesitant to do this because we saw kickstart as entirely
>non-interactive and also because anaconda wasn't really much of a
>library.  It is probably time for us to define a real API here.
>
>So, I'll ask some followup questions just for this.
>
>What kinds of user interactions do people want to do?  Do you want this
>to happen in the graphical interface or the text interface?  Both?
>
>When do you want to do them?  In pre or post?  During the installer
>proper?  Could whatever you are doing be turned into an anaconda addon?
>
>Do you want results going to the log file?  To the console?  To whatever
>the interface is?
>
>- Chris
>
>_______________________________________________
>Kickstart-list mailing list
>[email protected]
>https://www.redhat.com/mailman/listinfo/kickstart-list