[CentOS] Kickstart ksdevice question

[James A. Peltier]

----- On 3 Nov, 2017, at 09:13, Paul Heinlein heinlein at madboa.com 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 at madboa.com
| 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