Re: Back to eth shuffling ...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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@xxxxxxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxx> wrote:
> >
> > > On 15 May 2015 at 03:51, Ashley M. Kirchner <ashley@xxxxxxxxxx> 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@xxxxxxxxxx
> > > http://lists.centos.org/mailman/listinfo/centos
> > >
> > >
> > _______________________________________________
> > CentOS mailing list
> > CentOS@xxxxxxxxxx
> > http://lists.centos.org/mailman/listinfo/centos
> >
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
>
>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos





[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux