Booting Linux using UEFI can brick Samsung laptops

nomorewindows · 2013-03-03 14:43:10

65kid wrote:

I reset the BIOS settings by unplugging the CMOS battery. Unfortunately this didn't restore access to the BIOS Setup. Even more unfortunately: SecureBoot is now enabled again and booting from USB is disabled by default. And I can't change either of those things since I can't get into the BIOS.
In other words, I can't boot anything now which means the machine is basically bricked....

Maybe you can boot with the Arch iso CD?

65kid · 2013-03-03 15:07:20

I don't have an internal drive and, as mentioned, USB doesn't work either. I can't do anything, the machine is useless right now, I'm gonna have to send it in.

srs5694 · 2013-03-03 18:46:39

65kid wrote:

I don't have an internal drive and, as mentioned, USB doesn't work either. I can't do anything, the machine is useless right now, I'm gonna have to send it in.

A shot-in-the-dark suggestion: Try unplugging the hard disk and booting with no hard disk (or perhaps with a completely empty hard disk). Maybe that will "wake up" the firmware and enable you to get into its settings screen to disable Secure Boot or do whatever else you need to do.

nomorewindows · 2013-03-03 23:45:18

srs5694 wrote:

65kid wrote:
I don't have an internal drive and, as mentioned, USB doesn't work either. I can't do anything, the machine is useless right now, I'm gonna have to send it in.
A shot-in-the-dark suggestion: Try unplugging the hard disk and booting with no hard disk (or perhaps with a completely empty hard disk). Maybe that will "wake up" the firmware and enable you to get into its settings screen to disable Secure Boot or do whatever else you need to do.

That will most likely force it into the PXE mode I was talking about, but if PXE is disabled maybe not even that. Still requires a separate machine with the complete bells and whistles. I have tried arch's PXE boot/install and it takes awhile because it practically downloads the whole CD over the internet to your machine and boots from it.

Last edited by nomorewindows (2013-03-03 23:46:59)

65kid · 2013-03-04 11:00:46

I'm not even sure if the machine is capable of PXE, even if it was, I would have had to go into the BIOS Setup to activate it. I didn't try the "unplug-hard-disk" idea, but I doubt that it would have helped. Something is seriously broken directly in the firmware. I already talked to the Samsung support and sent the machine in for repair. Thanks anyway for your ideas.

nomorewindows · 2013-03-04 12:54:08

65kid wrote:

I'm not even sure if the machine is capable of PXE, even if it was, I would have had to go into the BIOS Setup to activate it. I didn't try the "unplug-hard-disk" idea, but I doubt that it would have helped. Something is seriously broken directly in the firmware. I already talked to the Samsung support and sent the machine in for repair. Thanks anyway for your ideas.

PXE is a PC98 standard I think it was. But taking the hard drive out to activate it is mutually exclusive. Your boot selection menu should have it.

65kid · 2013-03-10 15:03:28

I just got a private mail from someone who ran into the same problem. Just for clarification, I don't think there is any way to fix this yourself by restoring the entry somehow. I sent the machine in for repairs last monday and got it back yesterday, they replaced the motherboard. There has been a BIOS update, but I have no idea if this particular issue has been fixed (and I'm not gonna try it out for obvious reasons). I will just have to make sure to not use efibootmgr with kernel 3.8 or higher.

srs5694 · 2013-03-10 17:40:31

65kid wrote:

