similar to: Kickstart with multiple eth devices

-----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 >> <ashley at pcraft.com> 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

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 driver. I am working on that but it will also include naming the devices based on the module

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 based on how anaconda has seen them. In order for this to work on Cent 6 you have to set biosdevname=0

<overly trimmed> 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 are still messed up. So this is what I have in the >

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 works but the enhancements are mainly useful for Fedora 19-21. I did forget to say I also block

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.

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

On Wed, 25 Feb 2015 16:45:04 -0600, Ashley M. Kirchner <ashley at pcraft.com> 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 be eth2, at

Actually, I know what the MAC is for the builtin Port1 and 2. Those are listed in the BIOS. But ultimately I don't want to rely on them as I want the same kickstart file to work for other machines, so hardcoding those in the kickstart file wouldn't quite work, unless I start writing multiple kickstart files, one per machine. Anyway, lspci reports this: 00:19.0 Ethernet controller: Intel

Right, I understand that part. However I believe I'm now in the realm of making this specific to this machine as I have no guarantee that another identical machine will pop up with those same bus IDs. Maybe for the internal ports, but I don't know if the same will happen for the PCIe bus. Would that be correct? On Thu, May 14, 2015 at 6:21 PM, Kahlil Hodgson < kahlil.hodgson at

When I was working on this last time (with the r8169 driver), someone on this list provided the following script which is what "fixed" the issue at the time by creating a new 70-persistent-net.rules file with the devices enumerated in order. However, this no longer works now. echo "[KICKSTART] Binding eth interfaces to the expected MAC address in UDEV" echo "## Created by

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 want it to do. Looking at persistent-net.rules, it always puts the additional card first, both

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 file: # On-Board Port 1 with public IP configuration network --noipv6 --onboot yes --bootproto

> On Feb 23, 2015, at 6:34 PM, Ashley M. Kirchner <ashley at pcraft.com> 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 come up as eth2. After adding the

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 <jason at warr.net> wrote: > Starting back in RHEL/Cent 5 I found that the only way to make sure your > interface enumeration was consistent after install

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 <jason at warr.net> wrote: > 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

On Tue, Jan 20, 2015 at 11:13 AM, Ashley M. Kirchner <ashley at pcraft.com> wrote: > Tom: Thanks for the suggestion. I'll look into those tools. > > Mark: Yes, they are using pxeboot. Right now when they boot up, the pxe > config offers two options, 32- and 64bit. Are you suggesting I create > multiple entries that one selects based on what the machine is going to be? >

On Tue, Jan 20, 2015 at 10:41 AM, Tom Grace <lists-in at deathbycomputers.co.uk> wrote: > On 20/01/2015 16:29, Ashley M. Kirchner wrote: >> >> So my question is, is there some way do determine via kickstart, what to >> install on that machine based on some criteria, possibly the IP that's >> being assigned to it, or MAC address, or something ... > > If

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

Hi, In a corporate environment we are not allowed to use DHCP/PXE for doing network installations. This means we have to look for other solutions. Our solution is to use an ISO image (mounted via a KVM solution) to kick off the network installation. A big problem currently is that the order of the network interfaces is arbitrary (depends on the order of the drivers loaded) and is not