[Fujitsu LIFEBOOK LH532 (UMA)] Ubuntu EFI install locks out firmware access

[Satish]

:~$ apt-cache policy grub-efi-amd64
grub-efi-amd64:
  Installed: 2.00-22
  Candidate: 2.00-22

EFI installation of Ubuntu clears out the boot entries in firmware leaving user with no option but boot Ubuntu. Pressing (F2) to enter BIOS Setup has no effect as does pressing (F12) for Boot Order.
The only way to get back firmware access is to flash the bios using manufacturer provided utilities. Unfortunately Fujitsu doesn't provide a BIOS flash utility for Linux/Ubuntu. It is to be noted that installed Windows in EFI mode on the same system does not clear out firmware access but just adds the 'Windows Boot Loader' entry at the top of the boot sequence.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-image-3.13.0-5-generic 3.13.0-5.20 [modified: boot/vmlinuz-3.13.0-5-generic]
ProcVersionSignature: Ubuntu 3.13.0-5.20-generic 3.13.0
Uname: Linux 3.13.0-5-generic x86_64
ApportVersion: 2.13.1-0ubuntu1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: satish 1852 F.... pulseaudio
CurrentDesktop: Unity
Date: Mon Jan 27 11:06:37 2014
HibernationDevice: RESUME=UUID=c73dc7d0-4253-44fa-9589-d8c91c9cac13
InstallationDate: Installed on 2014-01-26 (0 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140124)
MachineType: FUJITSU LIFEBOOK LH532
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-5-generic.efi.signed root=UUID=efd53305-1eac-42ba-b3f9-828b72cb5560 ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.13.0-5-generic N/A
 linux-backports-modules-3.13.0-5-generic N/A
 linux-firmware 1.122
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 05/24/2012
dmi.bios.vendor: FUJITSU // Phoenix Technologies Ltd.
dmi.bios.version: Version 1.10
dmi.board.name: FJNBB1E
dmi.board.vendor: FUJITSU
dmi.chassis.type: 10
dmi.chassis.vendor: FUJITSU
dmi.modalias: dmi:bvnFUJITSU//PhoenixTechnologiesLtd.:bvrVersion1.10:bd05/24/2012:svnFUJITSU:pnLIFEBOOKLH532:pvr:rvnFUJITSU:rnFJNBB1E:rvr:cvnFUJITSU:ct10:cvr:
dmi.product.name: LIFEBOOK LH532
dmi.sys.vendor: FUJITSU

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Did this issue also happen with prior releases, such as Saucy or did this issue just start happening in Trusty?

[Satish (satishp)]

This issue was present in prior releases too. I faced it in Quantal and then Saucy too. The original bug report is here - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1082418
The reporter of that bug is no longer active to perform tests and since the bug affects me too, I was trying to provide reports/logs/etc. Although the manufacturer of both the systems is Fujitsu, my laptop model is different from the original bug reporter's and it was suggested to me that reporting a new bug would be better.

[penalvch (penalvch)]

Satish, so to clarify, you personally with your hardware (not someone else with different hardware on another report) experienced it from Quantal through Trusty?

[Satish (satishp)]

Yes, that's correct. I just didn't report it earlier because I assumed that any fix for the 1082418 bug would essentially fix mine too.

[penalvch (penalvch)]

Satish, thank you for providing the requested information. Just to clarify, could you please provide a click-for-click on what you did when you were installing it?

For example, you had a Windows 7/8 UEFI partition installed first, put CD in, Install Ubuntu, Install Ubuntu alongside them, etc.

[Satish (satishp)]

Here's what I did.

1. The laptop does not come with a OS pre-installed. So after opening the package, when I first switched it on, it prompted for a boot device. I instead restarted and entered the firmware (F2) and changed the Boot Order to look for CD/DVD first and then try the HDD.
2. I put in Ubuntu CD, restarted and installed.
3. On the partitioning options, I chose 'Something Else' and created around 7 partitions (GPT, obviously). Two 50GB partitions for Ubuntu and Mint (I planned to install Mint later), 10GB swap, two 100GB partitions for data (I usually install all s/w in one and put my user data in another) with the last partition taking the rest of space.
4. Ubuntu detected that my system supports EFI and prompted for separate /boot/EFI partition. I just choose Yes.
5. After installation, for a few weeks I did not try to get into firmware. Only when I put in the Mint CD, did I notice that I had no option to get into the firmware. Only Ubuntu's grub was loading. I then searched the web for problems and came across the bug 1082418. I subscribed myself.
6. Following some instructions there, I opened up the laptop and shorted a couple of pins to reset the NVRAM. This still did not let me into firmware but atleast the Boot Sequence menu was available (F12). I installed Mint OS using the CD and this too erased my firmware access including the Boot Sequence again.
7. Using the same shorting trick, I now used Fujitsu supplied FreeDOS USB image (that I burned to a USB device) to boot into FreeDOS and flashed the BIOS. This restored full access to firmware and I went in and changed the Boot Order again to try CD/DVD first.
8. Windows 8 Preview was out and I wanted to try it out. I burned a CD and installed Windows. This messed up my partitions (still working though) by creating a few more for Recovery and what not. Anyway, once inside Windows, I downloaded Fujitsu's BIOS Flash utlity to be able to flash my BIOS from Windows.
8. Point to note is that installing Windows did not clear out my firmware access. It put an entry 'Windows Boot Loader' at the top of the boot order. Ubuntu was never able to do this - I guess the whole thing was failing when Ubuntu was trying to add its boot entry.