There has been a BIOS update, but I have no idea if this particular issue has been fixed (and I'm not gonna try it out for obvious reasons). I will just have to make sure to not use efibootmgr with kernel 3.8 or higher.

As I understand it, more recent kernels have a workaround that prevents the most common source of bricking, but I don't recall the precise kernel version that incorporates this fix. In any event, if you must boot a Samsung in EFI mode, using the most recent kernel makes sense, and using an older kernel is precisely the wrong thing to do. Although efibootmgr can add data to the NVRAM, it's not necessarily a big threat. Actions like "efibootmgr -v" simply read the data, and the "-o" option changes data; neither is likely to cause problems.

That said, though, running a Samsung laptop in EFI mode is risky, since programs other than efibootmgr can cause NVRAM writes. The kernel is one of these; with certain configurations, a kernel panic will cause an NVRAM write, and this can brick the computer. Thus, once again:

Currently and AFAIK, the only way to be sure you won't brick a Samsung laptop because of this bug is to run in BIOS/CSM/legacy mode!

65kid · 2013-03-10 18:16:46

a funny thing just happened: I bricked it again (kind of)
good news is, I now know what causes this. It is actually not the fault of efibootmgr.
Look at the output of efibootmgr before I installed gummiboot:

BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0003,0004,0005,0006,0007
Boot0000  Setup	
Boot0001  Boot Menu	
Boot0002  Recovery	
Boot0003* SATA HDD:	030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f600
Boot0004* USB CD:	030a2400d23878bc820f604d8316c068ee79d25b86701296aa5a7848b66cd49dd3ba6a55
Boot0005* USB FDD:	030a2400d23878bc820f604d8316c068ee79d25b6ff015a28830b543a8b8641009461e49
Boot0006* USB HDD:	030a2400d23878bc820f604d8316c068ee79d25b33e821aaaf33bc4789bd419f88c50803
Boot0007* NETWORK:	030a2400d23878bc820f604d8316c068ee79d25b78a84aaf2b2afc4ea79cf5cc8f3d3803

now after I ran "gummiboot install".

BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0003,0004,0005,0006,0007
Boot0000* Linux Boot Manager	HD(1,800,64000,f043edfc-c863-40a9-813f-4743204f0ba4)File(\EFI\gummiboot\gummibootx64.efi)
Boot0001  Boot Menu	
Boot0002  Recovery	
Boot0003* SATA HDD:	030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f600
Boot0004* USB CD:	030a2400d23878bc820f604d8316c068ee79d25b86701296aa5a7848b66cd49dd3ba6a55
Boot0005* USB FDD:	030a2400d23878bc820f604d8316c068ee79d25b6ff015a28830b543a8b8641009461e49
Boot0006* USB HDD:	030a2400d23878bc820f604d8316c068ee79d25b33e821aaaf33bc4789bd419f88c50803
Boot0007* NETWORK:	030a2400d23878bc820f604d8316c068ee79d25b78a84aaf2b2afc4ea79cf5cc8f3d3803

That's right, gummiboot doesn't install itself on top of the list, it replaces the item on top of the list... and that just happens to be the BIOS Setup....
The lucky thing is, the latest gummiboot gives me the option to "Reboot into Firmware Interface" which still allows me to get into the BIOS setup, so I'm not as screwed as before. But getting into the BIOS via F2 is still broken.

Now while this is obviously still Samsung's fault, the question is whether there is also a bug in the gummiboot installer in that it replaces the entry instead of adding it. I will at least file an Arch Linux bug so gummiboot doesn't hit [extra] and more people will (kind of) brick their machines. Then I'm gonna have a look into gummiboot...

god damn you samsung...

edit: bug report here: https://bugs.archlinux.org/task/34248

Last edited by 65kid (2013-03-10 18:31:14)

stas · 2013-03-10 18:24:30

Hi,
I have a similar issue with the unreachable BIOS Setup.
I think my mistake was to use Intel's UEFI Shell and isse something like this "bcfg add 0 fsi:/..." Instead of adding a new parameter, it kinda replaced it.
I think I found a possible solution to this. Some guy[0] reported that he had a similar issue and got it fixed by using Windows 8.

>>In Windows 8 go to Charms menu, Settings, Change PC settings, General, Advanced start-up, Restart, Restart now, Troubleshoot Advanced options, UEFI firmware settings, restart.
>>Voilá, BIOS settings menu appears!

[0] http://forum.notebookreview.com/samsung … ost9042125

65kid · 2013-03-10 18:39:37

stas wrote:

Hi,
I have a similar issue with the unreachable BIOS Setup.
I think my mistake was to use Intel's UEFI Shell and isse something like this "bcfg add 0 fsi:/..." Instead of adding a new parameter, it kinda replaced it.
I think I found a possible solution to this. Some guy[0] reported that he had a similar issue and got it fixed by using Windows 8.
>>In Windows 8 go to Charms menu, Settings, Change PC settings, General, Advanced start-up, Restart, Restart now, Troubleshoot Advanced options, UEFI firmware settings, restart.
>>Voilá, BIOS settings menu appears!
[0] http://forum.notebookreview.com/samsung … ost9042125

(stas is the one I wrote before via mail as I mentioned)

this is still just a workaround, what if you can't boot Windows? I can still use gummiboots' "Reboot into Firmware" option for now, but if I pull the CMOS battery as I did last time, the machine would still be completely bricked again. Samsung has to fix their buggy firmware.

65kid · 2013-03-10 18:58:22

ok, I found a way to actually fix this.
Before I did any modification of the EFI firmware I made a complete backup of /sys/firmware/efi/, turns out this was a good idea because all I had to do now was:

cat efibackup/vars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c/raw_var > /sys/firmware/efi/vars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c/raw_var

voila, Setup Entry restored!

@stas: I could give you this file, but this is binary data and I don't know if it is be machine specific. This may not work on your machine or it may even break stuff even more, I don't know...

stas · 2013-03-10 19:58:10

please send it to me, I try to dig into it and try it by chance

stas · 2013-03-10 20:37:02

the raw format of the efi vars are dumps off the "struct efi_variable" structure in the kernel. A diff of the "hexdum -C" of 65kid's version and my broken Setup version showed some minor changes with the ASCII codes Setup in it. I backed up my version and cat 65kid's version over mine. Afterwards I booted into an UEFI Shell and recreated my OS boot entry with:
bcfg boot add 9 fs:\efi\arch\grubx64.efi "Arch Linux"

and BAM, it works again:
[stas@cassiopeia] [~]
% sudo efibootmgr -v
BootCurrent: 0001
Timeout: 10 seconds
BootOrder: 0001,0005,0006,0004,0003,0007
Boot0000 Setup
Boot0001* Arch Linux ACPI(a0341d0,0)PCI(1f,2)ATAPI(0,0,0)HD(1,800,76800,17f26548-194f-40dd-85a0-14b6e3f0251f)File(\EFI\arch\grubx64.efi)
Boot0002* Recovery
Boot0003* SATA HDD: 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f600
Boot0004* USB CD: 030a2400d23878bc820f604d8316c068ee79d25b86701296aa5a7848b66cd49dd3ba6a55
Boot0005* USB FDD: 030a2400d23878bc820f604d8316c068ee79d25b6ff015a28830b543a8b8641009461e49
Boot0006* USB HDD: 030a2400d23878bc820f604d8316c068ee79d25b33e821aaaf33bc4789bd419f88c50803
Boot0007 NETWORK: 030a2400d23878bc820f604d8316c068ee79d25b78a84aaf2b2afc4ea79cf5cc8f3d3803

Now I just need a working samsung-laptop module and this series 9 gem is perfect.
Thanks 65kid for not having me sending back my laptop

nomorewindows · 2013-03-10 21:20:19

stas wrote:

the raw format of the efi vars are dumps off the "struct efi_variable" structure in the kernel. A diff of the "hexdum -C" of 65kid's version and my broken Setup version showed some minor changes with the ASCII codes Setup in it. I backed up my version and cat 65kid's version over mine. Afterwards I booted into an UEFI Shell and recreated my OS boot entry with:
bcfg boot add 9 fs:\efi\arch\grubx64.efi "Arch Linux"
and BAM, it works again:
[stas@cassiopeia] [~]
% sudo efibootmgr -v
BootCurrent: 0001
Timeout: 10 seconds
BootOrder: 0001,0005,0006,0004,0003,0007
Boot0000 Setup
Boot0001* Arch Linux ACPI(a0341d0,0)PCI(1f,2)ATAPI(0,0,0)HD(1,800,76800,17f26548-194f-40dd-85a0-14b6e3f0251f)File(\EFI\arch\grubx64.efi)
Boot0002* Recovery
Boot0003* SATA HDD: 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f600
Boot0004* USB CD: 030a2400d23878bc820f604d8316c068ee79d25b86701296aa5a7848b66cd49dd3ba6a55
Boot0005* USB FDD: 030a2400d23878bc820f604d8316c068ee79d25b6ff015a28830b543a8b8641009461e49
Boot0006* USB HDD: 030a2400d23878bc820f604d8316c068ee79d25b33e821aaaf33bc4789bd419f88c50803
Boot0007 NETWORK: 030a2400d23878bc820f604d8316c068ee79d25b78a84aaf2b2afc4ea79cf5cc8f3d3803

Now I just need a working samsung-laptop module and this series 9 gem is perfect.
Thanks 65kid for not having me sending back my laptop

Don't forget to * the Network entry and the Setup entry, it might come in handy. Or at least have it in the boot order.
What's with all the UUID? I have to know some magic number to start this wonder ful device. It all looks like a goback to NTLDR and BOOT.INI, at least for the Arch Linux entry.

Kraken · 2013-03-11 00:37:14

Hi there,

I kinda want to buy this computer (because mine has 6 years and something) but I'm a bit confused with the UEFI, GPT thing. First, the motherboard that comes with this computer is a UEFI motherboard right? So I have been reading this thread and my intention is to use Bios Compatible Mode because I don't want to brick my new laptop. If I choose the Bios Compatible Mode what procedure should I need to do??? I have been reading the wiki but I kinda became confused with so much information :x. I want to erase all partitions that come with this laptop and then create new ones (for example: root and home partitions), the idea is to use cgdisk /dev/sda and the create them. But should I create a special partition, such as /boot/ to use grub2?!?! If so should I do it first, and then create root and home partitions?

I read so much alerts about the bricking that I'm a bit afraid on doing something wrong. So my point is, should I create a /boot/efi/ (even using Bios Compatible Mode - CMS only) or use some GPT config...

PS: My idea is just to use Arch on this laptop

Thank you for your time..

Best Regards

Last edited by Kraken (2013-03-11 00:39:05)

WonderWoofy · 2013-03-11 06:00:47

So I just bricked my ThinkPad in a remarkably similar string of events here.

I wanted to install Debian to my third unused SSD in my computer (the mSATA that runs @ SATA II). So I booted the installer, totally forgetting about binary firmware blobs that I need. I shut it down (hard poweroff) and began to boot into Arch. It stopped with the LVM2 thing which was weird because it hadn't done that in a while.

But this time instead of activating the volume, I got a sweet kernel panic! But there were only a few lines of output which looked really weird.

I did another hard poweroff, and upon "reboot" it wouldn't go. I get no POST, no nothing. Actually that is a lie, the fan spins as though it is going to turn on and the red "ThinkLight" comes on.

At first I thought it was the screen only, so I tried plugging into an external monitor... still nothing. I tried hitting F1 during/after the fan spins to see if I can get the setup beep. I tried giving it a while and then trying to run things (with sound) blindly. I tried anything/everything I can think of with no luck.

I have arranged for warranty repair, but I just thought I would grow this experience out there. Not sure if it is related... and I have no way to potentially diagnose either.

I guess I will find out in a week what they end up doing to the machine... I will report back.

I have taken out all my drives and miscellaneous stuffs I added... I am going to check out my drives to make surenthey are not corrupted. Though I am not sure what would have corrupted them, as far as those are concerned the last time they were actually being used by something it was a clean shutdown/unmount. The Debian installer didn't make it to a stage of doing anything with then (I don't think), and the failed bootup was unable to find the LVM. So they shouldn't have been touched since last real use.

