On Thu, Feb 26, 2015 at 3:42 PM, Tom Brown wrote:
>
> ksdevice=aa;bb:cc:dd:ee:ff in your above example will ensure the device
> with that mac is the kickstart device.
>
>
Yeah, turned out bootif accomplishes the same thing, at least in my
scenario. What happened afterwards though is different.
__
I have a Dell server that has two built-in ethernet devices. When I
kickstart the machine, they are correctly identified as eth0 and eth1
(correctly meaning they correspond to the physical device ports 1 and
2). I
need a third one and want that to come up as eth2. After adding the
hardware, ki
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
wrote:
Nope, it do
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 wrote:
>
>
> On Thu, 2
On Thu, 26 Feb 2015 13:42:57 -0600, Ashley M. Kirchner
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
foll
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 machi
On Wed, 25 Feb 2015 17:30:30 -0600, Ashley M. Kirchner
wrote:
On Feb 25, 2015 4:19 PM, "Jason Warr" 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 kick
On Feb 25, 2015 4:19 PM, "Jason Warr" 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 i
On Wed, 25 Feb 2015 17:11:02 -0600, Ashley M. Kirchner
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
f
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
du
On Wed, 25 Feb 2015 16:45:04 -0600, Ashley M. Kirchner
wrote:
Out of order meaning, it puts the additional ethernet card as eth0, with
the built-in ports as eth1 and eth2 respectively. WITHOUT the additional
card >installed, it puts the built-in ports as eth0 and eth1, which is
what I wa
On Wed, Feb 25, 2015 at 4:45 PM, Ashley M. Kirchner wrote:
> Out of order meaning, it puts the additional ethernet card as eth0, with
> the built-in ports as eth1 and eth2 respectively. WITHOUT the additional
> card installed, it puts the built-in ports as eth0 and eth1, which is what
> I want it
Ashley M. Kirchner wrote:
> Out of order meaning, it puts the additional ethernet card as eth0, with
> the built-in ports as eth1 and eth2 respectively. WITHOUT the additional
> card installed, it puts the built-in ports as eth0 and eth1, which is what
> I want it to do. The additional card should
Out of order meaning, it puts the additional ethernet card as eth0, with
the built-in ports as eth1 and eth2 respectively. WITHOUT the additional
card installed, it puts the built-in ports as eth0 and eth1, which is what
I want it to do. The additional card should be eth2, at least that's what I
wa
Define out of order in this case just so I know for sure what you mean.
What my solution does, or at least does reliably in my case, is make sure
the interfaces are in the same order once installed as the install kernel
saw them. It won't re-order them to be sequential based on bus, mac or
Ok, when I run that, it creates a now "custom" 70-persistent-net.rules, but
the interfaces are still out of order, with the added one listed first, and
the built-ins 2nd and 3rd.
On Wed, Feb 25, 2015 at 2:00 PM, Jason Warr wrote:
> Here is my script for post install if you want to try it.
>
> In
Here is my script for post install if you want to try it.
In order for the shuffling to not occur you do need to create the udev
rules file somehow. I am not sure how mangled this will be in email but
it is worth a try. It should run OK with nothing else. I have a better
version in the w
Thanks for that Jason but it didn't solve the problem. The system is still
coming up with the interfaces shuffled. It seems to *always* want to use
the added ethernet card as eth0.
On Wed, Feb 25, 2015 at 1:37 PM, Jason Warr wrote:
> Starting back in RHEL/Cent 5 I found that the only way to make
Starting back in RHEL/Cent 5 I found that the only way to make sure your
interface enumeration was consistent after install with what you had
during install was to create a udev rules file using the mac addresses as
the key. It is easy to run a short script in postinstall to create it
base
Version 6.6 ...
On Wed, Feb 25, 2015 at 1:17 PM, Jim Perrin wrote:
>
>
> On 02/25/2015 01:56 PM, Ashley M. Kirchner wrote:
> > Ok, so some of this now works, but I'm still having problems. With the
> > bootif option, the system now correctly configures and uses the same
> > interface to get its
On 02/25/2015 01:56 PM, Ashley M. Kirchner wrote:
> Ok, so some of this now works, but I'm still having problems. With the
> bootif option, the system now correctly configures and uses the same
> interface to get its kickstart file. However, when the system is done and
> boots up, the interfaces
Ok, so some of this now works, but I'm still having problems. With the
bootif option, the system now correctly configures and uses the same
interface to get its kickstart file. However, when the system is done and
boots up, the interfaces are still messed up. So this is what I have in the
kickstart
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23/02/15 08:16 PM, Steven Tardy wrote:
>
>> On Feb 23, 2015, at 6:34 PM, Ashley M. Kirchner
>> wrote:
>>
>> I have a Dell server that has two built-in ethernet devices. When
>> I kickstart the machine, they are correctly identified as eth0
>> and
> On Feb 23, 2015, at 6:34 PM, Ashley M. Kirchner wrote:
>
> I have a Dell server that has two built-in ethernet devices. When I
> kickstart the machine, they are correctly identified as eth0 and eth1
> (correctly meaning they correspond to the physical device ports 1 and 2). I
> need a third on
6.6-x86_64 ...
Keep in mind this is happening during the kickstart process. What I'm
seeing is this:
When the system first comes on, PXE kicks in and port 2 (or eth1) gets an
IP from the network's dhcp and is configured properly. PXE grabs the
necessary files to start installation. However, as so
On 02/23/2015 05:34 PM, Ashley M. Kirchner wrote:
I have a Dell server that has two built-in ethernet devices. When I
kickstart the machine, they are correctly identified as eth0 and eth1
(correctly meaning they correspond to the physical device ports 1 and 2). I
need a third one and want that to
Correction to my own post: I know it's not kickstart that's doing the
renaming, it's the kernel that's booting up the system.
On Feb 23, 2015 4:34 PM, "Ashley M. Kirchner" wrote:
> I have a Dell server that has two built-in ethernet devices. When I
> kickstart the machine, they are correctly iden
I have a Dell server that has two built-in ethernet devices. When I
kickstart the machine, they are correctly identified as eth0 and eth1
(correctly meaning they correspond to the physical device ports 1 and 2). I
need a third one and want that to come up as eth2. After adding the
hardware, kicksta
28 matches
Mail list logo
