[Fujitsu Lifebook AH532] UEFI firmware locks itself after installing Ubuntu in UEFI mode

[viking777]

lsb_release -rd
Description: Ubuntu 12.10
Release: 12.10

apt-cache policy grub-efi-amd64
grub-efi-amd64:
  Installed: 2.00-7ubuntu11
  Candidate: 2.00-7ubuntu11

Pheonix Secure Core Tiano bios version 1.09

New laptop Fujitsu Lifebook AH532. Windows 7 preinstalled. All functions worked normally when running Win7. Ubuntu 12.10 installed using whole disk. Installation successful Ubuntu boots and runs normally, however all access to the bios has now been lost. Pressing the default key (f2) during boot up is acknowledged by bios beep, but ignored and Ubuntu continues booting. In addition the 'boot choices' menu (f12) contains nothing but Ubuntu making it impossible to boot from USB or CD/DVD.

The latter (f12) problem was overcome by opening up the machine, removing the ram and shorting the cl1/cl2 posts with a screwdriver. This restores the ability to boot from USB/CD by pressing f12 but does not restore bios access.

The following recovery actions have been tried.
1) Install Boot-Repair, run repair, no change occurred. Boot repair report here:
http://paste.ubuntu.com/1375041/

2) Restore Windows from Clonezilla disk image (factory settings) - result - bios access is no longer possible from windows either, f2 now launches the Windows boot menu.

3) Update all drivers using Fujitsu driver update tool from within windows (which included a bios update). Result - no change, no bios.

4) Restored Ubuntu from Clonezilla disk image - no change.

5) Added second distro to disk. Installed successfully (uefi mode as that is all I have) no change to bios access.

So overall result I have lost all bios access even from a reinstalled Windows. I repeat that bios access was perfectly normal before installing Ubuntu.

I strongly suggest you read the contents of this thread in addition to the information here:

http://ubuntuforums.org/showthread.php?t=2086602

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: grub-efi 2.00-7ubuntu11
ProcVersionSignature: Ubuntu 3.5.0-18.29-generic 3.5.7
Uname: Linux 3.5.0-18-generic x86_64
ApportVersion: 2.6.1-0ubuntu6
Architecture: amd64
Date: Fri Nov 23 15:50:07 2012
InstallationDate: Installed on 2012-11-22 (1 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5)
MarkForUpload: True
SourcePackage: grub2
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Chris Murphy (dr4-b5gpiyla-tff)]

Referring to UEFI settings as BIOS is confusing because many UEFI implementations have a CSM that emulates legacy BIOS. I'm assuming the OP means they can't get into UEFI settings to configure UEFI, rather than being unable to boot (legacy) OS's in CSM-BIOS mode?

Has the drive either been sufficiently wiped to remove the EFI System partition, or have superfluous folders (Ubuntu or GRUB) been removed from the EFI System partition?

[YannUbuntu (yannubuntu)]

> I'm assuming the OP means they can't get into UEFI settings to configure UEFI, rather than being unable to boot (legacy) OS's in CSM-BIOS mode?

It is my understanding too.

> Has the drive either been sufficiently wiped to remove the EFI System partition, or have superfluous folders (Ubuntu or GRUB) been removed from the EFI System partition?

- the BootInfo in http://ubuntuforums.org/showpost.php?p=12366098&postcount=1 shows that just after the Ubuntu install there was only 1 file in the ESP: /boot/efi/efi/ubuntu/grubx64.efi
- and Viking777 wrote "Ubuntu 12.10 installed using whole disk.", so i guess that he used the "Erase disk and install Ubuntu" option in Ubiquity. @Viking777: please can you confirm?

[viking777 (viking-f2s)]

@YannUbuntu
I confirm I used the Erase Disk option to install Ubuntu.
@Chris Murphy
Your reference to Uefi settings confuses me. In my terminology, a bios is a hard coded chip attached to a motherboard which has settings accessed by pressing f2 at boot up for such things as setting the boot order, adjusting the hardware clock etc,etc. That is what I have lost access to.
If I now have Uefi settings as well as bios settings then that is something I have not heard of before (like I said I know very little about Uefi). How would I access those if they are different to the bios settings? This has nothing to do with booting legacy systems, all the systems I have used to date are Uefi enabled.

[morlock (mor-lock)]

I have the exact same problem. For more information aber the general problem see also http://www.linlap.com/fujitsu_lifebook_ah532

In short: you can get the boot menu back but you need to open the laptop and short two pads. You can then use FreeDOS to flash the "BIOS" (or whatever this is called nowadays).

