Kickstart feels more like a Kickstand...

/etc/dnsmasq.conf - Had to enable TFTP and reset the TFTP root folder option to /tftpboot/netboot which is already symbolically linked to the Apache served files in /var/www/html/pub. I have ensured that all of the necessary files for the Kickstart have been placed into this folder, and I have edited several files to ensure they all now point to the /tftpboot/netboot/ folder. This was done in an attempt to simplify the process and make it more understandable.

In the /etc/dnsmasq I had to enable the built in tftp server in DNSMASQ, which had not been enabled. I believe this is only needed if you're using the 'integrated' tftp server that is a part of DHCP, but it did not help. The default TFTP server had been enabled, but cannot be started independently as a service, as xinetd.d handles what inetd used to. I attempted to tftp into this server from a near by machine, and noticed I was faced with nothing but timeouts or route to host errors (most of the time). I can only seem to get files consistently across localhost (127.0.0.1, and yes, you need to use 127.0.0.1 as using localhost will likely require a –noipv6 flag should it have one. Additionally, the folder that was set as the root directory for tftp files has also been set to /tftpboot/netboot in order to make things simpler.

The last time I made a post I remember I had come across a root-path "file/location/here" for the DHCP server, which has also been set to /tftpboot/netboot. There are now 2 copies of the Oracle Linux 7 ISO. One is live mounted at bootup via /etc/fstab/ and is mounted in /tftpboot/netboot/OL7/ as well as there being a full, unmounted ISO in /tftpboot/netboot/OL7.iso I noticed that 'ftp' paths should be avoided, and either NFS, or HTTP should be used in the Kickstart file, as it wouldn't actually pull the files needed. I changed anything that was pointed to an 'ftp' server in the ks.cfg, the /tftpboot/pxelinux.cfg/default.

I took a look at the Kickstart file and passed it through a KS file validator by running the command, "ksvalidator /tftpboot/netboot/ks.cfg -e -i" to show me all of the possible errors, or files that are improperly pointed too within the setup. I was shown that one of the command flags I believed I initially needed "--nobase" was no longer needed, and in fact deprecated in an older version, which the terminal suggested could have been the cause of my error. After removing the imrproper syntax, it appears as though I got no output from running KSValidator.

While not directly news, I have been able to get the Blue KS install selection screen to pop-up occasionally (the screen from which KS installs normally occur), but it still seems incredibly sporadic. I'm wondering if this will require reducing the DHCP size, and possible finding some way for the Kickstart to know how to differentiate between our DHCP servers, and the ones used for kickstart. Sometimes the PXE boot will say there are no TFTP files in 149.61.33.10, which is one of the DNS servers. Other times, it will appear to load, and get about as far as it used to, but now it shows the root-path as /tftpboot/ as that is where the pxelinux files are containing the menu, and memdisk. It still occasionally freezes after setting up the ethernet adapter, but further googling has brought me to an interesting conclusion.

Another user mentioned that if you use the text install via kickstart, if there appear to be any incorrect settings related to partition(s), sizing, or file systems, then Anaconda will fail to work through the Kickstart configuration file as intended, and give us behavior similar to what we see: the KS process halting. I would like to believe that the KS tester (ksvalidator) would have given me errors, or verbose output stating that there other sources of error, however, at this point, I'm not even sure how well those tools work. I have also changed the adapter from 'em0' to 'eth0' in each file, and restarted services to see if it would help the installation work properly, but that did not help. Online I discovered there is essentially an "auto" option called "link". Typically, the kernel will simply work with the first device that is linked to a network, and it should still use DHCP and IPv4 settings set via the KS file. I forcefully added a --noipv6 line to the Kickstart configuration to rule out the possibility that was causing issues.

After toying with the majority of these configurations, I have uploaded a forum post to the Oracle forums (with a link to the majority of the configuration files minus the IP’s in the dhcpd config) to see if someone else with more Kickstart experience can help us out. I have a hunch that it may be a result of an improperly pointed .iso, .cfg file, or possibly improperly partitioned. The post can be located here: https://community.oracle.com/message/13198962#13198962

Just out of curiousity, I decided to check /root/anaconda-ks.cfg (the file that gets auto-created upon default Oracle Linux 7 install to attempt to duplicate your exact installation setup) and attempted simply changing the install source from an ISO to be done over the network. It still looks like the process times out at the same spot, and we know that these partitioning options should work, as they've been in use for some time now on the PXEBoot server. Accidentally forgot to comment out 2 of the additional repositories that the Anaconda-KS.cfg contained. Kickstart is known to stop if it cannot locate a package, the route to the host server, or is given a command which it cannot process. After trying to play with this configuration, I was shown the issue where the KS client connects to the campus's DNS server and fails to find a route to the Server. This leads me to believe that it may be network/dhcp related, so I will make a backup of that config, and see if we can get something out of this.

It seems that by setting the DNS servers to the PXEBoot server (possibly now that DNSMasq is enabled, can't say for sure) but it appears as though we consistently timeout in the same black and white text based screen. I'm wondering if previously it was attempting to check the DNS server, and route back first, but I believe Harris said that most of our hardware utilizes OSPF networking topology to ensure that everything travels through the shortest open path first to reach its destination. Edit: Nevermind, upon rebooting (despite having reset the dhcp service... I'm guessing this is a xinetd related thing) it still works sporadically, so I am reverting back to the old config.

While checking online pxelinux.cfg's, I noticed that the initrd.img and vmlinuz that you grab are LINUX DISTRIBUTION SPECIFIC! Meaning should we get this working for Oracle Linux 7.1 x86-x64, we would need to pull new vmlinuz and initrd files for each other OS or modified install and package those all together in a subdirectory of the tftpboot folder. This should not be an issue, as both files have been obtained from the OL7.1 ISO.