Project

General

Profile

Actions

Bug #1474

closed

Foreman reports different host architecture with new facter version 1.6.5 (x86_64 vs amd64)

Added by Andreas Ntaflos about 12 years ago. Updated almost 12 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Importers
Target version:
Difficulty:
Triaged:
Fixed in Releases:
Found in Releases:

Description

Not sure if this is a bug in facter or Foreman. Since upgrading from facter 1.6.4 (from apt.puppetlabs.com) to 1.6.5 the host architecture for 64bit hosts displayed by Foreman changed from "x86_64" to "amd64".

We use Ubuntu 10.04.3 almost exclusively. Before, all machines showed "x86_64" whereas now they are "amd64". Interestingly, the facts reported by facter are the same, at least when called interactively. Here using facter 1.6.4 on a KVM instance of Ubuntu 10.04.3:

$ facter --version
1.6.4
$ sudo facter |egrep "(hard|arch)" 
architecture => amd64
hardwareisa => unknown
hardwaremodel => x86_64

Here using facter 1.6.5 on a KVM instance of Ubuntu 10.04.3:

$ sudo facter --version
1.6.5
$ sudo facter | egrep "(hard|arch)" 
architecture => amd64
hardwareisa => unknown
hardwaremodel => x86_64

On the surface it doesn't seem like anything has changed in facter, but that's all I can say for sure.

This change in behavior resulted in an interesting bug when provisioning new hosts. The operating system for the new host is set to Ubuntu 10.04, using x86_64 as architecture, as ever before. Then the installation takes place, unattended and using preseed. In the finish script the new host installs puppet and sets various config files, then connects to the puppetmaster. There it apparently reports its architecture, which is no longer x86_64, as it would have been before, but "amd64". Unfortunately, "amd64" is not activated for the operating system that gets installed (because it never even existed before the newly built host reports it in), and the finish script can't correctly fetch the /unattended/built resource but instead gets a "409 Conflict" from Foreman.

This particular problem can be solved by adding "amd64" to the valid architectures for the operating system, but it took me a few hours to track this down.

Actions #1

Updated by Ohad Levy almost 12 years ago

  • Category set to Importers
  • Status changed from New to Closed
  • Assignee set to Ohad Levy
  • Target version set to 1.0

this was fixed in 1.0

Actions

Also available in: Atom PDF