ubiquity crashed with TypeError in make_error_string(): sequence item 0: expected str instance, NoneType found

[Jason Gerard DeRose]

Testing latest daily ISO under KVM (hosted on up-to-date Utopic).

Steps I took:

1) Choose "Install Ubuntu"
2) Hit F6, then ESC, and add oem-config/enable=true to work around lp:1371651
3) Got this Apport crash as soon as the Ubiquity session started

Not sure if this is related to running under KVM, will try on hardware and report back shortly.

ProblemType: Crash
DistroRelease: Ubuntu 14.10
Package: ubiquity 2.19.8
ProcVersionSignature: Ubuntu 3.16.0-17.23-generic 3.16.3
Uname: Linux 3.16.0-17-generic x86_64
ApportVersion: 2.14.7-0ubuntu2
Architecture: amd64
CasperVersion: 1.344
Date: Thu Sep 25 22:25:07 2014
ExecutablePath: /usr/lib/ubiquity/bin/ubiquity
InstallCmdLine: file=/cdrom/preseed/ubuntu.seed boot=casper only-ubiquity initrd=/casper/initrd.lz quiet splash oem-config/enable=true --
InterpreterPath: /usr/bin/python3.4
LiveMediaBuild: Ubuntu 14.10 "Utopic Unicorn" - Alpha amd64 (20140923)
ProcCmdline: /usr/bin/python3 /usr/lib/ubiquity/bin/ubiquity --only
ProcEnviron: Error: [Errno 13] Permission denied: '/proc/2273/environ'
PythonArgs: ['/usr/lib/ubiquity/bin/ubiquity', '--only']
SourcePackage: ubiquity
Title: ubiquity crashed with TypeError in make_error_string(): sequence item 0: expected str instance, NoneType found
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

[Jason Gerard DeRose (jderose)]

Okay, seems to only happen under KVM, not on physical hardware.

Wondering if this is the same problem discussed here:

https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1371651

[Jason Gerard DeRose (jderose)]

Interestingly, this same crash is happened when using OEM config with a 14.04.1 guest on a 14.10 host.

Normal mode 14.04.1 and 14.10 guests install fine on a 14.10 host, only the OEM config mode is crashing.

[Jason Gerard DeRose (jderose)]

Okay, figured this out, more or less.

I was mocking DMI information in qemu using:

-smbios file=smbios_type_1.bin

The dump was from actual hardware, but under the seemingly more strict parsing done either by the newer kernel and/or dmidecode, the "system-product-name" ends up with a hugely long warning (and some junk characters as well, I believe).

I can likewise reproduce this bug on the actual hardware I got the dmidecode dump from, so it has nothing to do with running under qemu, as far as I can tell.

Something different in the code paths used for a normal install vs OEM install means Ubiquity crashes only when doing an OEM install.

I worked around the problem by switching to a dmidecode dump from newer hardware.

This is probably a very low priority bug as it doesn't effect normal end user installs.

[Launchpad Janitor (janitor)]

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

[Peter (andsub)]

I work as a system builder and ran into this bug today doing an OEM install on an Asus H170I-Plus D3 motherboard. The issue is seems to be related to the System-Product-Name field. When doing an OEM install it creates an invalid System-Product-Name and crashes the ubiquity installer. It seems to be echoing the dmidecode error into the field causing an invalid number of characters.

the field gets filled with:

oem-SMBIOS-implementations-newer-than-version-2-8-are-not-fully-supported-by-this-version-of-dmidecode-System-Product-Name

When i booted the installer normally. Same error but in the installer it allows me to fix the invalid field. Attached is a screenshot of that.

hope this helps!

[Pascual (pasgomar)]

I'm working as a PC builder too and have the same issue with OEM install on an MSI H110M pro VD mainboard, but I suspect the hardware is not the problem.

I'm testing with Ubuntu 15.10
my report log is almost the same except file:
ProcEnviron: Error: [Errno 13] Permission denied: '/proc/2273/environ

Is there some workaround to make an OEM install?

[Earl Malmrose (earl)]

Happening on Asus H170M-PLUS/CSM motherboard with Ubuntu 15.10 64-bit OEM Install.

[ubuntushop (g-info-l)]

workaround for now:
in your preseed file:
d-i preseed/early_command string chmod -x /root/usr/sbin/dmidecode

it's not the best solution, but we are getting a lot of new notebooks with the new smbios, which causes the problem.
When the end user does his first boot, the computername error is still present, but can be changed to shorter name.