But I haven't succeeded yet to install Ubuntu in such a way that it doesn't break the Boot menu/"bios" menu (the menus you enter when pressing F2/F12 right after powering on the machine). Is there any way to debug the problem?

[viking777 (viking-f2s)]

I can confirm that the advice given by morlock has returned my bios to working order, though I don't think this marks the bug as solved as it is just a workround and will probably recur if Ubuntu is reinstalled.

The bios contains no settings related to Uefi that I can find (ie I can't switch it off). And YannUbuntu, who kindly read my latest Boot-Repair pastebin report, tells me that Secure Boot is not enabled.

[morlock (mor-lock)]

Btw, This is a quite serious issue!

Anyway, I might have found a workaround that allows you to repair your EFI and boot menu without opening your laptop + the shorting procedure + firmware reinstall with FreeDOS . Buth onestly, I don't want to write everything all over again, so for the details please have a look at http://www.linlap.com/fujitsu_lifebook_ah532?&#comment_c5adb1445ac430630761be90a7eac560 (the comment by moerdock from 2012/11/30 04:00).

Basically, I used nvramtool to do a binary dump of the content of my NVRAM after I had repaired everything. It *might* (again, MIGHT) be possible for other users to write this binary dump to their NVRAM and it just works. I'm not sure, though. Try it at your own risk! If something goes wrong you should be able to fix everything by doing the shorting procedure. But once more: I don't take any responsibility if your machine breaks :)

[morlock (mor-lock)]

Oh, and another thing: the attached archive contains three binary dumps of my NVRAM:

- nvram_working_boot: this was taken right after I had reset the NVRAM.
- nvram_working_boot_and_efi: this was taken after I had reset the NVRAM and "reflashed the EFI menu" from FreeDOS
- nvram_fucked_up: the binary dump of the broken state.

I really hope that someone can debug these dumps. If you need additional information, pleaes tell me and I will try my best to deliver it.

[viking777 (viking-f2s)]

morlock, thank you very much for this work.

I have tried all three of your nvram dumps on my machine and none of them make any difference to its behaviour. In other words f2 settings menu and f12 boot choices continue to be available at all times even when in running your 'nvram_fucked_up' state. So I guess nvram settings are not transferable between machines??

If I manage to break my machine again (which I am sure will happen next time I install/reinstall a distro) I will try my own nvram_backup to repair it before anything else it is certainly easier than shorting motherboards and flashing bioses.

The question that immediately springs to mind is how would you get an nvram_backup on a brand new machine without any linux version installed. Can it be run from a live CD/DVD, if so how, and would it give the same results? This would be an essential part of your 'improved' workround for this problem, but of course users would have to be aware of both the problem and solution before hand, which is not very likely.

The other question that bugs me is, supposing I had chosen to install 'alongside' windows instead of completely replacing it would I have had the same bother?

Sadly I am not prepared to reinstall Windows just to find out.

[morlock (mor-lock)]

Oh my ... please forget the whole NVRAM backup idea for now. It doesn't even work for me anymore. It worked *flawlessly* and *repeteadly* yesterday night (I could just copy the binary dumps around and make nothing work, only the boot menu and both menus). The difference yesterday was that after I had shortened the pads I tried everything consecutively without powering down the machine even once. And back then, the described procedure worked. Sry for the inconvenience.

