another identical machine will have the same bus ids. that's why this works.
Kahlil (Kal) Hodgson GPG: C9A02289
Head of Technology (m) +61 (0) 4 2573 0382
DealMax Pty Ltd GitHub: @tartansandal
Suite 1416
401 Docklands Drive
Docklands VIC 3008 Australia
"All parts should go together without forcing. You must remember that
the parts you are reassembling were disassembled by you. Therefore,
if you can't get them together again, there must be a reason. By all
means, do not use a hammer." -- IBM maintenance manual, 1925
On 15 May 2015 at 11:02, Ashley M. Kirchner <ashley at pcraft.com> wrote:
> 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 dealmax.com.au> wrote:
>
> > So a 70-persistent-net.rules like
> >
> > # onboard port 1 -> eth0
> > ACTION=="add", SUBSYSTEM=="net",
BUS=="pci", ID=="0000:00:19.0",
> > NAME="eth0"
> >
> > # PCIe card -> eth2
> > ACTION=="add", SUBSYSTEM=="net",
BUS=="pci", ID=="0000:03:00.0",
> > NAME="eth2"
> >
> > # onboard port 2 -> eth1
> > ACTION=="add", SUBSYSTEM=="net",
BUS=="pci", ID=="0000:08:00.0",
> > NAME="eth1"
> >
> > will do what you want.
> >
> > Note: I've just changed the ID and NAME values to match what you
have and
> > what you want.
> >
> >
> >
> > Kahlil (Kal) Hodgson GPG: C9A02289
> > Head of Technology (m) +61 (0) 4 2573 0382
> > DealMax Pty Ltd GitHub: @tartansandal
> >
> > Suite 1416
> > 401 Docklands Drive
> > Docklands VIC 3008 Australia
> >
> > "All parts should go together without forcing. You must remember
that
> > the parts you are reassembling were disassembled by you. Therefore,
> > if you can't get them together again, there must be a reason. By
all
> > means, do not use a hammer." -- IBM maintenance manual, 1925
> >
> > On 15 May 2015 at 10:12, Ashley M. Kirchner <ashley at
pcraft.com> wrote:
> >
> > > 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 Corporation 82566DM-2 Gigabit
> Network
> > > Connection (rev 02)
> > > 03:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit
Ethernet
> > > Controller (Copper) (rev 06)
> > > 08:00.0 Ethernet controller: Intel Corporation 82573V Gigabit
Ethernet
> > > Controller (Copper) (rev 03)
> > >
> > > Now when I look at the enumeration from dmesg, I get this:
> > > e1000e 0000:00:19.0: eth0: (PCI Express:2.5GT/s:Width x1)
> > > 00:1e:68:58:00:4c <-- this is Port1
> > > e1000e 0000:03:00.0: eth1: (PCI Express:2.5GT/s:Width x1)
> > > 00:15:17:d3:43:62 <-- PCIe Card
> > > e1000e 0000:08:00.0: eth2: (PCI Express:2.5GT/s:Width x1)
> > > 00:1e:68:58:00:4d <-- this is Port2
> > >
> > > So this is how it gets enumerated for some reason. But during the
> > machine's
> > > POST, it always brings up the PXE boot order as Port1, Port2, and
> finally
> > > the PCIe card, which is the correct order that I want it in. It
also
> only
> > > has one single expansion slot so it's not like I can try a
different
> one
> > to
> > > see if it makes a difference, unfortunately.
> > >
> > >
> > > On Thu, May 14, 2015 at 5:47 PM, Kahlil Hodgson <
> > > kahlil.hodgson at dealmax.com.au> wrote:
> > >
> > > > On 15 May 2015 at 03:51, Ashley M. Kirchner <ashley at
pcraft.com>
> wrote:
> > > >
> > > > > After the machine boots and I look in
/root/ksnet-devices, I see
> the
> > > MAC
> > > > > addresses for the devices as:
> > > > > Port1 -> eth0
> > > > > PCIe Card-> eth1
> > > > > Port2 -> eth2
> > > > >
> > > > > And yet, during the machine's POST (which can
verify by the PXE
> boot
> > > up
> > > > of
> > > > > each device), it correctly enumerates the ethernet
devices as:
> > > > > Port1
> > > > > Port2
> > > > > PCIe card
> > > > >
> > > > > So where and why is the order changed when the kernel
kicks in and
> > > start
> > > > > booting the machine? And how can I stop it, or change
its behavior?
> > I'm
> > > > not
> > > > > seeing any 'renaming' going on in dmesg like I
sometimes find. So
> > > > something
> > > > > is causing this and I can't figure it out.
> > > > >
> > > >
> > > > ?Yeah, my understanding is that the kernel does not really
trust all
> > the
> > > > information that the BIOS tells it and probes for the
network devices
> > > > itself.?
> > > >
> > > > I'm thinking, since you are using kickstart and PXE
boot, you're not
> > > going
> > > > to know the HWADDR for your NICs before hand, but you
probably do
> have
> > a
> > > > predictable pci bus layout.
> > > >
> > > > So grab pciutils package and run:
> > > >
> > > > lspci | grep Ethernet
> > > >
> > > > I get something like
> > > >
> > > > 00:0a.0 Ethernet controller: NVIDIA Corporation MCP67
Ethernet (rev
> a2)
> > > > 01:06.0 Ethernet controller: Intel Corporation 82541PI
Gigabit
> Ethernet
> > > > Controller (rev 05)
> > > > 01:07.0 Ethernet controller: Intel Corporation 82541PI
Gigabit
> Ethernet
> > > > Controller (rev 05)
> > > >
> > > > The first number is the bus id which is going to be
consistent across
> > > > machines with the same mainboard and nic layout.
> > > >
> > > > So I can make a persistent-net.rules file like:
> > > >
> > > > ACTION=="add", SUBSYSTEM=="net",
BUS=="pci", ID=="0000:00:0a.0",
> > > > NAME="eth0"
> > > > ACTION=="add", SUBSYSTEM=="net",
BUS=="pci", ID=="0000:01:06.0",
> > > > NAME="eth1"
> > > > ACTION=="add", SUBSYSTEM=="net",
BUS=="pci", ID=="0000:01:07.0",
> > > > NAME="eth2"
> > > >
> > > >
> > > > Hope this helps.
> > > >
> > > > K
> > > > _______________________________________________
> > > > CentOS mailing list
> > > > CentOS at centos.org
> > > > http://lists.centos.org/mailman/listinfo/centos
> > > >
> > > >
> > > _______________________________________________
> > > CentOS mailing list
> > > CentOS at centos.org
> > > http://lists.centos.org/mailman/listinfo/centos
> > >
> > _______________________________________________
> > CentOS mailing list
> > CentOS at centos.org
> > http://lists.centos.org/mailman/listinfo/centos
> >
> >
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
>