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.
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.