14.04.4: work-around "SMBIOS-implementations-newer-than-version-2-8..." junk from dmidecode

Bug #1539266 reported by Jason Gerard DeRose
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Fix Released
Medium
Unassigned
Trusty
Fix Released
Medium
Unassigned
Wily
Won't Fix
Medium
Unassigned

Bug Description

[Impact]
This impacts installations on new hardware which is not well supported by the version of dmidecode available in the release (2.12); this is especially apparent with systems based on the Intel Skylake line of processors.

[Test case]
Attempt an install with ubiquity (Desktop image), on 15.10 or any prior release on a Skylake system. Installation will crash at the username/hostname panel in ubiquity.

[Regression potential]
None. This explicitly replaces a known string warning for the system model coming from dmidecode only in the case where ubiquity uses it as a basis for a hostname; and doesn't affect any other part of the installation or the final system.

---

With dmidecode older than 3.0, certain newer hardware contains a large warning message in, say, the system-product-name string.

For example, this:

dmidecode --quiet --string system-product-name

Would return something like:

SMBIOS-implementations-newer-than-version-2-8-are-not-fully-supported-by-this-version-of-dmidecode-MODEL-NAME

This is problematic because the resulting default hostname built by Ubiquity isn't valid (it's too long).

I while back I investigated backporting dmidecode 3.0 to 14.04.4, but it seems to have problems with older kernels for certain string keys (I was testing with the 3.19 kernel).

Another way to work around this is to have Ubiquity clean this up before using the system-product-name string as part of the default hostname.

So I'm going to whip up a merge proposal for Ubiquity to fix this. Apologies I'm bringing this up so near the 14.04.4 release, I dropped the ball on this one.

Thanks!

Revision history for this message
Adam Conrad (adconrad) wrote : Please test proposed package

Hello Jason, or anyone else affected,

Accepted ubiquity into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ubiquity/2.18.8.12 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in ubiquity (Ubuntu Trusty):
status: New → Fix Committed
tags: added: verification-needed
Mathew Hodson (mhodson)
Changed in ubiquity (Ubuntu):
importance: Undecided → Medium
Changed in ubiquity (Ubuntu Trusty):
importance: Undecided → Medium
Revision history for this message
Jason Gerard DeRose (jderose) wrote :

Okay, I tested:

* Normal install on physical hardware with an Haswell laptop (BIOS mode, SMBIOS older than 2.8)

* Normal install on physical hardware with a Skylake laptop (UEFI mode, SMBIOS newer than 2.8)

* OEM mode install under qemu (BIOS mode)

* OEM mode install under qemu (UEFI mode)

* OEM first-run user setup on physical hardware with an Haswell laptop (BIOS mode, SMBIOS older than 2.8)

* OEM first-run user setup on physical hardware with a Skylake laptop (UEFI mode, SMBIOS newer than 2.8)

Everything is shiny, so I'm removing the verification-needed tag, adding verification-done.

Thanks!

tags: added: verification-done
removed: verification-needed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubiquity - 2.18.8.12

---------------
ubiquity (2.18.8.12) trusty; urgency=medium

  [ Mathieu Trudel-Lapierre ]
  * Automatic update of included source packages: flash-kernel
    3.0~rc.4ubuntu49.7, partman-efi 25ubuntu6.14.04.2.

  [ Jason DeRose ]
  * Work-around "SMBIOS-implementations-newer-than-version-2-8..." junk from
    dmidecode when running on newer BIOS implementations. (LP: #1539266)

 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 01 Feb 2016 11:27:15 -0500

Changed in ubiquity (Ubuntu Trusty):
status: Fix Committed → Fix Released
Revision history for this message
Timo Aaltonen (tjaalton) wrote : Update Released

The verification of the Stable Release Update for ubiquity has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Seems like we have reason to believe this may also affect wily. We won't spin new images, but having an update for ubiquity may help some people.

Changed in ubiquity (Ubuntu Wily):
status: New → Triaged
importance: Undecided → Medium
Changed in ubiquity (Ubuntu):
status: New → Triaged
description: updated
Revision history for this message
Jason Gerard DeRose (jderose) wrote :

Mathieu, yes, this does effect Wily as well, which I forgot to mention. System76 worked around this by backporting dmidecode 3.0 from Xenial and delivering it in our PPA.

Originally I thought this would be the best approach for Trusty also, but dmidecode 3.0 seems to have problems when used with the 3.19 kernel and older (dmidecode segfaults when attempting to decode certain --string keys).

Revision history for this message
Brian Murray (brian-murray) wrote : Please test proposed package

Hello Jason, or anyone else affected,

Accepted ubiquity into wily-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ubiquity/2.21.37.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in ubiquity (Ubuntu Wily):
status: Triaged → Fix Committed
tags: removed: verification-done
tags: added: verification-needed
Revision history for this message
Earl Malmrose (earl) wrote :

Running 15.10 Live CD, I enabled -proposed and updated ubiquity. It still crashes. Screenshot of error details attached.

Earl Malmrose (earl)
tags: added: verification-failed
removed: verification-needed
Revision history for this message
Jason Gerard DeRose (jderose) wrote :

Earl... ah, I think that TypeError is something different, likely this bug:

https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1374193

https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1064151

https://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/912031

For the hardware I did this work-around for, Ubiquity didn't actually crash, it just had a junk default hostname that couldn't be used (because it was too long).

Revision history for this message
Earl Malmrose (earl) wrote :

Are you sure this was fixed? I still get a crazy "SMBIOS-implementations-newer-than-version-2-8-are-not-fully-supported-by-this-version-of-dmidecode" with Ubiquity 2.21.37.1.

Revision history for this message
Jason Gerard DeRose (jderose) wrote : Re: [Bug 1539266] Re: 14.04.4: work-around "SMBIOS-implementations-newer-than-version-2-8..." junk from dmidecode

----- Original Message -----
From: "Earl Malmrose" <email address hidden>
To: <email address hidden>
Sent: Thursday, February 25, 2016 2:01:31 PM
Subject: [Bug 1539266] Re: 14.04.4: work-around "SMBIOS-implementations-newer-than-version-2-8..." junk from dmidecode

Are you sure this was fixed? I still get a crazy "SMBIOS-
implementations-newer-than-version-2-8-are-not-fully-supported-by-this-
version-of-dmidecode" with Ubiquity 2.21.37.1.

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1539266

Title:
  14.04.4: work-around "SMBIOS-implementations-newer-than-
  version-2-8..." junk from dmidecode

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1539266/+subscriptions

Revision history for this message
Jason Gerard DeRose (jderose) wrote :

I haven't had a chance to test this yet on Wily, but it definitely fixed it on the hardware I tested on with the 14.04.4 daily ISOs leading up to the 14.04.4 release.

Also, I'm not entirely sure whether updating the packages from the live environment gives you an accurate test, so that might be what's going on.

At this point the 15.10 ISO can't be fixed itself, so fixing this is Wily would only really be useful for OEM mode installs (where the packages were updated prior to building the golden image).

Revision history for this message
Martin Pitt (pitti) wrote :

I removed the wily SRU from -proposed. Wily has a remaining life time of a week or two.

Changed in ubiquity (Ubuntu):
status: Triaged → Fix Released
Changed in ubiquity (Ubuntu Wily):
status: Fix Committed → Won't Fix
tags: removed: verification-failed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.