This post was painful on my nexus 7.

65kid · 2013-03-11 12:15:50

Kraken wrote:

I kinda want to buy this computer

Well, I personally wouldn't because Samsung screwed up big time here. If you missed it a few pages before, there isn't just the buggy EFI firmware but also the fact that CPU features (AES-NI) are disabled for no reason whatsoever and Samsung doesn't even care to explain why.

Kraken wrote:

First, the motherboard that comes with this computer is a UEFI motherboard right? So I have been reading this thread and my intention is to use Bios Compatible Mode because I don't want to brick my new laptop. If I choose the Bios Compatible Mode what procedure should I need to do??? I have been reading the wiki but I kinda became confused with so much information :x. I want to erase all partitions that come with this laptop and then create new ones (for example: root and home partitions), the idea is to use cgdisk /dev/sda and the create them. But should I create a special partition, such as /boot/ to use grub2?!?! If so should I do it first, and then create root and home partitions?
I read so much alerts about the bricking that I'm a bit afraid on doing something wrong. So my point is, should I create a /boot/efi/ (even using Bios Compatible Mode - CMS only) or use some GPT config...

Disable UEFI boot in the BIOS Setup and you should be on the safe side. Using GPT is still fine, it's more modern than MBR. Using a separate /boot is not strictly necessary if you use CSM boot but is imho always a good idea, it might come in handy later if you want to use a more complex setup (encryption, LVM, RAID etc.).

