On Wed, 25 Feb 2015 17:11:02 -0600, Ashley M. Kirchner <ashley at pcraft.com> wrote:> Add "rdblacklist=MODULE_NAME" to your append line in pxelinux.conf file. >> > > Trying that next. It'll have to wait till tomorrow as we're under a > serious > blizzard/snow event right now and I'd like to get home before all of hell > freezes over. However, question, if I blacklist the module, that means > during kickstart it doesn't know it's there either, which would cause a > 'network' definition for that interface to fail (and kickstart to stop) > ... > I think.It will if you try to configure the now non-existent interface.> > This should get you into a usable state post-install so you can setup >> additional interfaces. >> > > My hope is that I don't have to do anything after it's done and reboots. > The whole purpose of me doing this is in case something happens with the > drive and I'm not here, someone can shove a new one in, reboot and let it > go through the kickstart and be operational ten minutes later without > them > having done anything else. Maybe I'm aiming too damn high.No, your not. One thing you might be doing though is being to concerned about ordering. The actual numbering of interfaces is, in most cases, purely cosmetic. So if you do not have another reason for needing a nice, logical ordering you should ignore it. Your use case is almost exactly why I went the route I did in the first place. Since this appears to be a recovery plan for a specific system then your best course is to accept the ordering as kickstart sees it and adjust your network config lines to compensate. As long as you have a udev rules file the ordering will not change on reboot.> _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos
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?
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.
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) 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? 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. >> > >
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