On the bright side, it is not totally ruled out that this workaround could work for everyone - if I find out the %&%((%& reason why it doesn't work anymore on my laptop...

P.S.: I think it is possible to write a binary dump from a live usb. But for now, it doesn't help much....

[viking777 (viking-f2s)]

That is a shame morlock, it seemed like a much easier solution all round.

Well done for finding it even if it doesn't work!

[viking777 (viking-f2s)]

I am not at all familiar with Uefi workings, so the following comment is neither a solution nor even a theory, simply a question for others that are familiar with Uefi to consider.

I see that in my /boot/efi folder I have the following files:

ls -l /boot/efi/EFI/Microsoft/Boot/
total 480
-rwxr-xr-x 1 root root 122880 Nov 24 12:01 bootmgfw.efi*
-rwxr-xr-x 1 root root 122880 Nov 24 12:01 bootmgfw.efi.grb*
-rwxr-xr-x 1 root root 122880 Nov 24 12:01 bootx64.efi*
-rwxr-xr-x 1 root root 122880 Nov 24 12:01 bootx64.efi.grb*

So the question is why have I got Microsoft files in my /boot/efi folder when I have no Microsoft installation, and could this have any bearing on this bug?

One thing is obvious, the only thing that can have put them there is Ubiquity. Bear in mind that I used the 'Replace Windows' option to install Ubuntu, not 'Install alongside'. Given that, then Ubiquity really has no need to create such files. Obviously dual booters would probably find these files very necessary but not anyone who is completely removing Windows.

The thought springs to mind that these might be some sort of signatures required to implement 'Secure Boot'. But since my machine does not support 'Secure Boot' again they are surely unnecessary. I can't read the files (hex?) so I don't know what is in them.

Anyway it is just something for you to think about, I might be very wide of the mark in believing this has anything to do with the basic problem.

[YannUbuntu (yannubuntu)]

These 4 files were created by Boot-Repair (see http://ubuntuforums.org/showpost.php?p=12379441&postcount=637 ).
I don't think they cause the bug, but to be sure you can delete them, either via command lines or via the Advanced option --> "Restore EFI backups" option of Boot-Repair.

[viking777 (viking-f2s)]

Ah, thank you again YannUbuntu.

That is not the answer then.

[Gabor Kelemen (kelemeng)]

The same thing happened with my new Lifebook AH552SL and Ubuntu 12.04.

[Alex (sahab-alex)]

Fujitsu Lifebook AH552/SL - (x|K)Ubuntu 12.10 - the same shit

[Satish (satishp)]

I concur. This issue is pretty serious.

Unlike viking777, I used 'Something Else' option during partitioning to create different partitions, keeping one for installing Mint later. Little did I know that my Ubuntu install will lock me out of BIOS. Now I can't get my laptop to boot from the Mint DVD.

My Boot-Repair output is here - http://paste.ubuntu.com/5670796/

I tried the 'shorting' trick to get back the option to let me boot from CD/DVD, but it didn't work for me. Maybe I missed something.

I do not have anything important in the laptop yet so I am very open to deleting everything and starting again but I am not sure how to achieve that since I cannot boot from LiveCD or any other OS. Can I use GParted to delete the EFI partition? Would I get back to BIOS then?

I hope I do not end up with a dead system - can't reinstall, can't remove, can't add distros.

-
Satish
Fujitsu Lifebook LH532

[viking777 (viking-f2s)]

Satish the only thing I might add to this is that in my experience, when you do the 'shorting' of the cl1 cl2 pins the machine must have power available, it is no good doing it with the battery removed it wont work, in fact the machine has to be switched on. (see my post dated "2012/11/21 18:38" on this site: http://www.linlap.com/fujitsu_lifebook_ah532 ). I tried it with power removed and absolutely nothing happens. Bear in mind that what I did there is potentially dangerous both to you and the machine. Another thing to try (a lot safer! ) is to remove the cmos battery (if you can find it, I dont know where it is) this has reportedly worked on other machines, but I can't gurantee it will work on the Fujutsu.

In my case I only finally solved this problem when I removed Uefi from the system completely (deleted the Efi System partition). Having done that I had to do my motherboard shorting/bios flashing routine one more time then reinstall everything in 'legacy' mode, after which the problem has gone away for good.

This is a problem with Fujitsu's bios/uefi firmware in my opinion, it is very similar, if not identical to the problem affecting Samsung machines (which seem to have been more widely publicised than this).

I don't know if Matthew Garret's kernel patch will solve this problem for the Fujitsu, but I suspect it will.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=68d929862e29a8b52a7f2f2f86a0600423b093cd

I don't know how widely this patch has been applied just yet, obviously having totally removed Uefi from my machine, and having no desire to ever put it back, I can't test it.

[Satish (satishp)]

Yes, that has been my guess as well. I kept the battery but did not switch the system on. Shall do it the next time I try it.

I looked for the CMOS battery too but I assume Fujitsu soldered it and hid it away. Also the CL1 CL2 pins weren't under the RAM area in my laptop, they were adjacent to it. Ofcourse I would still remove the RAM before shorting but I agree that this is not the way to try and make this work. Fujitsu should fix their BIOS/UEFI soon.
If I ever get back my BIOS, that is the first thing I would do - disable UEFI and install everything in legacy mode. It's a no-brainer now.

I expected to see the firmware's entry in GRUB at the very least; this led me to the /etc/grub.d/30_uefi_firmware shell script. I noticed that the 'efi_vars_dir' points to a location that doesn't exist. It looks for /sys/firmware/efi/vars while in my machine it is /sys/firmware/efi/efivars. It is empty though, so I didn't give it any more thought. But looking at that kernel patch talking about efi vars, I am not so sure now.

[Satish (satishp)]

Some more info in the hope it helps the developers to make sense of this issue:-

I managed to restore the "Boot via CD/DVD" option by shorting the said CL1 and CL2 pins. However this did not restore my BIOS/UEFI firmware access. I was just able to use the 'Boot via CD/DVD' and 'Boot via USB HDD' options. Using the former, I installed Linux Mint 14. Deleted the EFI system partition and installed grub-pc to handle the boot loading process.

Later used the manufacturer's BIOS Flash via FreeDOS to flash my firmware and get back firmware access.

Windows 8.1 preview arrived and I wanted to check it out so went ahead and grabbed the ISO. Since Windows doesn't allow BIOS mode installation on a GPT disk, I had to go for a UEFI mode installation. This went as expected and removed the grub loader. However the firmware access was still there. Installing UEFI Windows just added a 'Windows Boot loader' in the firmware's boot menu and put it on top. I was still able to choose boot via CD or USB.

Put in the Ubuntu Live CD and booted through that to restore access to Ubuntu/Mint. Installed Boot-Repair and used the 'Recommended Repair' approach. Now since there is a EFI System Partition (Windows created this) and UEFI mode OSes (Windows 8.1 and Ubuntu), I guess, Boot-Repair figured out that grub-efi needs to be installed. Followed instructions shown by Boot-Repair and the summary is present here - http://paste.ubuntu.com/5873309/

I was asked to disable 'Secure Boot' from my firmware on restart but as earlier, I lost firmware access again. I guess, grub-efi failed somewhere and I was being taken directly to the grub menu with no way to enter my firmware and switch off Secure Boot.

Since I have a working Windows, I booted into it via grub and flashed my BIOS again to get back firmware access.

I stumbled upon the utility - rEFInd Boot Manager by Roderick W. Smith here - http://www.rodsbooks.com/refind/ and using the instructions for Windows (http://www.rodsbooks.com/refind/installing.html#windows), I installed it and now have a working system with access to all OSes (Windows 8.1, Ubuntu and Mint) along with my BIOS/UEFI firmware access as well (restored via flashing).

When my Windows 8.1 preview expires, I will have some work to do probably but I'll cross that bridge when I come to it.

To Developers:- Just holler if you need me to run any tests or provide more info.

[Phillip Susi (psusi)]

Most likely what is happening is that the EFI boot variables are somehow getting messed up, and your bios is buggy and goes off the deep end when this happens. After installing grub-pc, check dmesg for any EFI related errors, and run sudo efibootmgr and post the output please.

[Satish (satishp)]

Ok.
The dmesg output (searching for EFI) is attached. The following is something I see in the dmesg output.
                    efivars: get_next_variable: status=8000000000000002

For some reason, the 'efibootmgr' command doesn't show any output. It simply returns; I even tried running the Terminal under root and executing it with the same result.

The following is my EFI System Partition (ESP) mounted on /boot/efi

/boot/efi/EFI
                        Boot/bootx64.efi
                        Microsoft/
                                          Boot/
                                                   bootmgfw.efi
                                                   bootmgr.efi
                                                   ...
                        refind/
                                    refind.conf
                                    refind_x64.efi
                                    ...
                        ubuntu/
                                      grub.cfg
                                      grubx64.efi
                                      shimx64.efi

[Phillip Susi (psusi)]

Can you run efibootmgr before trying to install grub-efi ( after getting the system back to a working state ), and make sure that it works correctly at that point, without this error in dmesg? If so, it looks like there may be a bug in the kernel, or at least, a bug in your bios that the kernel might be able to work around.

[Satish (satishp)]

grub-efi isn't installed; there's only grub-pc. No matter what I try, efibootmgr refuses to give me any output.

[Phillip Susi (psusi)]

You need to boot in efi mode to use efibootmgr. In other words, reset your bios to factory defaults, and get it to boot from the install cd in efi mode.

[Launchpad Janitor (janitor)]

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

[Satish (satishp)]

Apologize for the delay..
The efivars error exists even when I have 'efibootmgr' running ok. There was an update that locked out my firmware again. efibootmgr returns nothing (I guess because the boot entry/order setting in NVRAM has been erased and is empty). I created a new entry for refind and efibootmgr returns..

     BootOrder: 0000
     Boot0000* rEFInd

but dmesg still has the error

     [ 0.821512] efivars: get_next_variable: status=8000000000000002

But this does not persist. On reboot, only ubuntu's grub loads (can't get to rEFInd or CD/DVD or anything).

Should this bug be reported against 'efibootmgr'?
On every update of the package, my firmware gets erased. And the only boot entry is the one 'efibootmgr' ran from (in my case, it is either Ubuntu or Elementary).

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1082418

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Satish (satishp)]

ApportVersion: 2.12.5-0ubuntu2.2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: satish 1876 F.... pulseaudio
DistroRelease: Ubuntu 13.10
HibernationDevice: RESUME=UUID=c73dc7d0-4253-44fa-9589-d8c91c9cac13
InstallationDate: Installed on 2013-03-23 (284 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5)
MachineType: FUJITSU LIFEBOOK LH532
MarkForUpload: True
Package: linux 3.11.0.14.15
PackageArchitecture: amd64
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: \boot\vmlinuz-3.11.0-14-generic ro root=UUID=bec9632a-2569-467d-9bfd-c2b291e2f3ec initrd=boot\initrd.img-3.11.0-14-generic
ProcVersionSignature: Ubuntu 3.11.0-14.21-generic 3.11.7
RelatedPackageVersions:
 linux-restricted-modules-3.11.0-14-generic N/A
 linux-backports-modules-3.11.0-14-generic N/A
 linux-firmware 1.116
Tags: saucy
Uname: Linux 3.11.0-14-generic x86_64
UpgradeStatus: Upgraded to saucy on 2013-10-18 (76 days ago)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
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

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[penalvch (penalvch)]

viking777, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

[Satish (satishp)]

Christopher, I can do the test on the latest kernel but not right away. Downloading nearly 1GB of that cdimage would burn out my volume cap and I need it for work. I will give it a shot probably near the end of the month (closer to my volume cap reset date).

[Satish (satishp)]

ApportVersion: 2.13.1-0ubuntu1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: satish 1976 F.... pulseaudio
CurrentDesktop: Unity
DistroRelease: Ubuntu 14.04
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
Package: linux (not installed)
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
ProcVersionSignature: Ubuntu 3.13.0-5.20-generic 3.13.0
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
Tags: trusty
Uname: Linux 3.13.0-5-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
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

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

apport information

[Satish (satishp)]

Christopher, as required, I installed latest build from Ubuntu daily-live/current images and this wiped out my UEFI firmware access. This confirms that the bug exists on the latest kernel too.

[penalvch (penalvch)]

Satish, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[YannUbuntu (yannubuntu)]

@Christopher: see comments #16 and #17 --> the bug affects not only Lifebook AH532 but also AH552

[Launchpad Janitor (janitor)]

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

[penalvch (penalvch)]

Not In Progress as outlined in https://wiki.ubuntu.com/Bugs/Status .

[david6 (andrew-dowden)]

Possible workaround, for 14.10 ..

Quick press 'Power' button, and immediately start repeatedly pressing <Esc> ... (Don't just press and hold.)

[penalvch (penalvch)]

david6, it will help immensely if you filed a new report via a terminal:
ubuntu-bug linux

Please feel free to subscribe me to it.

[aimwin (aimausy)]

I have Lifebook LH532 and for almost 2 years not a problems with EFI boot
(installed ubuntu(&derivertives multi boots) more than 20 times)
until I upgrade 750GB (MSDOS) with new empty 1TB (was formated to MBR-MsDos)
and installed ubuntu 14.04.1 as only OS in 1TB and let ubuntu did that automatically, (1st choice installation)
it made 1TB as GPT and did UEFI installation.

Ubuntu 14.04.1 hacked and blocked firmware Bios,
no more F2 Bios option and F12 boot menu.

Yes I confirm as this bug and
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1273060
-------------------------
I have upgrade ubuntu 14.04.1 installation to 14.10
reboot and try to do what
david6 (andrew-dowden) wrote on 2015-04-13:
said above.
Press <Esc>
produce only to interupt grub boot menu to grub> (grub promt)
So it is not workaround for me at the moment.

david6 please explain details of what your procedures and the end results please.

I have not tried fresh install Ubuntu 14.10
===================

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

Conclusion >>> Don't allow your harddisk to be made to GPT before ubuntu installations.
 if you are not 100% that your BIOS is compatible with Ubuntu GPT-UEFI installation.<<<<,

By forcing your harddisk to be MBR or MSdos format, before Ubuntu installation.
That prevent UBUNTU to be installed in GPT-UEFI that can wreck your Bios.

(And do not allow Ubuntu to install in the first choice, by UBUNTU's ways,
you must select the last option, choose your own ways of installations.)
----------------
I have not flash Bios since mine LifeBook was bought in Thailand and those above links are UK models.
So I did not dare to flash Bios yet.

But I can install the same Ubuntu 14.04.1 many times without wrecking F12 boot menu any longer.

----------------for newbies to ubuntu

So It is the GPT of the harddisk that force Ubuntu to install as UEFI mode and wreck Fujitsu Bios.
It is the "worst bug" (from user point of view) I found on Ubuntu for my life.

Ubuntu GURUs must do somethings.
This give bad names to ubuntu.

The computer technician quote $100 to fix my Bios.
=============

Propose simple problems reductions or preventive solutions (for under 2TB Disk).

1. During Installation, there must be warning message about making harddisk into GPT partition type with
" very prominent LETTERING " that this GPT and UEFI installation could wreck the Bios of your computer.
(Many computer's Bios are not compatible with UBUNTU UEFI installation and result in blocking further use of Bios,
and with samples models Fujitsu and many others.)
"Proceed with your own risk "
or
"Choose to do the MBR and Bios installation option." then safe old days of installations are done.

2. The installation process check the troblesome models of computers
and ju...

[penalvch (penalvch)]

aimwin, it will help immensely if you filed a new report via a terminal:
ubuntu-bug linux

Please feel free to subscribe me to it.

[aimwin (aimausy)]

I have now got MBR 1TB ubuntu installation.
Is it worth to file that "ubuntu-bug linux" ?

Since only the Bios need to be flashed.
And the report would not show the Bios problems, would it shows?
And the F12 Boot Menu is working perfectly now.

My concern for the reporting are,

1. david6's work around is not working for me and I spent 4 hours upgrading that 14.10, so I hope he response with more details.
    So others will not spend their times on the wrong path.

2. My fix and workaround aren't mention anywhere so I hope this will hellp others to at least stop further repeated problems.
Though they may not be able to flash Bios, like me.

3. Make proposal to "ubuntu installation programing team" to imporove user's warning and alternative workaround options.
Please suggest is this the place to voice opinion on this matter.

Thanks.

[aimwin (aimausy)]

If we need to be in GPT-UEFI installation ( that crippled F2 Bios and F12 Boot Menu ) to creat the "ubuntu-bug report",
I would redone it again when I have more free time.
Also I will do the ubuntu-bug report afterward in the MBR 1 TB installation.

So please confirm if that excersise will help the debuging team.
Thanks

[aimwin (aimausy)]

Please let me know what kind of report you need to get from us.
I am sending "ubuntu-bug report" under present MBR 1 TB installation.
https://bugs.launchpad.net/ubuntu/+source/linux-lts-utopic/+bug/1451387

Do you want me to do Ubuntu Installation with GPT-UEFI and file another terminal bug report?

[PsyClip-R (victor-sokyrko)]

I've succeeded to boot gparted from external usb.

just press multiple times right after boot/reboot ESC.
This should throw you to grub console.

Then:

ls
set root=(hd1,msdos2)
chailoader /efi/... (list the content of the drive and find *.efi)
boot

that's gonna load the gparted (or the one you've chosen before

[made on Fujitsu AH532, Linux Mint Rebecca]

[Vegard Bakke (vegard-bakke)]

Is this bug still considered important (amongst the 3500 other bugs in the list)?

I just encountered a slightly different flavour of this one, and can provide some input before I try vikings777's fix.

I've been running pre-installed Windows 7 on a Fujitsu AH532 since 2012.

Two weeks back, I installed a Live-USB with Ubuntu 14.04. All working well, but I struggled getting it persistent, so I decided to do a full Ubuntu installation to another USB-drive. Leaving my Windows hard drive untouched.

1) I entered my "BIOS" to change boot order, and booting from my Ubuntu Live-USB.

2) I followed a installation guide (don't remember now which one on the top of my head), and partitioned my second USB-drive with a BIOS boot partition, an UEFI partition, a main partition and a swap partition.

3) I installed Ubuntu on a second USB-drive. Leaving my Windows hard-drive "intact" (???)

Now, I can only boot my machine by inserting my second full-installation-USB-drive. I cannot boot Windows, and I cannot boot from my LiveUSB.

If I boot without inserting my full-installation-USB-drive, I get the boot screen telling me I can press F2 or F12, none which work, as described by others before me, apart from making the correct beep. Then I enter the "Boot menu" (incl "Application menu").

I even physically removed my Windows hard drive, but the same thing happens.

If anyone has time and interest to look at this, now a tad old issue, let me know what sort of debug reports you want, and I'll try to help.

Cheers,
Vegard

[penalvch (penalvch)]

Vegard Bakke, it will help immensely if you filed a new report via a terminal:
ubuntu-bug linux

Please feel free to subscribe me to it.

[Vegard Bakke (vegard-bakke)]

I have now filed my bug under:

[Vegard Bakke (vegard-bakke)]

I have now filed my bug: https://bugs.launchpad.net/ubuntu/+source/linux-lts-utopic/+bug/1471380 (in case anyone from the future is reading this thread)

[Launchpad Janitor (janitor)]

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

[FG (redirect06)]

Hi,

I own a Fujitsu Lifebook A532 and I have same problem.
I used a HDD with Windows 10 and would try Ubuntu 14.04.
I put a new HDD, download Ubuntu, make a USB bootable and install Ubuntu with default.
All is working.
I decided then to put back my first HDD with Windows and I when I but.. there is Phoenix SecureCore Tiano on the screen, and no F2 or F12 solution !! Menu is asking ubuntu or Diagnostic... What the hell ? I want my Windows back :o) shame on me.
The only solution to make booting my HDD with Windows is to put off BIOS battery.
Then F12 is working but F2 still no longer.
I did not try to play with some pins...