WonderWoofy · 2013-03-11 15:30:16

65kid wrote:

Well, I personally wouldn't because Samsung screwed up big time here. If you missed it a few pages before, there isn't just the buggy EFI firmware but also the fact that CPU features (AES-NI) are disabled for no reason whatsoever and Samsung doesn't even care to explain why

I have actually seen reports of this on numerous Thinkpads as well with a BIOS update recently. It effected numerous models, and so far there hasnt been a crappy explanation, there has been no explanation from Lenovo.

So yes Samsung might have some buggy firmware, but unless you get something like a chromebook with coreboot, you are going to have bugs and whatnot simple because this part of the machine is closed source bullshit.

So while i understand why you condone avoidance of Samsung ATM, I just feel like you are kind of risking potentially bad firmware no matter where your decision may land... in other words, don't mislead this guy into thinking bad firmware and poor responses are Samsung specific.

nomorewindows · 2013-03-11 15:41:20

SecureBoot isn't the only reason to stay away from UEFI.

WonderWoofy · 2013-03-11 15:45:22

nomorewindows wrote:

SecureBoot isn't the only reason to stay away from UEFI.

SecureBoot might have been scary when it was first announced, but as long as there is a way to turn it off and the community has found ways of getting around that limitation, I think the continued proclamation that it is a reason to boycott UEFI is just simply spreading FUD at thus point.

