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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
