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

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