srs5694 · 2013-03-11 16:53:02

WonderWoofy wrote:

So I just bricked my ThinkPad in a remarkably similar string of events here.

That's painful -- and disturbing. It's conceivable that this is an unrelated problem, or a coincidence (your board just happened to die after a kernel panic), but it's also conceivable that Samsung's EFI shares a common bug with the EFI in your ThinkPad. This is a possibility because all EFIs are derived from the same source code, and only a handful of companies (AMI, Insyde, etc.) make the variants used by all manufacturers. Thus, a bug may have crept in that affects multiple systems, and was just noticed first on Samsungs.

My recommendation is that you contact Matthew J. Garrett, who seems to be the Linux community's leading figure on low-level EFI interactions. He's got a blog at http://mjg59.dreamwidth.org, and this post, in particular, is relevant. He might be able to investigate further; based on his posts, he seems to be able to acquire hardware for testing.

WonderWoofy · 2013-03-11 21:12:56

Rod, that probably is a good idea, as it is probably best if notification is made even if it is a false alarm.

I was thinking about it a bit, and the Samsung thing apparently happens in a fully booted system and is related to a partickar kernel module. Well in my case I think that since it occurred before the partitions were mouted (or could even be found) means that no kernel modules would have been loaded... particularly the thinkpad_acpi module.

So I am questioning whether or not this is even potentially a related incident. TBH though I don't know enough about the inner workings of the BIOS/UEFI to really make any kind of truly informed judgement call on that though. All I know is that my computer was happily running very well and then ceased to run immediately after a kernel panic. But the computer is only about six months old (Lenovo reports ~170 days left of a one year warranty) and showed no obvious signs of malfunctioning.

Anyway, we'll see what they say, and I will contact Matthew Garrett and see what he says also.

srs5694 · 2013-03-11 22:13:02

