+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, "kickstart-list-bounces@xxxxxxxxxx on behalf of Chris Lumens" <kickstart-list-bounces@xxxxxxxxxx on behalf of clumens@xxxxxxxxxx> 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 >Kickstart-list@xxxxxxxxxx >https://www.redhat.com/mailman/listinfo/kickstart-list _______________________________________________ Kickstart-list mailing list Kickstart-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/kickstart-list