I upgraded to Ubuntu releases as they came out and everytime it wiped out my firmware access. I installed Elementary OS as well replacing Mint and this too exhibited the same behaviour.

I now have Windows 8.1 Preview but not for long (running out in a few days) and I will not have an alternative to the shorting method then. Although I did a couple of times, I honestly don't want to mess with things by opening up the laptop.

[Satish (satishp)]

Devs,
Any chance this bug might get a little attention? It makes my pc practically un-usable.

Everytime I run "efibootmgr" with the "-c" option to create a boot entry, it erases all existing ones. Only the last entry added from efibootmgr persists - even the device select entries like Boot from USB, Boot from CD/DVD, etc go away.

If anyone can recommend how to create a boot entry for "Boot from USB" using "efibootmgr", that would be an acceptable workaround for me at this point. I could then boot the FreeDOS USB disk and flash my firmware, without opening and messing with circuitry on the board.

[Jan Henke (jhe)]

Satish for your information, utopic has a new upstream version of efibootmgr included. It might be worth checking if that is fixing your problem as well.

[Joseph Salisbury (jsalisbury)]

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

  With the recent release of this Ubuntu release, would like to confirm if this bug is still present. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get dist-upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

[Satish (satishp)]

I just checked on 14.04 (kernel 3.13.0-031300-generic) with efibootmgr version 0.6.1

The bug still exists; I created an boot loader entry and it wiped out access to firmware. I was not able to boot to CD/DVD or USB to restore it and had to open up to short the pins.

[Satish (satishp)]

More info...

I updated and now the kernel version is 3.15.0-6-generic and efibootmgr's 0.7.0

Now when I run just "efibootmgr", I get the following message

satish@LH532:~$ efibootmgr
show_boot_order(): No such file or directory

Looking at efibootmgr.c, it looks like the efi_get_variable() might be failing although I do not see any 'new' entry in dmesg. The boot time 'efivars: get_next_variable: status=8000000000000002' exist.

[aimwin (aimausy)]

Please look at my post in
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1082418/comments/74

>>>>>> My Fix and workaround.<<<<<<<<<<<

In short process.

1. Short circuit CL1 and CL2 as posts above, to get F12 boot menu.
2. Boot with live Ubuntu then convert GPT 1TB to MBR 1TB (using gdisk)
3. Install Ubuntu on one of the partition of MBR 1TB, (I made 6 partitions).

Result = multi boots ubuntu no more F12 boot menu wrecking.
Now I can install Windows and other Ubuntu derivertives, no issue on usb nor DVD boot choices.

[Jean-Pierre van Riel (jpvr)]

This bug is high risk! It's effectively bricked a Dell Latitude E6540 :-(

My theory is that, somehow, the update caused a change to the firmware NVRAM settings and boot entries for UEFI, and the Dell code can't handle something unexpected. And after I've entered BIOS password, the firmware code sadly fails to even manage to enter setup (F2) or the one time boot menu (F12). That's lousy fail-safe coding on the firmware devs part. Surely if searching NVRAM for boot options fails, that shouldn't keep the user locked out of the BIOS settings!

