I just reproduced this one - develop branch. It blows up even when OS is set.

Greg, it looks like we are merging the parameters incorrectly, we need to get rid of the root "discover" element:

  Parameters: {"utf8"=>"✓", "authenticity_token"=>"MHEY/WxtPNYH+uHJ5sRYl6C+qsnYlfXBvv2Cl46ExM4=", "host"=>{"name"=>"52540039fb52", "hostgroup_id"=>"", "environment_id"=>"1", "puppet_ca_proxy_id"=>"1", "puppet_proxy_id"=>"1", "managed"=>"true", "progress_report_id"=>"[FILTERED]", "type"=>"Host::Managed", "domain_id"=>"1", "realm_id"=>"", "mac"=>"52:54:00:39:fb:52", "subnet_id"=>"1", "ip"=>"192.168.122.186", "interfaces_attributes"=>{"new_interfaces"=>{"_destroy"=>"false", "type"=>"Nic::Managed", "mac"=>"", "name"=>"", "domain_id"=>"", "ip"=>"", "provider"=>"IPMI"}}, "architecture_id"=>"1", "provision_method"=>"build", "build"=>"1", "disk"=>"", "root_pass"=>"[FILTERED]", "is_owned_by"=>"1-Users", "enabled"=>"1", "model_id"=>"1", "comment"=>"", "overwrite"=>"false"}, "discover"=>{"puppetclass_ids"=>[""], "operatingsystem_id"=>"1", "medium_id"=>"1", "ptable_id"=>"7"}, "id"=>"52540039fb52"}

What caused the change?

@lukas I can't replicate that at all - with latest HEAD of both foreman and discovery, the form renders all objects with host[] not discover[]

Greg, I just reproduced once again.

Just to put us on the same wave:

- discovered a random host
- on a discovered hosts page, clicked on Provision button
- New Host page appeared
- switched to Show Source browser feature
- search for "os_select" text
- this is what I see:

<span id="os_select">
    <div class="clearfix"><div class="form-group "><label class="col-md-2 control-label" for="operatingsystem_id">Operating system</label><div class="col-md-4"><select class="form-control " data-url="/os_selected_discovered_hosts" disabled="disabled" id="discovered_host_operatingsystem_id" name="discovered_host[operatingsystem_id]" onchange="os_selected(this);"><option value=""></option>
</select><span class="help-block"></span></div><span class="help-block help-inline"><img alt="Spinner" class="hide" src="/assets/spinner.gif" /></span></div></div>
</span>

Note the: name="discovered_host[operatingsystem_id]"

When I do New Host directly (clear case, no Discovered Hosts page involved), I see this correctly:

<span id="os_select">
  <div class="clearfix"><div class="form-group "><label class="col-md-2 control-label" for="operatingsystem_id">Operating system</label><div class="col-md-4"><select class="form-control " data-url="/hosts/os_selected" disabled="disabled" id="host_operatingsystem_id" name="host[operatingsystem_id]" onchange="os_selected(this);"><option value=""></option>
</select><span class="help-block"></span></div><span class="help-block help-inline"><img alt="Spinner" class="hide" src="/assets/spinner.gif" /></span></div></div>
</span>

Looking at the discovery/foreman code I think this naming is not correct.

This is my local gem set:

$ cat bundler.d/Gemfile.local.rb 
gem "facter" 
gem "pry-rails" 
gem "pry-plus" 

# plugins
gem 'foreman_discovery', :path => "../foreman_discovery/" 

Discovery: 5c524bb33caee8331e3ac3feac5633fb238910cc
Foreman: 7f7c531e3e35d30687aacb41ba00ebd04c2e0daf

I have the same problem running Foreman 1.6.1 and discovery 1.4.0 RC4. It doesn't occur for all hosts, but I have at least two discovered hosts where the error is reproducable. When viewing the page source I can see the wrong name="discovered_host[operatingsystem_id]" too.

Please tell me if there is something I can do to trace the origin of this error.

Frank, thanks for the report. Are you able to tell for which hosts do you enconter the error? I'd like to identify when it happens.

Lukas Zapletal wrote:

Frank, thanks for the report. Are you able to tell for which hosts do you enconter the error? I'd like to identify when it happens.

Unfortunately no. I was unable to find a scheme, it seems to happen for random hosts.

Frank, can you please re-test with this image:

https://lzap.fedorapeople.org/temp/foreman-discovery-2.0pre1/

I haven't confirmed yet, but user on IRC channel reports a workaround:

14:34 kick-buttowski | provision the machine with the ip that it booted from ( the discovery dhcpd ip )
14:34 kick-buttowski | and change it once you get a full host real quick ( before it get's built )

I guess I've found a way to reliable reproduce this error. You need to trigger a "Overwrite"-Condition, i.e. use an IP address or DNS name that is already in use. In this case foreman will notify about this problem and provide you with the "Overwrite" button. Once you click the button you will see the famous error: "undefined method `boot_filename' for nil:NilClass". You will also see the wrong parameters as described in comments 5 and 7.

@Lukas: Tested the new discovery image, but no change. I doubt that this bug is related to the discovery image.

The workaround from comment 12 does not work for me either. I still get the boot_filename error when trying to provision the discovered host.

I just reproduced it even without Discovery. I did select an architecture but nothing else on the OS tab! I am leaving the discovery project until we identify what is wrong.

Hm. I've tested the patch from pull request 2026. It certainly fixes the boot_filename exception, but it doesn't solve the problem.

Once I try to use an IP/MAC where a DHCP/DNS entry already exists, Foreman prompts me to overwrite the old entry. When this happens, the parameter for operatingsystem gets lost, because it is again wrapped inside the discovery_host parameter:

"discovered_host"=>{"puppetclass_ids"=>[""], "operatingsystem_id"=>"9"}

This leads to a loop: I set the operating system again, click "Overwrite", and the operating system is once again empty...