[Jean-Pierre van Riel (jpvr)]

And this bug isn't isolated to just to Fujitsu. The same thing just happened to me with a Dell.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1273060

[Launchpad Janitor (janitor)]

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

[Peter Nerlich (i-peter-h)]

I see this has been changed to expired because of lacking activity, so I just wanted to say hi and that it affects me, too. And I got pretty annoyed by it by now.

[penalvch (penalvch)]

Peter Nerlich, to advise, only stating something affects you is too vague to be actionable, and in turn, helpful.

Hence, it will help immensely if you filed a new report in a live environment with the Ubuntu repository kernel (not mainline/upstream) via a terminal:
ubuntu-bug linux

Please feel free to subscribe me to it.

For more on why this is helpful, please see https://wiki.ubuntu.com/ReportingBugs.

[Launchpad Janitor (janitor)]

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

[Filippo Falezza (effeffe99)]

Actually, this crap happened me many times and I was able to solve after burning a mobo just to figure out what was happening. PLEASE READ EVERYTHING BEFORE DOING ANYTHING!

When the system has not grub installed everything is ok, but after the install efi is destroyed. The only way to solve it is to jumper the two pins under the ram, it will reset cmos and efi. Then you have to create a freedos bootable usb stick with the bios updater on it. Pay attention that 1.x can't be updated to 2.x, so check twice for the exact bios version.
Then flash the bios.

