Ubuntu

[Fujitsu Lifebook AH532 & AH552] Ubuntu UEFI install locks out UEFI firmware (~bios) access

Reported by viking777 on 2012-11-23
40
This bug affects 6 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
High
Unassigned

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

viking777 (viking-f2s) wrote :
Launchpad Janitor (janitor) wrote :

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

Changed in grub2 (Ubuntu):
status: New → Confirmed
YannUbuntu (yannubuntu) on 2012-11-23
summary: - New Uefi install locks out bios accessd
+ Ubuntu Uefi install locks out bios access

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) wrote :

> 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) wrote :

@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) wrote :

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) wrote :

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) wrote :

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) wrote :

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.

YannUbuntu (yannubuntu) on 2012-11-30
summary: - Ubuntu Uefi install locks out bios access
+ Ubuntu UEFI install locks out UEFI firmware (~bios) access

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

Ah, thank you again YannUbuntu.

That is not the answer then.

Gabor Kelemen (kelemeng) wrote :

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

Alex (sahab-alex) wrote :

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

no longer affects: ubiquity
Satish (satishp) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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.

Changed in grub2 (Ubuntu):
status: Confirmed → Incomplete
Satish (satishp) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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

Changed in grub2 (Ubuntu):
status: Incomplete → Expired
Satish (satishp) wrote :

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

Phillip Susi (psusi) on 2014-01-02
affects: grub2 (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
status: Expired → New

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.

Changed in linux (Ubuntu):
status: New → Incomplete

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

tags: added: apport-collected saucy

apport information

apport information

Satish (satishp) wrote : CRDA.txt

apport information

apport information

apport information

apport information

Satish (satishp) wrote : Lspci.txt

apport information

Satish (satishp) wrote : Lsusb.txt

apport information

apport information

apport information

apport information

apport information

apport information

Satish (satishp) wrote : RfKill.txt

apport information

Satish (satishp) wrote : UdevDb.txt

apport information

Satish (satishp) wrote : UdevLog.txt

apport information

apport information

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Changed in linux (Ubuntu):
importance: Undecided → High
tags: added: needs-kernel-logs
tags: removed: apport-collected saucy

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>

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Satish (satishp) wrote :

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

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

tags: added: apport-collected trusty

apport information

apport information

Satish (satishp) wrote : CRDA.txt

apport information

apport information

apport information

Satish (satishp) wrote : Lspci.txt

apport information

Satish (satishp) wrote : Lsusb.txt

apport information

apport information

apport information

apport information

apport information

apport information

Satish (satishp) wrote : RfKill.txt

apport information

Satish (satishp) wrote : UdevDb.txt

apport information

Satish (satishp) wrote : UdevLog.txt

apport information

apport information

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.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed

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

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
tags: removed: apport-collected trusty
summary: - Ubuntu UEFI install locks out UEFI firmware (~bios) access
+ [Fujitsu Lifebook AH532] Ubuntu UEFI install locks out UEFI firmware
+ (~bios) access

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

Launchpad Janitor (janitor) wrote :

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

Changed in linux (Ubuntu):
status: Incomplete → Expired
summary: - [Fujitsu Lifebook AH532] Ubuntu UEFI install locks out UEFI firmware
- (~bios) access
+ [Fujitsu Lifebook AH532 & AH552] Ubuntu UEFI install locks out UEFI
+ firmware (~bios) access
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers