Nope, it doesn't add it to the kernel boot parameters. That was the first thing I checked. As for the bootproto ... DUH. I didn't check that. :) That being solved, yeah it's not bringing up the add-in card now when it boots up. On Thu, Feb 26, 2015 at 12:50 PM, Jason Warr <jason at warr.net> wrote: > > > On Thu, 26 Feb 2015 13:42:57 -0600, Ashley M. Kirchner <ashley at pcraft.com> > wrote: > > And after picking this back up this morning .... still no dice. I have now >> blacklisted the one module that would enumerate the add-in ethernet port >> so >> that is no longer an issue during the kickstart process, however the >> following is now happening: >> >> - kickstart completes successfully using the machine's physical port 2 (or >> eth1) which is on a subnet with DHCP >> - when the system reboots, it brings up port 1 (eth0) with the correct >> static IP information, HOWEVER ... >> - port 2 (eth1) is NOT configured properly. When I look at it's ifcfg-eth1 >> file, its bootproto is set to none when it should be set to dhcp. >> - the add-in card has not been enumerated, in fact the system doesn't even >> know it's there (dmesg has no mention of it and no module loaded) >> >> > Check the installed kernel append line to make sure the rdblacklist option > is not being pulled from the kickstart boot line. If it is you can add > this to the kickstart post install section: > > /usr/bin/perl -p -i -e 's/rdblacklist=MODULENAME//' /boot/grub/grub.conf > > So for port 2 (eth1), the kickstart file has it configured as a dhcp >> interface, so why when the system reboots it comes up with bootproto=none? >> > > As I pointed out the script I sent changes all interfaces to DHCP=none. > > If you are using it and you don't want it to do that then remove this line: > > /usr/bin/perl -p -i -e 's/dhcp/none/' /etc/sysconfig/network- > scripts/ifcfg-${NETDEV}-tmp > > On the other hand, port 1 (eth0) does come up with the static information >> as it should - that info is also set in the kickstart file. >> >> Baffled ... >> >> On Wed, Feb 25, 2015 at 4:46 PM, Ashley M. Kirchner <ashley at pcraft.com> >> wrote: >> >> Yeah, and we're back to someone needing to "do something" on the system >>> after it reboots. :) >>> >>> On Wed, Feb 25, 2015 at 4:37 PM, Jason Warr <jason at warr.net> wrote: >>> >>> On Wed, 25 Feb 2015 17:30:30 -0600, Ashley M. Kirchner < >>>> ashley at pcraft.com> wrote: >>>> >>>> >>>> On Feb 25, 2015 4:19 PM, "Jason Warr" <jason at warr.net> wrote: >>>> >>>> > It will if you try to configure the now non-existent interface. >>>> >>>> That's what I figured, so I can remove it from the kickstart file, no >>>> problem. The question then becomes, if kickstart doesn't configure it, >>>> what >>>> happens when the system reboots after install? It won't know what to do >>>> with that interface, correct? >>>> >>>> Is this a case where I will need to put an ifcfg-eth2 file in place >>>> during post-install? >>>> >>>> Upon reboot the system *should* generate a base one for you as it will >>>> see it as a new interface. Not a big deal if it does not though, just >>>> create one yourself. You will want to add it to the udev rules file >>>> though. You can re-run the script I sent to do that if you want. At >>>> that >>>> point it should be eth2. Or you can edit the existing one by copying a >>>> line and changing the MAC and eth* to whatever you need. >>>> >>>> >>> >>> _______________________________________________ >> CentOS mailing list >> CentOS at centos.org >> http://lists.centos.org/mailman/listinfo/centos >> > >