----- On 3 Nov, 2017, at 09:13, Paul Heinlein heinlein@xxxxxxxxxx wrote:
| On Fri, 3 Nov 2017, Mark Haney wrote:
|
|> On 11/01/2017 05:02 PM, James A. Peltier wrote:
|>> Leaving ksdevice= off the command line will prompt you for the location of
|>> the kickstart file and the device you want to use to kickstart
|>>
|> Well, things just got weird with this. The first couple of times I included
|> the biosdevname etc, on the command line with ksdevice=eth0 it worked
|> perfectly. Sometime yesterday (and I verified this a few minutes ago) that
|> stopped working. It's the same hardware (in fact, the exact same hardware as
|> I tested earlier, as it's the same box) and now, it's naming the interfaces
|> eno1/eno2 again.
|>
|> Honestly, not that I care, since taking the ksdevice= bit off worked just
|> fine, even with the interface names changed to eth0/eth1 in the kickstart
|> file. I have no idea why this happened, and finding an answer isn't critical
|> to getting these boxes kicked, though I would like to understand why the
|> BIOSDEVNAME NET.IFRAMES options stopped working suddenly. It's the same boot
|> image, and the exact same server that renamed the interfaces correctly
|> yesterday. Granted, it's Friday and maybe anaconda is tired of my crap and
|> has decided to throw a tantrum.
|
| I haven't been following this thread all that closely, so I'm unsure
| what system and firmware you have -- but we recently encountered a
| BIOS bug that has disrupted some local kickstarts.
|
| The short version is that our Intel SMBIOS reports duplicate names for
| onboard ethernet devices, which in our case are I350 1G cards:
|
| [root ~]# biosdevname -d | grep 'BIOS device'
| BIOS device: em1
| BIOS device: em1
| BIOS device: p785p1
|
| Ideally, the second device would be em2. Since they report the same,
| systemd gets inconsistently confused and the devices' "Kernel name"
| entries bounce between enoX and ethX.
|
| Worse, if I log in via the console, disable the interfaces, use
| modprobe to remove the igb modules, and the re-load it -- the
| interfaces may end up with different designations than they had at
| boot time.
|
| Intel has released a BIOS update that supposedly fixes the problem,
| but I haven't been able yet to travel to the data center to apply and
| test the patch. (No RMM modules in this rack, so I can't attach
| virtual boot media. Sigh.)
|
| Anyway, that may not be your problem, but it might be worth looking
| into.
|
| --
| Paul Heinlein
| heinlein@xxxxxxxxxx
| 45°38' N, 122°6' W
The system BIOS was going to be where I pointed my finger. It's happened to me many times before. Try upgrading to the latest BIOS and see if the issue goes away.
--
James A. Peltier
Manager - Research Computing Group | IT Services
Simon Fraser University | ASB10973
8888 University Dr., Burnaby, B.C. V5A 1S6
T: 778.782.6573 | M: 604.365.6432 | sfu.ca/itservices
Twitter: @sfu_it
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
