Bug 826657 - kssendmac option does not work unless DHCP is used
kssendmac option does not work unless DHCP is used
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
23
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Will Woods
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-30 13:26 EDT by Bill Pemberton
Modified: 2016-12-20 07:13 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-20 07:13:47 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
rd.debug /run/initramfs/init.log (grabbed at the package dependency check) (217.71 KB, text/x-log)
2012-07-31 14:42 EDT, Nathanael Noblet
no flags Details

  None (edit)
Description Bill Pemberton 2012-05-30 13:26:49 EDT
Description of problem:
Using kssendmac at install boot does not result in the TTP_X_RHN_PROVISIONING_MAC_* headers being sent to the kickstart server

Version-Release number of selected component (if applicable):
Fedora 17 netinst iso

How reproducible:
every time

Steps to Reproduce:
1. boot a netsinstall image, change the boot params to include ks=http://<yourserver> kssendmac
2. check the headers sent to the kickstart server

  
Actual results:
No HTTP_X_RHN_PROVISIONING_MAC_0 headers will be present

Expected results:
HTTP_X_RHN_PROVISIONING_MAC_0 header of the form 'device macaddress'.  Additionally there should be a HTTP_X_RHN_PROVISIONING_MAC_X header for each network interface on the system.

Additional info:
I saw in the dracut sources that kssendmac is being replaced by inst.ks.sendmac, so I tried setting that.  Both using inst.ks.sendmac by itself and inst.ks.sendmac=1 -- neither resulted in the headers being sent.
Comment 1 Nathanael Noblet 2012-07-31 13:31:30 EDT
Was this supposed to be fixed by https://listman.redhat.com/archives/anaconda-devel-list/2012-April/msg00050.html ?

I'm being bitten by the same bug. That fix is April 2012 and this bug was reported May... How do I know if this has been fixed in a newer dracut than F17 has?
Comment 2 Nathanael Noblet 2012-07-31 13:40:18 EDT
looks like this is most likely anaconda in the end
Comment 3 Nathanael Noblet 2012-07-31 14:42:13 EDT
Created attachment 601564 [details]
rd.debug /run/initramfs/init.log (grabbed at the package dependency check)
Comment 4 Nathanael Noblet 2012-07-31 14:58:23 EDT
One more tidbit. I've specified both kssendmac and kssendsn. I don't get the mac address, however I do receive a HTTP_X_SYSTEM_SERIAL_NUMBER in request.
Comment 5 Chris Lumens 2012-08-20 11:51:29 EDT
This should be fixed by 35a93ddd452d11aaacee16e1e8ece301ff310c0a on master.
Comment 6 Adam Williamson 2013-05-09 21:38:18 EDT
Bill, Nathanael, can either of you confirm that this is fixed in F18/F19? Thanks.
Comment 7 Bill Pemberton 2013-05-10 08:46:47 EDT
F18 and F19 still don't send the  HTTP_X_RHN_PROVISIONING_MAC_* headers with kssendmac.
Comment 8 Adam Williamson 2013-05-10 12:15:40 EDT
Thanks. Bumping to f19 and setting back to ASSIGNED.
Comment 9 Adam Williamson 2013-05-11 21:30:01 EDT
Can you test this instead?

inst.ks.sendmac

Seems like the command got renamed during the noloader change. Note that there's a general move to prefix inst. to all Anaconda parameters as well, but the 'naked' versions will work for a while, so 'ks.sendmac' should work at present; but 'inst.ks.sendmac' is more future proof.

This also applies to 'ksdevice' and 'kssendsn' - they have been renamed to 'inst.ks.device' and 'inst.ks.sendsn'. If you checked your logs you would have seen a small warning about this renaming, I think, but it's easy to miss!

