This should be easy to answer (I hope). We routinely kickstart boxes to use for managing our customers RADIUS/DHCP configurations (along with other things). We've had a C7 kickstart in place since I built one in May and are finally starting to roll it out for new installations. But, I'm curious as to what ksdevice= actually does.
With the C6 we routinely used ksdevice=eth0 since we ship boxes with two NICs and knew interface 1 was always eth0. With C7 comes the interface naming convention changes and that's where questions have arisen about that option. It's been set as ksdevice=eno1 since I know these servers name the interfaces with the eno# convention (integrated dual-port). A coworker of mine insists on setting it ksdevice=enp2s0 which doesn't seem to work like it should (though, it could be a fault netinstall image, I'm not sure yet). In all honesty, we'd prefer to keep the eth# convention for C7 like C6.
So, my question is, does setting ksdevice=eth0 dictate to the system the names of the interfaces? Is that just a name for the install process and the kickstart script assigns names? (We have the kickstart script setting them as eno1 and eno2, btw.)
I've googled this to no end and haven't found a satisfactory answer. So, I'm hoping someone with more KS experience than I can explain it.
Hello,
ksdevice specifies which NIC to be used during the network install.
The new naming conventions indeed make this more complicated than it needs to be. To go back to the old naming scheme (eth0, eth1 ...) just add this to boot parameters (kernel cmdline): biosdevname=0 net.ifnames=0
HTH Lucian
-- Sent from the Delta quadrant using Borg technology!
Nux! www.nux.ro
----- Original Message -----
From: "Mark Haney" mark.haney@neonova.net To: "CentOS mailing list" centos@centos.org Sent: Wednesday, 1 November, 2017 12:45:45 Subject: [CentOS] Kickstart ksdevice question
This should be easy to answer (I hope). We routinely kickstart boxes to use for managing our customers RADIUS/DHCP configurations (along with other things). We've had a C7 kickstart in place since I built one in May and are finally starting to roll it out for new installations. But, I'm curious as to what ksdevice= actually does.
With the C6 we routinely used ksdevice=eth0 since we ship boxes with two NICs and knew interface 1 was always eth0. With C7 comes the interface naming convention changes and that's where questions have arisen about that option. It's been set as ksdevice=eno1 since I know these servers name the interfaces with the eno# convention (integrated dual-port). A coworker of mine insists on setting it ksdevice=enp2s0 which doesn't seem to work like it should (though, it could be a fault netinstall image, I'm not sure yet). In all honesty, we'd prefer to keep the eth# convention for C7 like C6.
So, my question is, does setting ksdevice=eth0 dictate to the system the names of the interfaces? Is that just a name for the install process and the kickstart script assigns names? (We have the kickstart script setting them as eno1 and eno2, btw.)
I've googled this to no end and haven't found a satisfactory answer. So, I'm hoping someone with more KS experience than I can explain it.
-- Mark Haney Network Engineer at NeoNova 919-460-3330 option 1 mark.haney@neonova.net www.neonova.net
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Nux! wrote:
Hello,
ksdevice specifies which NIC to be used during the network install.
The new naming conventions indeed make this more complicated than it needs to be. To go back to the old naming scheme (eth0, eth1 ...) just add this to boot parameters (kernel cmdline): biosdevname=0 net.ifnames=0
Yes! Actually, the other admin I work with and I were just bitching about that a few minutes ago. I have no idea who thought the new enpxsyz was a "good idea", but for 99% of us, I look at the back of a system, and I want to know which one. the enxyz is significantly less than useful.
Now, if only there were some tool, like there used to be HERD, to figure out on my supermicro which DIMM is complaining.... You'd think IMPI would do it, but nooooo....
mark
HTH Lucian
-- Sent from the Delta quadrant using Borg technology!
Nux! www.nux.ro
----- Original Message -----
From: "Mark Haney" mark.haney@neonova.net To: "CentOS mailing list" centos@centos.org Sent: Wednesday, 1 November, 2017 12:45:45 Subject: [CentOS] Kickstart ksdevice question
This should be easy to answer (I hope). We routinely kickstart boxes to use for managing our customers RADIUS/DHCP configurations (along with other things). We've had a C7 kickstart in place since I built one in May and are finally starting to roll it out for new installations. But, I'm curious as to what ksdevice= actually does.
With the C6 we routinely used ksdevice=eth0 since we ship boxes with two NICs and knew interface 1 was always eth0. With C7 comes the interface naming convention changes and that's where questions have arisen about that option. It's been set as ksdevice=eno1 since I know these servers name the interfaces with the eno# convention (integrated dual-port). A coworker of mine insists on setting it ksdevice=enp2s0 which doesn't seem to work like it should (though, it could be a fault netinstall image, I'm not sure yet). In all honesty, we'd prefer to keep the eth# convention for C7 like C6.
So, my question is, does setting ksdevice=eth0 dictate to the system the names of the interfaces? Is that just a name for the install process and the kickstart script assigns names? (We have the kickstart script setting them as eno1 and eno2, btw.)
I've googled this to no end and haven't found a satisfactory answer. So, I'm hoping someone with more KS experience than I can explain it.
-- Mark Haney Network Engineer at NeoNova 919-460-3330 option 1 mark.haney@neonova.net www.neonova.net
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 11/01/2017 10:28 AM, m.roth@5-cent.us wrote:
Nux! wrote:
Hello,
ksdevice specifies which NIC to be used during the network install.
The new naming conventions indeed make this more complicated than it needs to be. To go back to the old naming scheme (eth0, eth1 ...) just add this to boot parameters (kernel cmdline): biosdevname=0 net.ifnames=0
Yes! Actually, the other admin I work with and I were just bitching about that a few minutes ago. I have no idea who thought the new enpxsyz was a "good idea", but for 99% of us, I look at the back of a system, and I want to know which one. the enxyz is significantly less than useful.
Now, if only there were some tool, like there used to be HERD, to figure out on my supermicro which DIMM is complaining.... You'd think IMPI would do it, but nooooo....
mark
It's funny you should mention that vendor because we use only SuperMicro servers here. The really good thing about that is that our boxes, the interfaces are eno1 & eno2 and not the ridiculous enp2s0abcdefhwtf convention on VMs and such. It was easy to remember, even if counter-intuitive since if you're like most people who've been in this business long enough, interfaces (and arrays) always start with 0. To me, eno1 is the second interface and I have to actually pause to rethink things because of that.
Once upon a time, Mark Haney mark.haney@neonova.net said:
This should be easy to answer (I hope). We routinely kickstart boxes to use for managing our customers RADIUS/DHCP configurations (along with other things). We've had a C7 kickstart in place since I built one in May and are finally starting to roll it out for new installations. But, I'm curious as to what ksdevice= actually does.
It just sets the NIC that the installer tries to bring up to fetch a kickstart file from the network (and then the rest of a network install, if you don't override it in the kickstart).
If you are PXE booting using pxelinux, add "ipappend 2" to your pxelinux.cfg stanza and "ksdevice=bootif" to the append line. With that, pxelinux will add the MAC address of the PXE NIC to the kernel command line, and the installer will pick that up and use the matching interface for the rest of the kickstart.
On Wed, 2017-11-01 at 08:45 -0400, Mark Haney wrote:
This should be easy to answer (I hope). We routinely kickstart boxes to use for managing our customers RADIUS/DHCP configurations (along with other things). We've had a C7 kickstart in place since I built one in May and are finally starting to roll it out for new installations. But, I'm curious as to what ksdevice= actually does.
Strictly speaking it is depricated https://anaconda-installer.readthedocs.io/en/latest/boot-options.html#d eprecated-options
Regards,
Tris
************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmaster@bgfl.org
The views expressed within this email are those of the individual, and not necessarily those of the organisation *************************************************************
Once upon a time, Tristan Hoar TrisHoar@bgfl.org said:
Strictly speaking it is depricated https://anaconda-installer.readthedocs.io/en/latest/boot-options.html#d eprecated-options
Yeah, looking at my kickstart setup, I don't actually specify it anymore because it is automatic. The important thing is adding the "ipappend 2" to the pxelinux stanza.
On 11/01/2017 01:57 PM, Tristan Hoar wrote:
Strictly speaking it is depricated https://anaconda-installer.readthedocs.io/en/latest/boot-options.html#d eprecated-options
Regards,
Tris
Okay, so it looks like I can simply change ksdevice=eth0 to bootdev=eth0, correct?
Once upon a time, Mark Haney mark.haney@neonova.net said:
Okay, so it looks like I can simply change ksdevice=eth0 to bootdev=eth0, correct?
I believe you can just leave both off (IIRC for CentOS 6 as well) if you add "ipappend 2" to the pxelinux stanza.
On 11/01/2017 03:25 PM, Chris Adams wrote:
Once upon a time, Mark Haney mark.haney@neonova.net said:
Okay, so it looks like I can simply change ksdevice=eth0 to bootdev=eth0, correct?
I believe you can just leave both off (IIRC for CentOS 6 as well) if you add "ipappend 2" to the pxelinux stanza.
I probably should have clarified that we're not using PXE and probably won't for the forseeable future. This is just a simple netinstall disc/flash drive boot.
Once upon a time, Mark Haney mark.haney@neonova.net said:
On 11/01/2017 03:25 PM, Chris Adams wrote:
Once upon a time, Mark Haney mark.haney@neonova.net said:
Okay, so it looks like I can simply change ksdevice=eth0 to bootdev=eth0, correct?
I believe you can just leave both off (IIRC for CentOS 6 as well) if you add "ipappend 2" to the pxelinux stanza.
I probably should have clarified that we're not using PXE and probably won't for the forseeable future. This is just a simple netinstall disc/flash drive boot.
Oh, okay. IIRC at one point there was an option to pick an interface with link (ksdevice=link or some such), but I don't know if that made it to the re-designed anaconda...
<wanders off to look at anaconda source>
Yep, still there, but it is also not needed (and actually ignored). By default, the first NIC with a link will be used. This is for some value of "first" of course, although I do find that the new naming does tend to match the order of the hardware more often than eth0/eth1/...
----- On 1 Nov, 2017, at 13:07, Chris Adams linux@cmadams.net wrote:
| Once upon a time, Mark Haney mark.haney@neonova.net said: |> On 11/01/2017 03:25 PM, Chris Adams wrote: |> >Once upon a time, Mark Haney mark.haney@neonova.net said: |> >>Okay, so it looks like I can simply change ksdevice=eth0 to |> >>bootdev=eth0, correct? |> >I believe you can just leave both off (IIRC for CentOS 6 as well) if you |> >add "ipappend 2" to the pxelinux stanza. |> > |> I probably should have clarified that we're not using PXE and |> probably won't for the forseeable future. This is just a simple |> netinstall disc/flash drive boot. | | Oh, okay. IIRC at one point there was an option to pick an interface | with link (ksdevice=link or some such), but I don't know if that made it | to the re-designed anaconda... | | <wanders off to look at anaconda source> | | Yep, still there, but it is also not needed (and actually ignored). By | default, the first NIC with a link will be used. This is for some value | of "first" of course, although I do find that the new naming does tend | to match the order of the hardware more often than eth0/eth1/... | | -- | Chris Adams linux@cmadams.net | _______________________________________________ | CentOS mailing list | CentOS@centos.org | https://lists.centos.org/mailman/listinfo/centos
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
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.
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.
----- On 3 Nov, 2017, at 09:13, Paul Heinlein heinlein@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@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.
-
Chris Adams -
James A. Peltier -
m.roth＠5-cent.us -
Mark Haney -
Nux! -
Paul Heinlein -
Tristan Hoar