BIOS that SMIBIOS is not fuly supported by dmidecode causes image autmatic installation fail

[Hsin-Yi, Chen (hychen)]

Image: Ubuntu 12.04 LTS

The suffix of hostname is too long and makes ubiqutiy automatic installation failed
because suffix contains the warring message of dmidecode.

Here is the error message in /var/log/installer/debug when installtion is failed.

Traceback (most recent call last):
  File "/usr/lib/ubiquity/plugins/ubi-usersetup.py", line 394, in info_loop
    self.hostname_error(make_error_string(self.controller, errors))
  File "/usr/lib/ubiquity/plugins/ubi-usersetup.py", line 69, in make_error_string
    return "\n".join([controller.get_string(error) for error in errors])
TypeError: sequence item 0: expected string, NoneType found

In automation installtion, ubiquity uses product name from BIOS as hostname suffix by
parsing dmidecode output, but if a SMBIOS version is large thatn the version dmidecode supported,
the output of `dmidecode -s system-product-name` or `dmidecode -s system-version`
contains the following warring message, so that hostname suffix is invalid.

The warring message is

````
# SMBIOS implementations newer than version 2.7 are not
# fully supported by this version of dmidecode.
````

**** Additional information:

ubiquity package version:

ii ubiquity 2.10.26 Ubuntu live CD installer
ii ubiquity-casper 1.315.1 Configuration hooks for live installer
ii ubiquity-frontend-gtk 2.10.26 GTK+ frontend for Ubiquity live installer
ii ubiquity-plugin-apt-setup 1.1 Ubiquity plugin - apt-setup
ii ubiquity-slideshow-ubuntu 58.2 Ubiquity slideshow for Ubuntu
ii ubiquity-ubuntu-artwork 2.10.26 Ubuntu artwork for Ubiquity live installer

[Colin Watson (cjwatson)]

dmidecode really ought to print this message to stderr, not stdout (at least when the -s option is in use, indicating a desire for machine-readable output; there might be backward-compatibility concerns with changing it in general). That would be much less fragile than trying to parse this out in ubiquity.

[Hsin-Yi, Chen (hychen) (ossug-hychen)]

@Colin

How about using python-dmidecode to get product name instead of parsing the output of dmidecode in ubiquity?

[Colin Watson (cjwatson)]

Interesting idea, but (a) it's currently in universe and would need MIR
paperwork, (b) I'm not at all comfortable with the fact that it's
basically a copy of dmidecode, so we'd need to make sure changes to
dmidecode were reflected in python-dmidecode.

[Hsin-Yi, Chen (hychen) (ossug-hychen)]

@Colin

you are right, using python-dmidecode brings up extra maintain efforts, so the solution I could image now is only trying to parse this out in ubiquity.

[Andy Whitcroft (apw)]

It turns out that dmidecode has had its boundary moved up 2.8 for saucy. This does not fix the issue but makes it much much less likely to be hit in saucy release images at least.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Tim Chen (timchen119)]

Could we backport the saucy's (or trusty's ) dmidecode to Precise? I try to find the bzr branch but lp:dmidecode seems a bit outdated.

[Ara Pulido (ara)]

Removing it from the OEM priority queue, as it works well in Trusty

[Marcus Tomlinson (marcustomlinson)]

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

[Marcus Tomlinson (marcustomlinson)]

This issue has sat incomplete for more than 60 days now. I'm going to close it as invalid. Please feel free re-open if this is still an issue for you. Thank you.

[Steve Langasek (vorlon)]

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release