Now reboot the computer. It will automatically check for any bootx64.efi in Boot folder in the efi partition. If you have something there, it will boot it.
In the case you want to reinstall grub you can, but in order to AVOID TO REPEAT EVERYTHING just remove the efibootmgr and efivars packages, without them grub-install won't touch the efi entries.

If you have any questions please ask, maybe i have some news since I am still trying to add a standard entry as i used to have.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Filippo Falezza (effeffe99)]

Solved, I added an entry via windows using an uefi entry manager

[dobey (dobey)]

It's nice that you've managed to find a workaround for yourself @Filippo, but this does not constitute the bug being fixed, nor your working to resolve the fix.

I've set the bug back to Confirmed, as multiple people have experience the issue, as detailed in the above comments.

[Filippo Falezza (effeffe99)]

The real issue is caused by efibootmgr which destroyes the nvram. It has to be fixed

[aimwin (aimausy)]

Dear Fillippo
Do you mean.1.  After we inatalled uefi ubuntu and it destroy Lifebook multi boot function in Bios.2. Instead of opening the Main Board to shorting CL1/CL2 posts, you can retorethe Option of Multiboot of the bios by just adding an entry via windows using an uefi entry manager?
If yes please give us more details. How to do that please. I will try on my notebook.

Sent from Yahoo7 Mail on Android

  On Tue, 17 Apr. 2018 at 2:55 am, Filippo Falezza<email address hidden> wrote: Solved, I added an entry via windows using an uefi entry manager

