Bug 826657

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?

looks like this is most likely anaconda in the end

Created attachment 601564 [details]
rd.debug /run/initramfs/init.log (grabbed at the package dependency check)

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.

This should be fixed by 35a93ddd452d11aaacee16e1e8ece301ff310c0a on master.

Bill, Nathanael, can either of you confirm that this is fixed in F18/F19? Thanks.

F18 and F19 still don't send the  HTTP_X_RHN_PROVISIONING_MAC_* headers with kssendmac.

Thanks. Bumping to f19 and setting back to ASSIGNED.

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.

Using inst.ks.sendmac doesn't change anything on F18 or F19, there's still no extra headers sent to the server.

Aw, and there I thought I'd figured it out.

So I've been getting both the MAC and the serial numbers... with kssendmac and kssendsn. In my last 30 installs anyway.

(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.

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...

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.

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
)

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.

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.

Bill, is this still a problem with 21? Thanks!

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.

eh, it's a clearly described and apparently valid bug, I think it's fine to keep it around.

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.

This should be fixed by https://github.com/rhinstaller/anaconda/commit/e083bbc, which will be in F23.

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

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.

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.