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