** Changed in: linux (Ubuntu)
      Status: Confirmed => Fix Released

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1082418

Title:
  [Fujitsu Lifebook AH532] UEFI firmware locks itself after installing
  Ubuntu in UEFI mode

Status in linux package in Ubuntu:
  Fix Released

Bug description:
  lsb_release -rd
  Description:    Ubuntu 12.10
  Release:    12.10

  apt-cache policy grub-efi-amd64
  grub-efi-amd64:
    Installed: 2.00-7ubuntu11
    Candidate: 2.00-7ubuntu11

  Pheonix Secure Core Tiano bios version 1.09

  New laptop Fujitsu Lifebook AH532. Windows 7 preinstalled. All
  functions worked normally when running Win7. Ubuntu 12.10 installed
  using whole disk. Installation successful Ubuntu boots and runs
  normally, however all access to the bios has now been lost. Pressing
  the default key (f2) during boot up is acknowledged by bios beep, but
  ignored and Ubuntu continues booting. In addition the 'boot choices'
  menu (f12) contains nothing but Ubuntu making it impossible to boot
  from USB or CD/DVD.

  The latter (f12) problem was overcome by opening up the machine,
  removing the ram and shorting the cl1/cl2 posts with a screwdriver.
  This restores the ability to boot from USB/CD by pressing f12 but does
  not restore bios access.

  The following recovery actions have been tried.
  1) Install Boot-Repair, run repair, no change occurred. Boot repair report here:
  http://paste.ubuntu.com/1375041/

  2) Restore Windows from Clonezilla disk image (factory settings) -
  result - bios access is no longer possible from windows either, f2 now
  launches the Windows boot menu.

  3) Update all drivers using Fujitsu driver update tool from within
  windows (which included a bios update). Result - no change, no bios.

  4) Restored Ubuntu from Clonezilla disk image - no change.

  5) Added second distro to disk. Installed successfully (uefi mode as
  that is all I have) no change to bios access.

  So overall result I have lost all bios access even from a reinstalled
  Windows. I repeat that bios access was perfectly normal before
  installing Ubuntu.

  I strongly suggest you read the contents of this thread in addition to
  the information here:

  http://ubuntuforums.org/showthread.php?t=2086602

  ProblemType: Bug
  DistroRelease: Ubuntu 12.10
  Package: grub-efi 2.00-7ubuntu11
  ProcVersionSignature: Ubuntu 3.5.0-18.29-generic 3.5.7
  Uname: Linux 3.5.0-18-generic x86_64
  ApportVersion: 2.6.1-0ubuntu6
  Architecture: amd64
  Date: Fri Nov 23 15:50:07 2012
  InstallationDate: Installed on 2012-11-...

