Invalid entry length (0). DMI table is broken! Stop.

[UWPVIOLATOR]

Server

• FOG Version: 1.4.4
• OS: Ubuntu 16.04

Client

• Service Version:
• OS:

Description

Invalid entry length (0). DMI table is broken! Stop.

Getting hosts that have this in the inventory. Was testing out postscripts and auto download drivers and found a host that I could not get its inventory to read. Deleted the host re inventory. Ran mysql maintenance.

How do I repair this table? I see about 211 hosts with this in their inventory.

mysqlcheck
DELETE FROM `hosts` WHERE `hostID` = '0';
DELETE FROM `hostMAC` WHERE hmID = '0' OR `hmHostID` = '0';
DELETE FROM `groupMembers` WHERE `gmID` = '0' OR `gmHostID` = '0' OR `gmGroupID` = '0';
DELETE FROM `snapinGroupAssoc` WHERE `sgaID` = '0' OR `sgaSnapinID` = '0' OR `sgaStorageGroupID` = '0';
DELETE from `snapinAssoc` WHERE `saID` = '0' OR `saHostID` = '0' OR `saSnapinID` = '0';
DELETE FROM `hosts` WHERE `hostID` NOT IN (SELECT `hmHostID` FROM `hostMAC` WHERE `hmPrimary` = '1');
DELETE FROM `hosts` WHERE `hostID` NOT IN (SELECT `hmHostID` FROM `hostMAC`);
DELETE FROM `hostMAC` WHERE `hmhostID` NOT IN (SELECT `hostID` FROM `hosts`);
DELETE FROM `snapinAssoc` WHERE `saHostID` NOT IN (SELECT `hostID` FROM `hosts`);
DELETE FROM `groupMembers` WHERE `gmHostID` NOT IN (SELECT `hostID` FROM `hosts`);
DELETE FROM `tasks` WHERE `taskStateID` IN ("1","2","3");
DELETE FROM `snapinTasks` WHERE `stState` in ("1","2","3");

[Tom Elliott]

you could, for the time being, truncate the inventory table I suppose?

Do we know when this started happening?

[UWPVIOLATOR]

@Tom-Elliott No I think it’s been link this for a long time. But now that we got the driver postscript working, it can’t find the folder when the model name is “OptiPlex 740 Enhanced Invalid entry length (0). DMI table is broken! Stop.” when it really needs “OptiPlex 740 Enhanced”

[Jason Shoemake]

@UWPVIOLATOR it would appear we have similar issues. Our Dell Precisions are doing something similar “Precision T3610 Invalid entry length (16). Fixed up to 11.” This is breaking our postdownload driver scripts as well. If you do a debug task on one of the machines and run dmidecode -t 1 you should see the invalid portion at the bottom. I can confirm on a T3610 that dmidecode 3.0-3 fixes the issue, it appears that fog is using version 3.0 (cannot confirm this though).

https://bugzilla.redhat.com/show_bug.cgi?id=1384195

[george1421]

@Jason-Shoemake If that is the case we’re going to have to compile an updated version of dmidecode. I just checked an updated version of centos 7 and its still running 3.0.

Once we get an updated version of dmidecode compiled we can then (short term) shim that into the inits using a postinit script. That will allow us to patch the inits until its proven to work. The developers then can get it into the official inits.

[Jason Shoemake]

@george1421 you are correct CentOS 7 is 3.0-2, Latest Fedora 26 is 3.1-1, Ubuntu 17.04 is 3.0-4.

I tested 3.0-2 and 3.0-4 on the precision using a USB stick and can confirm the error is indeed resolved in versions newer than 3.0-2

Thanks for the response.

[george1421]

@Jason-Shoemake well if you have a working dmidecod let see if we can write a bash script to inject that into FOS.

[george1421]

@developers Jason has confirmed that both dmidecode v 3.0-2 (from centos 7) and 3.1-1 (from Fedora 26) addresses this issue with the invalid entry length. Can we get the updated dmidecode in the current inits or in the 1.5.0 RC stream?

We currently have a work around using a postinit script patching the inits.

[Sebastian Roth]

@george1421 I just tried the 32 bit binaries in Fedora 26 RPMs (32 bit and 64 bit). Seems to work, shows version 3.1. Just download and extract the RPMs to get the binaries.

For the longterm solution I think we need to wait a few more weeks. Although dmidecode was bumped to version 3.1 in the buildroot master branch in May already (see here) it has not been included into one of the releases yet. Most current branch 2017.05.x still uses dmidecode 3.0.

[george1421]

@Sebastian-Roth I can confirm that 3.0-2 is in an up to date (fully patched) version of centos 7 r1611.

[george1421]

Just for clarity here, I gave jason instructions for patching FOS with an updated version of dmidecode already so all he needed was the steps. Jason had the updated version of dmidecode from Centos as well as Fedora (v 3.1-1). My instructions to him was as follows:

1. Copy the working file to /images/dev/postinitscripts on the fog server
2. Edit /images/dev/postinitscripts/fog.postinit
3. Append the following line to the bottom of the fog.postinit script.

cp --force ${postinitpath}/dmidecode /usr/sbin

4. That command will copy dmidecode (the fixed one) over the top of the one in FOS /usr/sbin
5. End of steps, now schedule a inventory or deployment.

[Jason Shoemake]

@george1421 sorry if I had a typo somewhere, but 3.0-2 does not work. I have confirmed that anything newer than that does indeed work. Using 3.1-1 and your fix everything is working across the board now on our server. Thanks a lot, hopefully this will be helpful for @UWPVIOLATOR as well.

[Sebastian Roth]

@george1421 @Jason-Shoemake I just reported this issue to the buildroot devs and they told me that 3.1 will be in the next release coming end of August. They even think about back-porting it to the LTS version (2017.02.4).

Please keep your eyes open for the next release (https://buildroot.org/news.html) and remind Tom and me to update the buildroot then.

[Tom Elliott]

I’ve rebuilt the init’s with dmidecode 3.1 built in now. RC-3 has this update among other fixes.

[george1421]

You can get the inits here, without upgrading to 1.5.0RC series. Here is the wget command to use from the FOG server’s linux console.

wget https://fogproject.org/inits/init.xz
wget https://fogproject.org/inits/init_32.xz

These files go in /var/www/html/fog/service/ipxe. Make sure you backup the current files before you update them with these.

With these new inits there is no need to use the postinit patch method I described below.