We unfortunately have three (or possibly four) different sets of Anaconda boot options documentation, none of which is quite perfect. I'm endeavouring to improve this at present.
Comment 10 Bill Pemberton 2013-05-13 09:15:24 EDT
Using inst.ks.sendmac doesn't change anything on F18 or F19, there's still no extra headers sent to the server.
Comment 11 Adam Williamson 2013-05-13 11:06:24 EDT
Aw, and there I thought I'd figured it out.
Comment 12 Nathanael Noblet 2013-07-17 13:03:25 EDT
So I've been getting both the MAC and the serial numbers... with kssendmac and kssendsn. In my last 30 installs anyway.
Comment 13 Bill Pemberton 2013-07-17 13:21:45 EDT
(In reply to Nathanael Noblet from comment #12)
> So I've been getting both the MAC and the serial numbers... with kssendmac
> and kssendsn. In my last 30 installs anyway.

Using what image? I don't see it working with the Fedora-19-x86_64-netinst.iso.
Comment 14 Nathanael Noblet 2013-07-17 13:43:37 EDT
I used the Fedora-19-i386-netinst.iso the sha256sum is 2b16f5826a810bb8c17aa2c2e0f70c4895ee4b89f7d59bb8bf39b07600d6357c. I copied the kernel and initrd from that, placed it on a usb thumbdrive that our machines boot from. The kernel line is: 

label linux-f19
  menu label ^Install Fedora 19
  menu default
  kernel vmlinuz-f19
  append initrd=initrd-netinstall-f19.img repo=http://mirrors.noblet.ca:8080/cobbler/ks_mirror/Fedora19-i386/ rd.luks=0 rd.md=0 rd.dm=0 kssendmac kssendsn ks=http://mirrors.noblet.ca:8080/ns-kickstart-f19.php?DOMAIN=ucmc

The squashfs/stage two are loaded from the cobbler mirror of the Fedora 19 i386 DVD.

In no way did I recompile or otherwise alter anything coming from fedora. No respins or updated isos...
Comment 15 Bill Pemberton 2013-07-17 13:53:48 EDT
Ok, so to document what I'm doing.  Basically the same thing except I'm using the x86_64 kernel and initrd from the Fedora-19-x86_64-netinst.iso.  My grub line:

menuentry 'Network install' --class gnu-linux --class gnu --class os {
	linux /f19_64 vnc nameserver=128.143.2.7 ip=128.143.12.155::128.143.12.1:255.255.0.0:ciclamino.itc.virginia.edu:eth0:off ks=http://viridian.itc.virginia.edu/ks/ks.cgi?ksversion=19 kssendmac
	initrd /f19_64.img
}

And I don't see any HTTP_X_RHN_PROVISIONING_MAC headers on the kickstart server.  The only thing I see special are HTTP_X_ANACONDA_SYSTEM_RELEASE and HTTP_X_ANACONDA_ARCHITECTURE.
Comment 16 Nathanael Noblet 2013-07-17 15:03:28 EDT
the server accepting the request is running php... here are all the $_SERVER variables

Array
(
    [HTTP_USER_AGENT] => curl/7.29.0
    [HTTP_HOST] => mirrors.noblet.ca:8080
    [HTTP_ACCEPT] => */*
    [HTTP_X_ANACONDA_ARCHITECTURE] => i686
    [HTTP_X_ANACONDA_SYSTEM_RELEASE] => Fedora
    [HTTP_X_RHN_PROVISIONING_MAC_0] => em1 e8:9a:8f:46:13:97
    [HTTP_X_SYSTEM_SERIAL_NUMBER] => LUSFS0D16412701F067600
    [PATH] => /sbin:/usr/sbin:/bin:/usr/bin
    [SERVER_SIGNATURE] => <address>Apache/2.2.15 (CentOS) Server at mirrors.noblet.ca Port 8080</address>

    [SERVER_SOFTWARE] => Apache/2.2.15 (CentOS)
    [SERVER_NAME] => mirrors.noblet.ca
    [SERVER_ADDR] => 10.0.2.15
    [SERVER_PORT] => 8080
    [REMOTE_ADDR] => 10.0.2.2
    [DOCUMENT_ROOT] => /var/www/mirror/
    [SERVER_ADMIN] => root@localhost
    [SCRIPT_FILENAME] => /var/www/mirror/ns-kickstart-f19.php
    [REMOTE_PORT] => 34553
    [GATEWAY_INTERFACE] => CGI/1.1
    [SERVER_PROTOCOL] => HTTP/1.1
    [REQUEST_METHOD] => GET
    [QUERY_STRING] => DOMAIN=ucmc
    [REQUEST_URI] => /ns-kickstart-f19.php?DOMAIN=ucmc
    [SCRIPT_NAME] => /ns-kickstart-f19.php
    [PHP_SELF] => /ns-kickstart-f19.php
    [REQUEST_TIME_FLOAT] => 1374087713.424
    [REQUEST_TIME] => 1374087713
)
Comment 17 Bill Pemberton 2013-07-17 15:48:44 EDT
Aha!  It dhcp vs explicitly setting the ip address.  I see one difference in my config and Nathanael's is the use of dhcp.  If I remove the ip= portion of my config, I get a HTTP_X_RHN_PROVISIONING_MAC_0 just like I should.

So, kssendmac works as long as you use dhcp.  I can't in most cases, so it's not quite fixed for me.
Comment 18 Fedora End Of Life 2015-01-09 16:58:34 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 19 Adam Williamson 2015-01-09 17:09:12 EST
Bill, is this still a problem with 21? Thanks!
Comment 20 Bill Pemberton 2015-01-13 09:57:32 EST
Yes, 21 is broken in exactly the same way as 19.  The only way kssendmac will only provide the HTTP_X_RHN_PROVISIONING_MAC_* is if dhcp is used for the install.

However, this bug is nearly 3 years old so if no one else has noticed, I was apparently the only one using this feature -- and I worked around it a long time ago so you may as well just close it.
Comment 21 Adam Williamson 2015-01-13 11:27:21 EST
eh, it's a clearly described and apparently valid bug, I think it's fine to keep it around.
Comment 22 Will Woods 2015-01-15 18:38:20 EST
The problem here is this:

1) When a NIC appears, if we have an 'ip=XXX' arg for it, we configure it and use it to fetch the kickstart.

2) We wait for udev to settle before adding the X-RHN-Provisioning-MAC-* headers to ensure that all MAC addresses will be present in the headers.

Each rule makes sense separately but together there's a race: if your NIC comes online before udev fully settles, you won't get X-RHN-Provisioning-MAC-* headers. DHCP appears to slow things down sufficiently that udev settles before the kickstart gets fetched.

So there's two obvious solutions:

a) Always wait for udev to settle before fetching the kickstart.

This can take an unexpectedly long time, since you have to wait for *every* device in the system to appear - even if they're not going to be used by the installer. This can problematic on systems with slow devices, or just lots of devices. (We definitely see systems with hundreds or thousands of NICs/disks..)

b) Add X-RHN-Provisioning-MAC-* for each NIC as it appears.

This ensures that you always get the MAC of the device requesting the kickstart, although other MACs may not be present.

As far as I can tell, a) is the documented behavior from RHEL6, so probably that should be what 'inst.ks.sendmac' gets you.
Comment 23 Will Woods 2015-06-26 15:50:26 EDT
This should be fixed by https://github.com/rhinstaller/anaconda/commit/e083bbc, which will be in F23.
Comment 24 Jan Kurik 2015-07-15 11:07:59 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
Comment 25 Fedora End Of Life 2016-11-24 05:40:03 EST
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 26 Fedora End Of Life 2016-12-20 07:13:47 EST
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.