As described in another post, I was installing Linux Mint 17.3 KDE on a Lenovo ThinkPad Edge E430 laptop, in a secondary partition to dual-boot with Windows 7. I had installed Linux Mint 17.3 Cinnamon successfully in that same partition twice before. But for some reason the KDE installation ended with an error message referring to an MEBx Error State. This post describes the steps I took to resolve that situation.
Becoming Familiar with the Problem
The first time I got that message, it said “MEBx Error State : : 0106.” A search yielded the statement that there were no results for this exact phrase, but of course Google kindly ran the search again without the quotes — and pulled up a confirmation that, in the words of one writer, “Our support did not recognize (and never seen before).” That and another source suggested starting with a reboot and, if that failed, trying additional steps.
Instead of a simple reboot, I powered the laptop off (but did not remove its power cable or battery) for at least a half-minute. This time, the error was different: “MEBx Error State : : 0303.” A search for that phrase (and also a variation) yielded one result in Czech and one in Chinese. We did not progress on to any other numbers; subsequent reboots returned to that 0303 error.
Looking at the screen where the error message appeared, I saw the words, “Intel(R) Management Engine BIOS Extension.” MEBx appeared to be short for that. I was puzzled to observe that that screen also said the firmware version was 0.0.0.0. It sounded like Intel was just starting out when they designed my machine.
There were suggestions to short pins 1 and 2, in order “to reset the Intel ME configuration to the factory defaults,” as described on p. 67 of the Intel NUC Board NUC5i5MYBE Technical Product Specification document. I didn’t think I had that particular board, but was not inclined to disassemble my laptop to make sure. I saw that this procedure failed to help at least one person who went to the trouble.
Each time, at startup, I noticed that the words “FW Status Recovery Error” appeared briefly onscreen. That search was a bit more fruitful. As with the previous searches, there were recurrent references to BIOS upgrades: some people said that such upgrades helped them get past this problem. To clarify, in light of the preceding paragraph, it appeared that what I might need to upgrade would be the MEBx — that is, the Intel BIOS Extension — which was surely not the same as the Phoenix BIOS whose information screen appeared as soon as I started the machine. (I had set my BIOS to display the diagnostic screen rather than the splashscreen, so that was why I was seeing this sort of detail.)
I guessed that maybe I was getting this error because KDE wanted to take advantage of BIOS features newer than those currently available on the ThinkPad. I had told the KDE installer to reformat the partition where Cinnamon was installed, so I thought I was starting from a blank slate in that partition.
The GRUB Issue
I saw some indications that hitting Ctrl-P at bootup would put me into the MEBx. Repeatedly doing so put me back at the same MEBx error, but this time (and henceforth) it did not remain stuck there; after a few seconds it moved on to the “grub rescue” prompt. It seemed that hitting Ctrl-P had made a change in the machine’s response to the MEBx error.
This time, I noticed these words before the GRUB prompt: “error: no such device,” followed by a long string of numbers and letters. I guessed that the long string was a Universally Unique Identifier (UUID) for some device that GRUB thought it should be finding on my computer. Most likely it was the Cinnamon installation. Apparently the KDE installer had not changed that to refer to the UUID corresponding to the new KDE installation.
Another suggestion was to change the hard drive boot sequence in my BIOS. I took a look, and rearranged things slightly, but I did not expect that to be the answer, and in fact it wasn’t. I had been booting from the same drive for the past year or two, and expected to continue to do so. In my case, it seemed the change was not in the physical drives, or even in the order of bootable partitions; it was just that I had replaced one bootable partition with another, having a different UUID.
A search for the “error: no such device” message led to various suggestions, including using Boot-Repair-Disk. I had that on my YUMI drive, but for a minute I thought this MEBx error was preventing me from booting it. But when I took the error message’s advice to “Press any key to continue,” it put me through to the USB drive (having hit F12 during the initial bootup, and then selected the USB drive). In the spirit of exploration, I chose Advanced Options and made two changes to the default values: (1) In the Main Options tab, I checked Restore MBR. (2) In the MBR Options tab, I chose sdb, which in my case was the drive containing the Windows and Linux dual-boot partitions. Then I clicked Apply. Unfortunately, the problem persisted.
I re-ran Boot-Repair-Disk and this time used Recommended Repair. At first, it looked like that didn’t work: on reboot, I had the same error messages. But after I pressed a key to continue, it put me through to the desired GNU GRUB multiboot menu, giving me the choice of booting Linux Mint KDE (with or without advanced options), Memtest86+ (in two configurations), or Windows 7.
I tried the Windows 7 option. That worked. I rebooted out of Windows. The “FW Status Recovery Error” message was still there, and so was the “MEBx Error State : : 0303.” I responded to the suggestion, “Press any key to continue,” and the GNU GRUB menu was back. I didn’t respond to it, and in a few seconds it defaulted to the first item on the list, which was to boot into Linux Mint KDE. That worked too.
So it seemed we were making progress. My guess, at this point, was that I had started with two problems. One was a GRUB problem caused by the KDE installation. I doubted that the problem was in the KDE installer per se, or in the choice of partitions, or in the way I had partitioned. I suspected that GRUB got screwed up because of the other problem, which had to do with the Intel MEBx. Apparently there was a way to update that BIOS Extension; and if I did that, maybe the error message would go away; maybe it wouldn’t be there after a reinstallation; maybe it would never have appeared, if I had done that BIOS update first.
If I was wrong in that understanding of the situation, I might have to refer back to some of the other sources that I had found, regarding the task of fixing GRUB. For future reference, those included Ubuntu Community documents on installing and troubleshooting Grub2 and on recovering Ubuntu after installing Windows; there was also an oft-cited StackExchange answer on repairing GRUB, and another on the “no such partition” error, as well as an Ubuntu forums thread on that last topic.
The MEBx Issue
If the GRUB problem was fixed, then my attention needed to turn, now, to that BIOS update issue. The first question was, what exactly was I supposed to be updating? I rebooted and took another look at the MBEx screen, where the error message appeared. The top line said I had MBEx v8.0.0.0065. I wondered if maybe Lenovo had a relevant update for this machine. The most recent BIOS update on their webpage dated from 2012. I was sure I had already installed that. Well, how about Intel? Along with that previous advice about shorting pins 1 and 2 (above), a search led to an unanswered question about resetting MBEx by briefly removing the CMOS battery (not an option, to my knowledge, on a laptop); an Intel AMT Implementation and Reference Guide page on Restoring Intel AMT to Factory Mode; and the following exchange in an Intel forum:
Lance Atencio (Intel): The MEBx is an extension to the BIOS and controlled by the OEM/BIOS provider. Each one has different ways of providing access to the MEBx settings. Ctrl-P is the typical means to access, but some vendors do it differently.
You might try looking for other settings in the BIOS that would display the CTRL-p during boot or try other boot hotkeys that are available.
plmanikandan: In BIOS setting ->Advance chipset feature ->Intel AMT is enabled. I downloaded the AMT tools from Acer website and triedMEInfoWin.exe. I’m getting error as “Error 8199: Communication error between application and Intel ME (Get RCS Connectivity v2)”
Lance Atencio (Intel): It appears that this system does have AMT, but since you cannot get access to the MEBx I’m afraid I’ll have to refer you back to Acer to get help with getting your system working. The OEMs control the firmware which is where the issue seems to be.
plmanikandan: If I do a local firmware update using tool provided by Intel(downloaded from Acer website), will it recover MEBx configuration?
Paul Carbin (Intel): Updating the firmware may recover the MEBx configuration, but you are really in the domain of the OEM. Intel AMT is only a small portion of the system firmware, and Intel does not control how the OEMs implement their firmware. Updating the firmware may cause other issues, andI recommend that you work with the OEM before upgrading firmware.
Also, did you try resetting BIOS to factory defaults?
That exchange led me to think the solution might be in my BIOS. I rebooted the machine and hit F1 (on other machines it might be F2, DEL, or some other key) to get into the BIOS settings. Unlike plmanikandan in the foregoing exchange, however, I did not see an Advanced Chipset Feature option. A search led to a Lenovo forum statement that “In general, BIOS menus are limited in Notebooks,” to which the user responded that s/he did somehow hit an unknown hotkey to get into advanced mode. A revised search led to another user who likewise believed there was some such option — because s/he had discovered it, by accident, hitting some random combination of keys, but was not sure which keys s/he had hit. Another search led to a Lenovo page listing ways to access the BIOS. There was an option of hitting Ctrl-Alt-F11 from a system booted in DOS on some models, but again there was no mention of advanced options.
I tried the BIOS option of loading setup defaults. On reboot, that did it: the error messages were gone. It wasn’t just that the default (i.e., relatively pretty) ThinkPad splash screen was hiding them: the system moved immediately from that introductory splash screen to the GRUB menu. I rebooted again and hit F1, F2, and DEL (I wasn’t sure which one would cut through the splash screen) to get back into BIOS. I reconfigured everything as it was before, as far as I could remember. This took away the splash screen and replaced it with the detailed diagnostic bootup screen, among other things. And now the error messages were back.
It appeared, then, that one of my changes to the BIOS settings was triggering the error messages. Back in the BIOS settings, I reverted once more to the factory defaults, but this time I altered those in just one way: I allowed the diagnostic screens instead of the splash screen. On reboot, the error messages were back. So I was probably wrong: the errors were still there, but somehow the splash screen was just bypassing them, on its way to the GRUB menu. Apparently it wasn’t that my BIOS changes were triggering the errors; apparently they were there in any case, but the splash screen would bypass them.
One source suggested another possible solution: re-flash the BIOS. The concept here was that the BIOS was firmware — that is, software built into chips on the computer’s motherboard — and it could be updated through certain procedures. I had saved the ISO that I downloaded when I last flashed the ThinkPad’s BIOS, so now I added that to the YUMI USB drive and rebooted the ThinkPad from that BIOS update ISO. For some reason, though, what appeared on the screen was mostly illegible.
I tried again with a fresh download from the Lenovo webpage. That worked. Possibly the old version had become corrupted. The flashing involved several steps and took a few minutes. When it was done, the error messages were gone. I booted into Windows and then immediately went back out and customized the BIOS settings. Then I rebooted again. Still no error messages. They were gone. I was able to boot into Linux Mint as well. This problem appeared to be solved.