Upgrade to Debian 12 - Boot alert: systemd[1]: Invalid DMI field header

[cdeb]

Hello,

What is described below has occurred using Debian on Oracle VirtualBox 7.0.8, on a Windows host.

Following a "full-upgrade" from Debian 11 to Debian 12, on boot there is a new message/alert that appears briefly:

systemd[1]: Invalid DMI field header.

This message is also to be found using dmesg or journalctl -b.

If I do an "upgrade" from Debian 11 to Debian 12 (rather than a "full-upgrade"), the alert does not appear. Following such an upgrade, though, if I manually upgrade systemd (systemd 247 (247.3-7+deb11u2) to systemd 252 (252.6-1)), the message then appears on boot.

The alert also appears for me following a fresh install of Debian 12 (using debian-12.0.0-amd64-netinst).


Questions:

• What does "systemd[1]: Invalid DMI field header" mean?
• What is the best way to investigate a "Invalid DMI field header", to track down/fix the problem.
  (I started by using dmidecode. There was no difference between dmidecode reports produced before and after a systemd upgrade. Any suggestions for other places to look?)
• Might there (possibly) be a bug in the updated systemd?
  (I have not noticed anyone else reporting this alert, so suspect it is more likely that the problem is at my end, and probably not a bug...(?))

If anyone can help with any of these queries, it would be greatly appreciated.
With thanks.

[CwF]

(I have not noticed anyone else reporting this alert, so suspect it is more likely that the problem is at my end, and probably not a bug...(?))

Likely a bug with the virtualizers machine definitions.

It would be interesting if the same occurs under a Debian KVM host, or on bare metal.

[fabien]

I started by using dmidecode.

That's a good idea. It could be useful that you post the full output of dmidecode.

[cdeb]

Hi CwF,
Thank you.
Very good suggestions.
Will look around at VirtualBox as well.
And also look into trying out on alternative.

[cdeb]

Hi Fabien,
Thanks.
dmidecode output follows:

Code: Select all

# dmidecode 3.4
Getting SMBIOS data from sysfs.
SMBIOS 2.5 present.
10 structures occupying 455 bytes.
Table at 0x000E1000.

Handle 0x0000, DMI type 0, 20 bytes
BIOS Information
	Vendor: innotek GmbH
	Version: VirtualBox
	Release Date: 12/01/2006
	Address: 0xE0000
	Runtime Size: 128 kB
	ROM Size: 128 kB
	Characteristics:
		ISA is supported
		PCI is supported
		Boot from CD is supported
		Selectable boot is supported
		8042 keyboard services are supported (int 9h)
		CGA/mono video services are supported (int 10h)
		ACPI is supported

Handle 0x0001, DMI type 1, 27 bytes
System Information
	Manufacturer: innotek GmbH
	Product Name: VirtualBox
	Version: 1.2
	Serial Number: 0
	UUID: 9da9f7d9-d4ae-dc4b-85ba-cb40cb5be95d
	Wake-up Type: Power Switch
	SKU Number: Not Specified
	Family: Virtual Machine

Handle 0x0008, DMI type 2, 15 bytes
Base Board Information
	Manufacturer: Oracle Corporation
	Product Name: VirtualBox
	Version: 1.2
	Serial Number: 0
	Asset Tag: Not Specified
	Features:
		Board is a hosting board
	Location In Chassis: Not Specified
	Chassis Handle: 0x0003
	Type: Motherboard
	Contained Object Handles: 0

Handle 0x0003, DMI type 3, 13 bytes
Chassis Information
	Manufacturer: Oracle Corporation
	Type: Other
	Lock: Not Present
	Version: Not Specified
	Serial Number: Not Specified
	Asset Tag: Not Specified
	Boot-up State: Safe
	Power Supply State: Safe
	Thermal State: Safe
	Security Status: None

Handle 0x0007, DMI type 126, 42 bytes
Inactive

Handle 0x0005, DMI type 126, 15 bytes
Inactive

Handle 0x0006, DMI type 126, 34 bytes
Inactive

Handle 0x0002, DMI type 11, 7 bytes
OEM Strings
	String 1: vboxVer_7.0.8
	String 2: vboxRev_156879

Handle 0x0008, DMI type 128, 8 bytes
OEM-specific Type
	Header and Data:
		80 08 08 00 FE B3 2D 00

Handle 0xFEFF, DMI type 127, 4 bytes
End Of Table

[fas]

I'm seeing exactly the same thing on both the VirtualBox VMs that I have just upgraded to Debian 12. It doesn't seem to be causing anything not to work, so I have largely ignored it, but I did a search this morning and found this post, so I shall be interested to hear the outcome. I've no idea what it is referring to or where to start looking, but if I can help by posting anything useful I'll be happy to.

[fabien]

Code: Select all

Handle 0x0008, DMI type 2, 15 bytes
Base Board Information
	Manufacturer: Oracle Corporation
	Product Name: VirtualBox
[...]
Handle 0x0008, DMI type 128, 8 bytes
OEM-specific Type
	Header and Data:
		80 08 08 00 FE B3 2D 00

From man 8 dmidecode:

Each record has:

• A handle. This is a unique identifier, which allows records to reference each other. For example, processor records usually reference cache memory records using their handles.

• A type. The SMBIOS specification defines different types of elements a computer can be made of. In this example, the type is 2, which means that the record contains "Base Board Information".

• A size. Each record has a 4-byte header (2 for the handle, 1 for the type, 1 for the size), the rest is used by the record data. This value doesn't take text strings into account (these are
placed at the end of the record), so the actual length of the record may be (and is often) greater than the displayed value.

• Decoded values. The information presented of course depends on the type of record. Here, we learn about the board's manufacturer, model, version and serial number.

So the DMI table has a flaw (two handles with the same identifier). It's a VirtualBox bug as @CwF rightly pointed out.
Probably the previous version of systemd didn't check the DMI table, or simply didn't report some types or error.
If it works, this error can probably be ignored.

[cdeb]

Hi @fas,
Thank you for posting.
Useful to know that this is happening in more than one place.
Summary is on its way, below, in response to fabien's most recent post.

[cdeb]

Hi @fabien,

Thank you for your explanation:

So the DMI table has a flaw (two handles with the same identifier).

As mentioned, I had compared the dmidecode reports from Debian 11 and Debian 12 and, finding them identical, had mistakenly dismissed this as a place for identifying the problem. But, I hadn't done the key step that fabien did of looking at the reports closely, and observing the duplicate header. So, a take-home message for me is to avoid assumptions and (at least try to) look more attentively at what is presented.

Interesting that the duplicates headers were in both Debian 11 and Debian 12, but the error is only now being reported.

Probably the previous version of systemd didn't check the DMI table, or simply didn't report some types or error.

Thanks too, to @CwF :

Likely a bug with the virtualizers machine definitions.

It's a VirtualBox bug as CwF rightly pointed out.

Further to that: it would appear that the issue DMI Handle is not unique has been about for a while on Virtual Box.
An Ubuntu user raised it (with Handle 0x0008 for them, too): https://www.virtualbox.org/ticket/19781

If it works, this error can probably be ignored

So far, my bookworm is working OK.
Hopefully, then, the alert and error can be ignored.

But, I will send something through to VirtualBox.

Again, thank you all for your help.