Here's what happened in my case:
1. Had a working install of Ubuntu Gnome 15.04 dual booting with Windows 10 and BIOS version A15 for this dell.
2. UEFI Secure Boot was enabled. The UEFI boot order priority options were set to favour the ubuntu entry (which effectively points to the EFI/ubuntu/shimx64.efi entry).
3. I ran the standard upgrade via the GUI from 15.04 to 15.10.
4. Upgrade process reported success, prompted to reboot. After a reboot, the system failed to boot into grub or anything else! Even with a UEFI compatible install CD or USB drive, I couldn't get it to boot.
5. Both F2 (BIOS setup) and F12 (one time boot menu) no longer work! This is a HUGE issue, since now I can't even use the BIOS options to change UEFI settings (e.g. look at enabled boot options, priority or disable secure boot, etc)
6. Opened up the laptop, disconnected the coin-cell CMOS battery, pressed the power button to discharge and force a BIOS settings reset (I've followed this process on many other systems to deal with a bugged out BIOS). Sadly no luck, same issue persists (I'm guessing removing the CMOS battery didn't manage to reset the NVRAM as I hoped).

What's interesting is I can take the SSD drive out, put it in a similar laptop, and it boots. It booted into Windows 10 at first, but after using settings (F2) on the working laptop, I could simply switch to the EFI/ubuntu/shimx64.efi as the first option and UEFI secure boot into Ubuntu Gnome 15.10 works fine.

[Jean-Pierre van Riel (jpvr)]

To summarise, there are at least two other related bug reports (which should add motivation given the wider impact of the issue):
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1082418
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1471380

[penalvch (penalvch)]

Jean-Pierre van Riel, given you have an outdated BIOS, you would want to update that first to see if this is resolved for your computer model. If you find an issue on the latest BIOS, then it will help immensely if you filed a new report via a terminal:
ubuntu-bug linux

Please feel free to subscribe me to it.

Also, there is no wide impact regarding this. This issue (correlated to a computer firmware bug, not a bug in Ubuntu/linux) affects one model of computer, from one manufacturer (out of the hundreds of computer models, and tens of manufacturers).

[penalvch (penalvch)]

Satish, as per http://support.ts.fujitsu.com/Download/ShowFiles.asp an update to your computer's buggy and outdated BIOS is available (2.07). If you update to this following https://help.ubuntu.com/community/BIOSUpdate does it change anything?

If it doesn't, could you please both specify what happened, and provide the output of the following terminal command:
sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date

For more on BIOS updates and linux, please see https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette .

Please note your current BIOS is already in the Bug Description, so posting this on the old BIOS would not be helpful. As well, you don't have to create a new bug report.

Once the BIOS is updated, if the problem is still reproducible, and the information above is provided, then please mark this report Status Confirmed. Otherwise, please mark this as Invalid.

Thank you for your understanding.

[Satish (satishp)]

Jean-Pierre van Riel, the exact same thing happened to me. I was under the impression that my motherboard gave out and was planning to take it to the service centre.
However I did not update Ubuntu; I rarely boot into Ubuntu these days - have been using Elementary. And I also have Windows 10 Insider Preview. Installed a bunch of updates both in Win 10 IP and Elementary and I cannot remember which one was the last.

But the issue is the same - totally bricked laptop. Nothing boots, F2 and F12 don't work. Shorting CL1 and CL2 doesn't help. Took out CMOS battery and put it back after a while; no change. Swapped HDD and RAM; no help.
I went and bought new CMOS battery too just to see if that helps.

I do not think the BIOS is outdated - Fujitsu's support page lists my BIOS as the latest.

[Jean-Pierre van Riel (jpvr)]

@Chistopher, thanks, the problem is now that my A15 bios can't even enter setup mode or boot anything, so I'm not sure how to try flash the most recent A16 version from (released just a month ago)? Searched the laptop's manual, and no indication of any jumpers to clear/reset NVRAM :-(

I agree and understand that firmware should be written in a way that doesn't allow the nvram boot option changes to cause it to lock up. Still, this kind of bug (even if attributed to firmware and not Linux) is occurring across at least two manufactures (Fujitsu and now Dell) whereby their 'buggy' firmware sees whatever changes ubuntu/Linux made to the NVRAM as NVRAM corruption and fail to even allow entering setup.

Given changing NVRAM bios settings during an install or update (as was my case) is high risk, perhaps the install process should at least issue a warning and allow the user to opt out of of clearing and changing NVRAM settings (and potentially trigger a nasty firmware bug). I think it would in some cases be safer for a user to manually go into the BIOS setup and manage the boot options from within the BIOS.

[Satish (satishp)]

@Christopher, my laptop model is LH532 (UMA) - the latest BIOS version is 1.10 and this is what the bug report has.
The one you mention (ver 2.07) is for the other model LH532/G22.
I am unable to restore the 'latest-bios-1.10' tag (laptop being bricked I'm accessing this page from my mobile).

[Satish (satishp)]

Christopher, system is not bootable any longer, so I cannot run those commands nor update BIOS if one was available.
In any case, BIOS being the latest, there's nothing to add to the report.
I shall set the report to 'Confirmed'. Let me know otherwise.

[Satish (satishp)]

@Chirstopher,
I noticed that you removed the 'latest-bios-1.10' tag again - can you explain why?
The Fujitsu support site lists 1.10 as the latest BIOS available for my model LH532 (UMA) - Serial No. DQBAxxxxxx

There are some updates to the other model LH532/G22 and all the accompanying docs warn that cross flashing across versions 1.xx and 2.xx is dangerous. Moreover, it is not the correct model so there's no reason to consider those BIOS versions in the context of this bug report.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

[Tim Schumacher (timschumi)]

I tracked this down to a bunch of edge-cases in Fujitsu's UEFI implementation, the Linux kernel, and efibootmgr.

The method of restoring access by doing a CMOS-reset (shorting the CL1_CL2 test point) and flashing the BIOS [1] was already known, but I also created a tool [2] that is supposed to restore all relevant settings from within a running Linux installation. Please do make note of the list of supported configurations and of the disclaimer.

A proper kernel-side fix is pending, but it will take some time to land in mainline Linux, linux-stable and the Ubuntu kernel tree respectively.

[1] https://support.ts.fujitsu.com/
[2] https://github.com/timschumi/ah532-biostools/