Project

General

Profile

Actions

Feature #255

closed

Check all x-rhn-provisioning headers

Added by Frank Sweetser almost 14 years ago. Updated almost 14 years ago.

Status:
Closed
Priority:
Normal
Category:
Unattended installations
Target version:
Difficulty:
Triaged:
Fixed in Releases:
Found in Releases:

Description

Currently, get_host_details in unattended_controller.rb only checks the MAC address from the provisioning header for eth0. This obviously breaks if, for some reason, you end up installing off of eth2 or some other device. I've attached a simple patch which tries to search for the IP address, and any of the MAC addresses on the client.


Files

Actions #1

Updated by Ohad Levy almost 14 years ago

  • Status changed from New to Feedback
  • Assignee changed from Ohad Levy to Frank Sweetser

I'm wondering if we need to change the kickstart template too, e.g. we have this in the template:

network --device eth0 --bootproto dhcp

maybe we should store the interface name and change this accordingly?

imho its a best practice to boot your servers from eth0, but that's another store :)

Do you want to post the diff as a git patch (so we'll know who to blame later on :))

Actions #2

Updated by Frank Sweetser almost 14 years ago

Ohad Levy wrote:

I'm wondering if we need to change the kickstart template too, e.g. we have this in the template:

[...]

maybe we should store the interface name and change this accordingly?

Playing around with it a bit, I found that at least with a DHCP config, you can just leave out the device argument and anaconda will just Do The Right Thing:

network --bootproto dhcp

However, I did have to modify my syslinux config file to get kickstart. Basically, the ipappend and ksdevice options here tell kickstart to use the same device that the machine PXE booted off of, regardless of interface name:

default linux
label linux
  ipappend 2
  kernel pxelinux.cfg/c5-x86_64-vmlinuz
  append initrd=pxelinux.cfg/c5-x86_64-initrd.img text ip=dhcp lang=en_US keymap=us ks=http://foreman/unattended/kickstart ksdevice=bootif

imho its a best practice to boot your servers from eth0, but that's another store :)

I agree - unfortunately I have some new servers that disagree, and insist on enumerating the add-in 10G NICs before the on-board 1G NICs :P

Do you want to post the diff as a git patch (so we'll know who to blame later on :))

Sure, why not? =)

Actions #3

Updated by Ohad Levy almost 14 years ago

  • Target version set to 0.1-5

Frank Sweetser wrote:

Ohad Levy wrote:

I'm wondering if we need to change the kickstart template too, e.g. we have this in the template:

[...]

maybe we should store the interface name and change this accordingly?

Playing around with it a bit, I found that at least with a DHCP config, you can just leave out the device argument and anaconda will just Do The Right Thing:

is that only on RHE5? I'm unsure about older versions of RH.

[...]

However, I did have to modify my syslinux config file to get kickstart. Basically, the ipappend and ksdevice options here tell kickstart to use the same device that the machine PXE booted off of, regardless of interface name:

dont we need to specifiy the ksdevice (to match to the booted interface)?
Its already planned to generate the actual pxelinux config file rather then to link, so we could actually use the same value (maybe set it up in the gui upfront).

[...]

imho its a best practice to boot your servers from eth0, but that's another store :)

I agree - unfortunately I have some new servers that disagree, and insist on enumerating the add-in 10G NICs before the on-board 1G NICs :P

cant you just disable the interfaces in bios? this usually solves the problem (unless you need it later on)

Actions #4

Updated by Frank Sweetser almost 14 years ago

Ohad Levy wrote:

is that only on RHE5? I'm unsure about older versions of RH.

I don't have any systems to test on, but the relevant documentation reads identically for RHEL 3, 4, and 5, so it should be okay.

dont we need to specifiy the ksdevice (to match to the booted interface)?

We are this way =)

By adding the 'ipappend 2' option to the syslinux config file, we're telling syslinux to add a new kernel boot parameter 'bootif=<MAC>' where MAC is the MAC address of the interface that PXE boot ran on. The 'ksdevice=bootif' option then tells anaconda to use the bootif parameter to track down the correct device by MAC address rather than looking for a fixed name.

Its already planned to generate the actual pxelinux config file rather then to link, so we could actually use the same value (maybe set it up in the gui upfront).

That sounds like a perfect idea - you could then specify a static ethX, bootif, or link parameter to ksdevice as needed.

cant you just disable the interfaces in bios? this usually solves the problem (unless you need it later on)

Not in this case, no. I can disable the on-board interfaces in BIOS, but the problematic ones are on a PCI add-in card that the BIOS can't do anything with, so I'd have to physically remove the card.

Actions #5

Updated by Ohad Levy almost 14 years ago

Frank Sweetser wrote:

By adding the 'ipappend 2' option to the syslinux config file, we're telling syslinux to add a new kernel boot parameter 'bootif=<MAC>' where MAC is the MAC address of the interface that PXE boot ran on. The 'ksdevice=bootif' option then tells anaconda to use the bootif parameter to track down the correct device by MAC address rather than looking for a fixed name.

If my memory serve me right, this never worked on RHE3/4 , I guess some testings are in order :)

Its already planned to generate the actual pxelinux config file rather then to link, so we could actually use the same value (maybe set it up in the gui upfront).

That sounds like a perfect idea - you could then specify a static ethX, bootif, or link parameter to ksdevice as needed.

yep, maybe it make sense to add it in to the ticket directly #24

Actions #6

Updated by Frank Sweetser almost 14 years ago

  • Status changed from Feedback to Ready For Testing
  • % Done changed from 0 to 100
Actions #7

Updated by Ohad Levy almost 14 years ago

  • Status changed from Ready For Testing to Closed
Actions

Also available in: Atom PDF