[aimwin (aimausy)]

Dear All, especiall UBUNTU Ubiquity team and The Boss (Mr. Mark)

It has been long time since I report this bug.
And so many of us are effected.

Today I have made experiments and have short cl1&cl2 many times again to help UBUNTU community.

I have reformat my SSD and install Windows 10 in UEFI mode, BIOS F12 is preserved 100% perfect.
Then I install 18.04 AND REDONE CL1&CL2 THEN 16.04 UBUNTU AND Lubuntu 18.04.
ALL experimentS UBUNTU all versions destroyed LH532 Bios F12 functions and need to short CL1&CL2 to bring BIOS F12.
BIOS F2 is still dead.

I have AGAIN reformat my SSD and install Windows 10 in UEFI mode, BIOS F12 is preserved 100% perfect.

I INSTALLED Manjaro LINUX in the second half of the non format hard disk.
It resulted in very excellent installation, BIOS F12 is preserved 100% perfect.

THEN I proceed to install UBUNTU 18.04, it is very smart in auto mode, request me to approve 50% re partitioning only for Manjaro Linux and not Windows 10. So I did approved that.
Resulted in :
1. Windows 10 boot ok.
2. UBUNTU 18.04 jealously destroyed access to Manjaro Linux, did Mr Mark order this????
3. It destroyed BIOS F12 and I have to short CL1&CL2 to get my BIOS F12.

SO I would like to confirm here UBUNTU 18.04 UBIQUITY HAS NOT BEEN IMPROVED.
It is worse than 16.04 in detecting existing BIOS LEGACY MODE installation.
And it is still maintain the bugs in destroying host computer BIOS.

BUT MANJARO installation program and Windows 10 works fine.

Something wrong in UBUNTU INSTALLATION PROCESS since 12.04. and no one care to change that.

I hope this existing bugs will destroy MR MARK's NEW NOTEBOOK in the future.
I really hope that.
So he will order the fixing of these bugs.

Best Regards to Everyone.

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