I saw this article: Booting Linux using UEFI can brick Samsung laptops - The H Open: News and Features
I have a few questions:
How do I find out if the laptop I have ( 900X4C-A01 - OVERVIEW | SAMSUNG ) has UEFI? I can’t seem to find that info.
If it does have UEFI, is it possible to remove/disable this? The article states that disabling secure boot is not enough.
Does this mean openSUSE could not be installed on a Samsung UEFI device?
Additional question:
This laptop doesn’t have a DVD/CD drive. I’ve read that disabling UEFI means you cannot boot from USB, is this true? If so, how would I install openSUSE?
Here’s Greg Kroah Hartman’s (kernel-developper) post on G+ on it:
Hm, who would have thought that just randomly poking memory of a laptop would brick it. Long ago Samsung told me that it was just fine to be doing this, and that there would not be any problems (I based the samsung-laptop driver on code that Samsung themselves gave me.)
Turns out, it wasn’t true, which is sad. Yes, the real solution is to fix the BIOS. If you have this hardware, just blacklist the samsung-laptop driver and all should be fine.
Update:
I just tested this on a 900X3D Samsung, running latest version of Ubuntu, and no problem happened at all.
So I don’t know what is happening here to the people who are reporting problems, very strange…
Thanks but how do I blacklist the samsung module without first booting in to openSUSE (which could brick it)?
Have a look in your BIOS settings.
It will say how to get there in the user manual.
In the BIOS on this laptop, when selecting legacy (uefi/legacy)
it enables a separate boot order listing which includes
It will list what is available for your hardware.
Thanks, I’ll try that. I’m still a little scared to install anything on this but I don’t want to use Windows.
Looking at this, is there a chance it’s only Ubuntu? Or is it Linux in general?
https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557?comments=all
Scary stuff!
My installation process is described below. However, the nature of this bug is such that you should consider very carefully if you still want to attempt installation of 64-bit Ubuntu on your Samsung laptop. If something does not work for you the way it should, your motherboard may be permanently damaged and your laptop may get bricked. For this reason, this bug should have been flagged “nuclear” rather than “critical”.
Any idea if this is a risk for openSUSE installs?
Does anyone here know Jos Poortvliet? I read that he installed openSUSE 12.2 on a Samsung laptop and wanted to hear his take on this.
On Wed, 30 Jan 2013 22:16:01 +0000, 6tr6tr wrote:
> Any idea if this is a risk for openSUSE installs?
I would assume it is until someone specifically says it isn’t or has been
fixed/addressed.
> Does anyone here know Jos Poortvliet? I read that he installed openSUSE
> 12.2 on a Samsung laptop and wanted to hear his take on this.
Jos is active on the openSUSE mailing lists - usually -project, but I
think I remember seeing him on -user as well.
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
On 01/30/2013 06:03 PM, Jim Henderson wrote:
> On Wed, 30 Jan 2013 22:16:01 +0000, 6tr6tr wrote:
>
>> Any idea if this is a risk for openSUSE installs?
>
> I would assume it is until someone specifically says it isn’t or has been
> fixed/addressed.
From what I read, this is a kernel problem. In addition, GregKH’s comment
indicates that kernels as far back as 3.0 are affected. On that basis, openSUSE
versions 12.1 and 12.2 are affected, as well as 12.3 Beta1. By the time 12.3 is
released, it will be fixed.
Samsung certainly deserves blame for this. Why would they write a BIOS that can
do this kind of damage when an incorrect value is written to some location? In
addition, they apparently lied to Greg.
On Thu, 31 Jan 2013 00:26:37 +0000, Larry Finger wrote:
> On 01/30/2013 06:03 PM, Jim Henderson wrote:
>> On Wed, 30 Jan 2013 22:16:01 +0000, 6tr6tr wrote:
>>
>>> Any idea if this is a risk for openSUSE installs?
>>
>> I would assume it is until someone specifically says it isn’t or has
>> been fixed/addressed.
>
> From what I read, this is a kernel problem. In addition, GregKH’s
> comment
> indicates that kernels as far back as 3.0 are affected. On that basis,
> openSUSE versions 12.1 and 12.2 are affected, as well as 12.3 Beta1. By
> the time 12.3 is released, it will be fixed.
That’s good to know.
> Samsung certainly deserves blame for this. Why would they write a BIOS
> that can do this kind of damage when an incorrect value is written to
> some location? In addition, they apparently lied to Greg.
IMHO saying they lied is a bit strong - but I don’t know the whole
story. Maybe the wrong person at Samsung was involved in the
conversation, maybe something was miscommunicated - I’m usually one to
give the benefit of the doubt until malice is clear. But again, I wasn’t
there, so I don’t know all the facts. 
There are, though, plenty of examples where proper bounds checking isn’t
done and damage is caused as a result. I can remember some old Compaq
RAID controllers that could be toasted if they were flashed improperly
(by which, IIRC, “properly” was either “from a specific undocumented
version” or “not at all because the firmware was broken”). In that
instance, I don’t think Compaq intentionally created a firmware update
that could trash a SMART controller intentionally.
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
On 01/30/2013 06:36 PM, Jim Henderson wrote:
> There are, though, plenty of examples where proper bounds checking isn’t
> done and damage is caused as a result. I can remember some old Compaq
> RAID controllers that could be toasted if they were flashed improperly
> (by which, IIRC, “properly” was either “from a specific undocumented
> version” or “not at all because the firmware was broken”). In that
> instance, I don’t think Compaq intentionally created a firmware update
> that could trash a SMART controller intentionally.
Certainly there are many opportunities to brick a device when firmware updating
goes wrong, but remember that in that case you have explicitly enabled writes to
locations that are normally read only. In the Samsung case, the device is being
bricked by writing the wrong value to a read/write register, or by writing to
the wrong register. That is a very different case, and Samsung’s BIOS coders
should have prevented that.
Does anyone know if this also occurs with the 3.5 kernel or just 3.6 and 3.7?
Jos Poortvliet (from openSUSE) has an article about his install of opensuse with samsung-laptop and UEFI: all mine!: Linux and the Samsung Series 9 NP900X3C He has zero issues with booting but he’s on the 3.5 kernel. So it made me wonder if the issue isn’t just samsung-laptop but maybe something between that and a change to the kernel?
On Thu, 31 Jan 2013 02:45:44 +0000, Larry Finger wrote:
> On 01/30/2013 06:36 PM, Jim Henderson wrote:
>
>> There are, though, plenty of examples where proper bounds checking
>> isn’t done and damage is caused as a result. I can remember some old
>> Compaq RAID controllers that could be toasted if they were flashed
>> improperly (by which, IIRC, “properly” was either “from a specific
>> undocumented version” or “not at all because the firmware was broken”).
>> In that instance, I don’t think Compaq intentionally created a
>> firmware update that could trash a SMART controller intentionally.
>
> Certainly there are many opportunities to brick a device when firmware
> updating goes wrong, but remember that in that case you have explicitly
> enabled writes to locations that are normally read only. In the Samsung
> case, the device is being bricked by writing the wrong value to a
> read/write register, or by writing to the wrong register. That is a very
> different case, and Samsung’s BIOS coders should have prevented that.
Should have, yeah - but we all make mistakes, even occasionally
boneheaded ones.
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
Certainly there are many opportunities to brick a device when firmware updating
goes wrong, but remember that in that case you have explicitly enabled writes to
locations that are normally read only. In the Samsung case, the device is being
bricked by writing the wrong value to a read/write register, or by writing to
the wrong register. That is a very different case, and Samsung’s BIOS coders
should have prevented that.
That’s more a case of being negligent than being malign. Mistakes happen, and what is done to resolve it from a customer perspective that is important. AFAIU, firmware updates have followed, although that doesn’t help those that have already bricked their computers.
Someone told me that if I install openSUSE 12.2 it won’t be a problem because it doesn’t support UEFI. Is this true?
It was also suggested that I install without changing any UEFI settings. Will that even work if openSUSE 12.2 doesn’t support UEFI?
Does mean I can just install it or do I need to do somethings like disable fastboot and enable CSM?
No, it is not. 12.2 does support UEFI.
Personally I would not do it unless I was firmly convinced I could return the machine if it bricks
Best idea sell it on eBay and buy a machine that does not have these problems. It is a clear that these machines have a defective design. No way should any software short of a BIOS upgrade be able to brick the machine.
It won’t be long before some evil person writes a Windows virus that bricks Samsung Laps
Thanks, I wasn’t sure.