What about a blacklist line somewhere in /etc/modprobe.d ?
I have never noticed anaconda adding one there but it is worth checking.
Also, when you check dmesg, are you looking for the expected module name
or eth2?
On Thu, 26 Feb 2015 14:46:08 -0600, Ashley M. Kirchner <ashley@xxxxxxxxxx>
wrote:
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@xxxxxxxx> wrote:
On Thu, 26 Feb 2015 13:42:57 -0600, Ashley M. Kirchner
<ashley@xxxxxxxxxx> 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@xxxxxxxxxx>
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@xxxxxxxx> wrote:
On Wed, 25 Feb 2015 17:30:30 -0600, Ashley M. Kirchner <
ashley@xxxxxxxxxx> wrote:
On Feb 25, 2015 4:19 PM, "Jason Warr" <jason@xxxxxxxx> 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@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