WonderWoofy, be aware that the Samsung kernel driver is just one way to trigger the real bug. The real problem seems to be writing too much data into the NVRAM storage space. (Please read Matthew Garrett's blog post on the subject for details.) The Samsung kernel driver causes the kernel to do this because the driver triggers a kernel error; but the same thing can happen because of the action of userspace programs or because of other kernel-related problems. The fact that your problem occurred following a kernel panic is what triggered alarm bells for me -- when this happens, the kernel may write data to the NVRAM storage space, which (on a Samsung) can cause a bricking. This is also one of the reasons I keep advising people to not run these Samsungs in EFI mode -- although Linux is pretty reliable, kernel panics can occur, and when one does, NVRAM may be written, and that can cause a bricking. Avoiding specific programs (including the Samsung kernel driver) just avoids certain avenues to a bricking; it doesn't fix the problem or guarantee that you won't run into the problem.

WonderWoofy · 2013-03-12 04:50:18

Those are good points you make srs5694, I actually have read the post and understood previously that tthere are other ways of triggering this. I just have been pondering over the plausibility of that having happened with my system, and that last post of mine was the result.

I am not really sure if this has anything to do with it or not, but the keenly panic I got was the funkiest looking kernel panic I have ever seen. It was all of 7-10 lines and appeared to be somewhat jumbled. I am not sure if this is s result of it just not having been fully booted into userspace or not (it happened while still in the initrd), or if that could potentially mean that the output was diverted somewhere else like the nvram.

In any case, I appreciate your concern with its additional effect of ensuring that my thoughts/suspicions aren't totally crazy.

Arch Linux

#51 2013-03-03 14:43:10

Re: Booting Linux using UEFI can brick Samsung laptops

#52 2013-03-03 15:07:20

Re: Booting Linux using UEFI can brick Samsung laptops

#53 2013-03-03 18:46:39

Re: Booting Linux using UEFI can brick Samsung laptops

#54 2013-03-03 23:45:18

Re: Booting Linux using UEFI can brick Samsung laptops

#55 2013-03-04 11:00:46

Re: Booting Linux using UEFI can brick Samsung laptops

#56 2013-03-04 12:54:08

Re: Booting Linux using UEFI can brick Samsung laptops

#57 2013-03-10 15:03:28

Re: Booting Linux using UEFI can brick Samsung laptops

#58 2013-03-10 17:40:31

Re: Booting Linux using UEFI can brick Samsung laptops

#59 2013-03-10 18:16:46

Re: Booting Linux using UEFI can brick Samsung laptops

#60 2013-03-10 18:24:30

Re: Booting Linux using UEFI can brick Samsung laptops

#61 2013-03-10 18:39:37

Re: Booting Linux using UEFI can brick Samsung laptops

#62 2013-03-10 18:58:22

Re: Booting Linux using UEFI can brick Samsung laptops

#63 2013-03-10 19:58:10

Re: Booting Linux using UEFI can brick Samsung laptops

#64 2013-03-10 20:37:02

Re: Booting Linux using UEFI can brick Samsung laptops

#65 2013-03-10 21:20:19

Re: Booting Linux using UEFI can brick Samsung laptops

#66 2013-03-11 00:37:14

Re: Booting Linux using UEFI can brick Samsung laptops

#67 2013-03-11 06:00:47

Re: Booting Linux using UEFI can brick Samsung laptops

#68 2013-03-11 12:15:50

Re: Booting Linux using UEFI can brick Samsung laptops

#69 2013-03-11 15:30:16

Re: Booting Linux using UEFI can brick Samsung laptops

#70 2013-03-11 15:41:20

Re: Booting Linux using UEFI can brick Samsung laptops

#71 2013-03-11 15:45:22

Re: Booting Linux using UEFI can brick Samsung laptops

#72 2013-03-11 16:53:02

Re: Booting Linux using UEFI can brick Samsung laptops

#73 2013-03-11 21:12:56

Re: Booting Linux using UEFI can brick Samsung laptops

#74 2013-03-11 22:13:02

Re: Booting Linux using UEFI can brick Samsung laptops

#75 2013-03-12 04:50:18

Re: Booting Linux using UEFI can brick Samsung laptops

Board footer