Samsung UEFI Bricking

[ed2975]

Hello,

Following the announcement in the linux mint 14 nadia release notes and the post in the ubuntu bug tracke here (https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557)r and in another blog here (http://mjg59.dreamwidth.org/22855.html) can anyone tell me if this issue has been resolved? I want to use UEFI because I want to keep the OEM windows 8 on my samsung np900x4c-ao6au and do not with to boot in bios mode and have to reformat the file table as MBR. Is it safe to install linux on a samsung laptop to boot in UEFI with GPT partitioning? Perhaps with secureboot disabled?

Any help would be greatly appreciated

Thanks,
Ed

[viking777]

I don't think anybody can tell you that Ed, and anyone that did would be really sticking their necks out a bit.

I can tell you one thing though. You may have to use Uefi in order to use Windows 8, I don't know. I don't use Windows, haven't used it for a long while and I am therefore not qualified to comment on it. But I am definitely qualified to tell you that you do not need Uefi to keep gpt partitioning on Linux, because that is exactly what I now have. Look at this:

Code: Select all

Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system     Name  Flags
 2      99.6MB  27.9GB  27.8GB  ext4
 3      27.9GB  34.2GB  6297MB  linux-swap(v1)
 4      34.2GB  160GB   126GB   ext4
 5      160GB   188GB   27.9GB  ext4
 6      188GB   214GB   26.2GB  ext4
 7      214GB   242GB   27.5GB  ext4

As you can read I have a gpt partition table, and just to prove it I have 6 primary partitions. You can also notice that my partition table starts with partition number 2, that is because partition number 1 used to be my Efi system partition, which I deliberately deleted. You can see that here:

Code: Select all

ls /boot
abi-3.5.0-25-generic         initrd.img-3.5.0-26-generic
abi-3.5.0-26-generic         memtest86+.bin
config-3.5.0-25-generic      memtest86+_multiboot.bin
config-3.5.0-26-generic      System.map-3.5.0-25-generic
extlinux/                    System.map-3.5.0-26-generic
grub/                        vmlinuz-3.5.0-25-generic
grub.bak/                    vmlinuz-3.5.0-26-generic
initrd.img-3.5.0-25-generic

No /boot/efi, it is gone for good.

So on Linux it is definitely possible to live without Uefi (in fact it is preferable) and you do not have to sacrifice gpt in order to do that. However like I said before, I don't have the slightest idea what this will do to Windows 8.

I feel sorry for anyone put into this position, as I have been a victim of it myself, my laptop has been 'bricked' (by which I mean completely unusable) about 6 times before I freed myself from the tyranny of Uefi. The recovery process from that 'bricking' was brutal in the extreme, involving shorting motherboard pins on a live board and repeatedly flashing the bios. It is unacceptable in the extreme that computer users should have to put up with this, but sadly, at the moment, we do.

[srs5694]

Following the announcement in the linux mint 14 nadia release notes and the post in the ubuntu bug tracke here (https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557)r and in another blog here (http://mjg59.dreamwidth.org/22855.html) can anyone tell me if this issue has been resolved? I want to use UEFI because I want to keep the OEM windows 8 on my samsung np900x4c-ao6au and do not with to boot in bios mode and have to reformat the file table as MBR. Is it safe to install linux on a samsung laptop to boot in UEFI with GPT partitioning? Perhaps with secureboot disabled?

First, Secure Boot has nothing to do with the bricking bug; it's triggered by writing too much data to an EFI storage area in NVRAM, and that can happen with or without Secure Boot active. Furthermore, as detailed in the second link you posted, it's not safe to boot Windows in EFI mode on those computers, since it's possible to brick them from Windows by writing enough data to an EFI data store. The same thing is possible in Linux, too. In other words, the OS you use isn't really relevant; the firmware itself is buggy, and the bug can be triggered from any OS.

That said, I've heard a vague report that there may be a second Linux kernel patch that prevents overly-large writes. If this is true, it may be safer to use Linux on these laptops now; but I haven't seen a good and detailed description of what this second patch is, or even that it really exists. (It could be that my source was confused and there's really just the one patch.) Thus, my advice remains what it's been for a while:

• These computer are defective. As such, if possible they should be returned to the store for a refund, and the refund used to purchase another computer.
• If a return is impossible, convert them to boot everything in BIOS mode. This is admittedly a hassle, but it's better than bricking your computer. (This page describes how to convert a BIOS-mode boot of Windows to use EFI instead. The reverse is supposedly achievable, but I don't have a URL handy with step-by-step instructions. You could try adapting the BIOS-to-EFI instructions to go the other way, though.)
• Check with Samsung. They are aware of the problem, and they may release a fixed firmware at some point. If you can't do either of the preceding things, use the computer as little as possible, and preferably only in Windows until Samsung releases an update. (The Windows-only point is to protect yourself; it's conceivable that Samsung will blame Linux and refuse in-warranty repairs should the computer end up bricked.)

[MtnDewManiac]

I gave up and formatted the drive on my buddy's new Samsung laptop and installed Mint as the sole OS.

I read several reports that many of these could be unbricked by unplugging, removing the battery, and then removing the CMOS battery. But even if that's true... I just spent the best part of a day disassembling a (different brand, admittedly) laptop in order to clean accumulated dirt from the three fans and heat-pipe assembly and I had it almost completely disassembled before I could have changed the one in it :yikes: .

I suppose the easiest way for you to tell if your laptop has been corrected is: Have you downloaded any BIOS firmware updates? If so, did the release notes mention that one of the fixes is for this issue? (And, if so, are you willing to trust a company that knowingly ignored a major bug in its computers for years, lol?)

Those aren't really questions we can answer for you.

Good luck,
MDM

[ed2975]

Thanks to all three of you for helping me I really appreciate

You're right about it being an unbelievable hassle, and I really do blame samsung 100% here its clearly a nuclear-grade problem that can happen even with the packaged OEM OS.

Samsung have released a BIOS/EFI update a few days ago, but with no release notes of any kind i'm not game to try it

The only reason I wanted to keep UEFI was to avoid formatting the SDD in this laptop to keep the OEM windows intact, and dual boot with linux mint. I've seen that ubuntu has a EFI boot manager and in theory should be fine, but the risk of a kernel crash writing to that NVRAM space seems to be the trigger that bricks the motherboard. In a perfect world, linux would be all I need, however I need to keep windows for backwards compatibility with programs written only for windows. I may just bite the bullet and reformat and use BIOS (called CSM by samsung) boot only to use a linux only system, and use my tower computer which doesn't put me through this bullshit for windows.

In short though I am seriously disappointed with samsung. This is my hardware I paid for, I should be able to do whatever I like with it without risk of critical failure. Note to all mint forum users: AVOID SAMSUNG SERIES 5,7,9 LAPTOPS UNTIL THIS IS COMPLETELY RESOLVED BY SAMSUNG.

[ed2975]

If a return is impossible, convert them to boot everything in BIOS mode. This is admittedly a hassle, but it's better than bricking your computer. (This page describes how to convert a BIOS-mode boot of Windows to use EFI instead. The reverse is supposedly achievable, but I don't have a URL handy with step-by-step instructions. You could try adapting the BIOS-to-EFI instructions to go the other way, though.)

This made for very interesting reading, and it seems if I understood correctly the UEFI-DUET program process may be able to solve my problem in part allowing an emulated UEFI environment for windows over the base BIOS I will use for linux on the same disk with a single bootloader. However as discussed in the link the process is extremely hit and miss, and again not something I should have to do if this hardware was programmed correctly. Thanks anyway though I may just give it a try.

[MtnDewManiac]

Please forgive a (somewhat) unrelated question, but next time you are in your BIOS menu, could you check the boot options and see if that model of Samsung is able to boot from a USB device? I was rather surprised with my friend's; when I gave up on this issue and removed Windows 8 entirely so as to avoid bricking someone else's laptop, I was going to put Mint on it via USB instead of DVD (already had it "burned" to a flash drive with Unetbootin, figured it would save time and a disc)... But there was no option to boot from USB device. Methinks whoever the "genius" is at Samsung that is in charge of their implementation of the Secure Boot / UEFI stuff thought, "What's the point if someone can just plug in a USB drive with a live OS and use it to read all the data off the laptop's hard drive? So I'll just remove that capability altogether."

Other than that - and the bug that makes using it with Secure Boot / UEFI enabled dangerous - I was reasonably impressed with the laptop that he got and thought he got a decent value for his $500. I figure that they'll get around to fixing the bug in their firmware sooner or later - if they haven't already - but if all of their newer laptops are incapable of booting from USB then I'll go ahead and permanently mark Samsung off my list of brands to mention to people who are shopping for a laptop.

Thank you,
MDM

[viking777]

This inability to boot from usb is in my opinion a function of its problems with Uefi and nothing to do with Samsung as such. I have been living with this for months (until I finally got rid of Uefi - which is the only solution for this type of laptop - again my opinion). The trick FOR ME to restore it was to short the CL1 CL2 motherboard pins which resets the nvram. The procedure is detailed here for MY laptop (see the Notes section): http://www.linlap.com/fujitsu_lifebook_ah532

In all probability, if you can find these pins it will do the same for your Samsung laptop (they probably won't be in the same place as mine are so you will need a motherboard manual - if you can find one). This will almost certainly void your warranty and I will take no responsibility for it going wrong if you decide to try it.

Also I would be most grateful if someone on this thread would add their bios details to this topic
http://forums.linuxmint.com/viewtopic.php?f=49&t=127071

It is designed to try and help others from making the same purchasing mistakes as I did.

[srs5694]

This inability to boot from usb is in my opinion a function of its problems with Uefi and nothing to do with Samsung as such.

No, it's not. I've got four EFI-based computers, and all of them can boot from USB flash drives. I've heard of such problems on some implementations, but it's critical to distinguish between bugs on individual EFIs and general limitations of EFI. This problem definitely falls into the former category, not the latter, as you suggest.

[MtnDewManiac]

This inability to boot from usb is in my opinion a function of its problems with Uefi and nothing to do with Samsung as such.

No, it's not. I've got four EFI-based computers, and all of them can boot from USB flash drives. I've heard of such problems on some implementations, but it's critical to distinguish between bugs on individual EFIs and general limitations of EFI. This problem definitely falls into the former category, not the latter, as you suggest.

With the Samsung laptop that I had a chance to play with (install Mint on), it wasn't a bug - USB simply wasn't an option on the boot list at all. Having seen "a few" laptops in the past six or eight years, all of which had an option to boot from USB, I was thinking that the feature was removed from the Samsungs for a purpose. And the only purpose I could think of was to stop people from bypassing secure boot - and the installed OS - by placing an OS of their choice onto a handy pocketable flash drive, changing a couple of options in the BIOS menu (not caring that Windows 8 or the versions of 7 that can use SB won't then boot, since they won't be booting it anyway), and copying the data from the laptop's hard drive to examine later at their leisure.

This scenario could be avoided, I suppose, by encrypting the hard drive and setting up a password in the BIOS, but few people do, AfaIK, and I didn't see any requirement to do so in order to use the Secure Boot stuff - which seems silly, considering the fact that SB is supposed to provide for a secure boot.

[srs5694]

With the Samsung laptop that I had a chance to play with (install Mint on), it wasn't a bug - USB simply wasn't an option on the boot list at all.

The two aren't necessarily contradictory.

Having seen "a few" laptops in the past six or eight years, all of which had an option to boot from USB, I was thinking that the feature was removed from the Samsungs for a purpose. And the only purpose I could think of was to stop people from bypassing secure boot - and the installed OS - by placing an OS of their choice onto a handy pocketable flash drive, changing a couple of options in the BIOS menu (not caring that Windows 8 or the versions of 7 that can use SB won't then boot, since they won't be booting it anyway), and copying the data from the laptop's hard drive to examine later at their leisure.

First, on x86-64 computers, it's normally possible to disalbe Secure Boot, and in fact Microsoft requires manufacturers to provide an option to disable Secure Boot. Second, when enabled, Secure Boot normally applies to all bootable devices, including USB flash drives. Thus, disabling the ability to boot from a USB medium wouldn't serve any useful purpose vis-a-vis Secure Boot, since there are other ways to "get around" Secure Boot and since the feature normally applies to external media, too. Furthermore, disabling the ability to boot from a USB medium limits disaster recovery options, even with a bootable Windows-based medium. Thus, there's no benefit to be gained and considerable drawback to doing this deliberately.

It's also not clear why a manufacturer would want to prevent users from "copying the data from the laptop's hard drive," unless you're talking about DRM type measures -- but Secure Boot has little or nothing to do with DRM.

Overall, if a computer lacks an obvious way to enable an external boot medium, two explanations spring to mind:

• Poor user interface -- It could be that the option exists but is not obvious in the user interface. It might be necessary to enable BIOS/CSM/legacy-mode booting before booting a BIOS-mode medium, for instance; or there might be an option outside of the "boot" menu to enable USB devices. (The latter is the case with my ASUS motherboard, for instance.)
• A bug --EFI is a complex system, and the user interfaces layered atop it are very new. This combination means that bugs are not just likely, they're a certainty. Thus, Hanlon's razor applies: "Never attribute to malice that which is adequately explained by stupidity."

Either of these is a far more likely explanation than a conspiracy to prevent users from booting legitimate OSes.

[MtnDewManiac]

With the Samsung laptop that I had a chance to play with (install Mint on), it wasn't a bug - USB simply wasn't an option on the boot list at all.

The two aren't necessarily contradictory.

True.

First, on x86-64 computers, it's normally possible to disalbe Secure Boot, and in fact Microsoft requires manufacturers to provide an option to disable Secure Boot.

Yes, I know. The only real reason that I can think of that would account for that is that Microsoft is wary of an antitrust action. Otherwise, they might possibly convince the hardware manufacturers to make it mandatory, permanent, 100% of the time - and then it would actually serve its stated purpose.

Second, when enabled, Secure Boot normally applies to all bootable devices, including USB flash drives.

I hadn't even considered that.

Thus, disabling the ability to boot from a USB medium wouldn't serve any useful purpose vis-a-vis Secure Boot, since there are other ways to "get around" Secure Boot and since the feature normally applies to external media, too.

I see what you mean; with the current poor implementation of Secure boot - allowing anyone to walk by and disable it within seconds of powering the computer on (if it is not password-protected) - it is starting to seem completely pointless, as far as its stated purpose goes.

Furthermore, disabling the ability to boot from a USB medium limits disaster recovery options, even with a bootable Windows-based medium. Thus, there's no benefit to be gained and considerable drawback to doing this deliberately.

Yes, I agree with you. My own failing laptop has a DVD/CD reader/writer, but it hasn't functioned properly since a few days after I bought the thing when I attempted to use it to create "recovery" media. If not for the fact that it allows me to boot from USB, I would have never been able to install its first linux OS one it and, if the hard drive would have failed, it would have been useless unless I could have somehow pre-installed an OS onto the replacement hard drive (possibly along with initial BIOS settings, since I think it stores them on the drive (not positive)).

It's also not clear why a manufacturer would want to prevent users from "copying the data from the laptop's hard drive," unless you're talking about DRM type measures -- but Secure Boot has little or nothing to do with DRM.

Respectfully, that comment leads me to believe that you must have led a very sheltered life up to this point to still have such wonderful naivety .

If by "users," you actually meant "owners," then, no, I suppose not. But I did not use the term "owner" (or "user," either). Perhaps I wasn't being entirely clear when I, instead, used the generic "people." I apologize for that.

But as for why it might be a good thing to offer some protection against people who aren't the owner of the computer in question to access/copy/change data on the hard drive... Some people use their computer for work-related purposes, often even laptops while at work. I would hazard a guess that not every one of them takes that laptop wherever es goes, even to the toilet. Especially since many of them have a Kensington Security Slot to which a cable can be locked to provide a modicum of protection against actual physical theft. Some people might even go to lunch occasionally without taking their laptop with them (and, I would assume, [/i]usually[/i], if their computer happens to be a desktop ). They might even, for whatever reason, leave the computer at work when they leave for the day. In all of those possible situations - to one degree or another - a person with nefarious goals in mind might wish to either harvest that computer's stored data (to see what a coworker is doing in regards to a project that they are both competing on, to sell the information to a competing business (or to give it to said business, if the person is employed by it), to pass along sensitive information to another country, et cetera). If a person is not using the computer for business purposes, es might - probably does - still have private information such as various website account names/passwords, email account information (and emails), information that might be useful to a person that wished to access their bank account(s), credit card information, a copy of their electronically-filed tax returns, et cetera. A person who is not as pure as the driven snow might steal the computer, or the owner might inadvertently leave it somewhere; there have even been cases of people's children looking for - and finding - credit card information in order to make purchases that they were not allowed to. And there would be like possibilities why it would be to those dishonest person's advantage to install things such as keyloggers, "phone-home" apps, et cetera.

Oddly, I read a blog by a Microsoft employ which stated that the purpose of Secure Boot was no 'compromises on security" and another Microsoft post which stated that was supposed to protect the computer during the pre-boot environment. <SCRATCHES HEAD> If all it takes - on a computer which has this stuff but which has not disabled booting from a USB or other external device - is for someone to place the OS of their choice onto a USB flash drive, insert it, power up the computer, press the button(s) to enter the BIOS/CMOS menu, change a setting or two (well, three if one counts changing the boot priority of the devices), and exit in order to access the data (all of that having been done in the "pre-boot environment," lol)... Then I would say that Microsoft's goal of accomplishing their stated purpose is a definite [/FAIL].

Overall, if a computer lacks an obvious way to enable an external boot medium, two explanations spring to mind:

• Poor user interface -- It could be that the option exists but is not obvious in the user interface. It might be necessary to enable BIOS/CSM/legacy-mode booting before booting a BIOS-mode medium, for instance; or there might be an option outside of the "boot" menu to enable USB devices. (The latter is the case with my ASUS motherboard, for instance.)
• A bug --EFI is a complex system, and the user interfaces layered atop it are very new. This combination means that bugs are not just likely, they're a certainty. Thus, Hanlon's razor applies: "Never attribute to malice that which is adequately explained by stupidity."

You discount the possibility of the manufacturer either not including external-booting or including a prohibition on same in the specifications given to whichever Chinese company builds the motherboards because your two scenarios are the only "obvious" possibilities ?

BtW, I distinctly remember not stating that this lack of external booting capability was due to malice.

Either of these is a far more likely explanation than a conspiracy to prevent users from booting legitimate OSes.

Quite positive I did not use the term, "conspiracy," either. (Again) respectfully, while I cannot control what you think after reading my words, please do not infer that I used entirely different ones. At best, it increases the possibility that others might also misunderstand them; and, at worst, it might cause some people to think I am a bit of an @ss when I have to explain this basic thing. With the open nature of Internet forums, such behavior can turn minor misunderstandings between two people into greater misunderstandings amongst a considerably larger number of them.

Have a good evening (/morning/afternoon, whichever the case may be),
MDM

[srs5694]

with the current poor implementation of Secure boot - allowing anyone to walk by and disable it within seconds of powering the computer on (if it is not password-protected) - it is starting to seem completely pointless, as far as its stated purpose goes.

No, it's just that its stated purpose isn't what you believe it to be. Secure Boot is not intended as the be-all and end-all security measure, nor is it intended to protect against data theft or threats posed by individuals who have physical access to the computer. It protects the computer against some forms of attack, and specifically, it protects against boot kits that a user might unwittingly install.

It's also not clear why a manufacturer would want to prevent users from "copying the data from the laptop's hard drive," unless you're talking about DRM type measures -- but Secure Boot has little or nothing to do with DRM.

Some people use their computer for work-related purposes, often even laptops while at work.

(Etc.) You're talking about reasons that users or employers might want to protect against unauthorized copying of data. Those reasons don't apply to manufacturers of computer hardware. Granted, a manufacturer might want to give users tools to manage such things, but that's not the same as the manufacturer being motivated to put obstacles in a user's path. I stand by my earlier comment.

[MtnDewManiac]

Okay, I kind of see your point, now.

So this Secure Boot thing isn't meant to completely protect the end-user or their data, only against their own foolhardy actions, such as clicking on one of those "Gee, I was on Facebook and I saw this picture of you in a very compromising position, you should click this link to check it out" (I actually saw that one show up in my inbox once, lol), downloading and installing "cracked" software (I guess that's a Microsoft Windows thing) which may have extra, err... features added by the miscreant who cracked it, visiting websites of questionable reputation, or any one of the numerous things that common-sense tells us all never to do, but which many people seem to fall for each and every year. Things that could allow rootkits and the like to be installed and placed into action during the boot process. But not to actually secure the boot from every threat.

In that regard, Secure Boot makes much more sense. As does the fact that it doesn't seem capable of protecting things from anyone who actually has physical access to the computer.

My confusion about Secure Boot was, perhaps, furthered by reading the comments (that I mentioned in my previous post) on two separate Microsoft employees' official Microsoft blogs. I assumed that a company - especially one as large as Microsoft - would vet its employees' comments, at least the ones that it allows to be posted for public view on a Microsoft site and that, therefore, all of the comments would be... "fully defensible by legal," IOW, true/factual and not false and/or an exaggeration. In short, I took them at face value. I'm afraid that seems to be somewhat of a failing of mine; when one tries to speak plainly, and has been raised to do so from childhood, one also has a tendency to assume that others are doing the same unless/until one sees evidence to the contrary.

Thank you for clearing that up.

In the future - whether it is right or wrong - whenever I hear/read the term "Secure Boot," I'll just think of it as simply another form of virus/malware protection.

Best regards,
MDM

[osvega]

I just bought this laptop: Samsung NP350E5C-A07IT.

The version of the bios is P04ABE, the only bootable device shown is called "WINDOWS BOOT MANAGER (P0: STBLABLABLA500MBB)", it has FASTBIOS, SECUREBOOT (and consequently UEFI) enabled.

How lucky: it shoud be one of those nice brickable laptop ticking right under my hands!

There are 6 allocated partitions: 3 for recovery, 1 for EFI, a M$ reserved plus C:.

After having disabled FASTBIOS and SECUREBOOT, a subsequent menu with the UEFI status revealed, I select CSM MODE option instead of UEFI OS (the third being UEFI & LEGACY OS).

Linux Mint 14 (cinnamon) DVD now boots (despite the fact that no TSSCORP DVD nor other USB device shows under the bootable device BIOS section) letting me check that all of the hardware work nicely under linux.

But Windows 8 doesn't, nor the recovery.

Trying to revert the changed settings to ENABLED, makes the M$ os and recovery work again (so I could shrink the C: partition from 431Gb to 100Gb).

Subsequently, bringing them back to DISABLED lets me run again the Mint LiveDVD, fiddling a bit and writing this post.

I suppose I can't reinstall the Win8 OS as no install DVD was shipped with the package and the Samsung Recovery Backup program under Win8 always interrupts with a 1200 error even if the Factory Recovery Backup to an external HDD works, albeit painfully slow, but DVD install media isn't _allowed_ with both the Samsung and the Windows Backup programs.

So, could the summary be so far:
if you don't have win8 install dvds, no dual boot is possible at the moment on this laptop: disabling the above mentioned BIOS options so to avoid bricking this other than this nice piece of hardware and installing linux (writing a CSM boot sector on the disk) will permantly render the preinstalled windows and recovery partitions not bootable forever.
?

[steveking]

This is a very interesting topic as I too have recently bought myself a nice shiny new Samsung Laptop and was wandering where the progress may be?

I have scoured the internet after reading horror story after horror story I am unsure of how to continue with this. I initially bought the laptop and said that I would "test" Windows 8 out let it have its chance (it is only fair). But after having the laptop for about a month now I am already sick and tired of this horrible metro look and Windows in general!

Is there any definative ways to install Linux onto these devices? I can boot from a live CD quite happily if I set my BIOS to "UEFI OS and Legacy OS" which seems to suggest that I could quite happily install it and leave it in that mode? Obviously leaving it in that mode and trying to boot back to Windows 8 does not work, but if I were to get rid of the Windows 8 completely then i do not see the problem? Also With Samsung Laptops and the UEFI boot the Recovery Manager takes up 10Gb of storage! This could be 10Gb of valuable stored to use!!

So without rambling on tooo much I was posing the question of "Has anybody managed this yet? If so how?"

Cheers
Steve

[srs5694]

I just bought this laptop: Samsung NP350E5C-A07IT.

(Much snippage.)

First, see this page for some pointers on how to obtain or create a legal and bootable Windows 8 installation/recovery medium. I don't have Windows 8 myself, so I can't vouch for any of the methods or sources described there or say what will work, but you can try them yourself, and with any luck you can find something that will enable you to install Windows 8 in BIOS mode. That's definitely the safest way to go, although it's also likely to be the most tedious in the short term.

Second, a patch to the Linux kernel has recently been created that works around the bricking problem. This patch limits the amount of data that Linux can write to the NVRAM, which is the fundamental cause of the problem, as opposed to an earlier patch that simply prevented loading a Samsung-specific driver that had the effect of triggering such a write. I don't know if Mint has yet updated any of its kernels to include this patch, though, so I'd be wary of installing or using Mint in EFI mode unless/until you hear that this new patch has been applied. Also, this patch won't protect the computer from bricking itself in Windows.

If you're willing to risk continued booting of Windows in EFI mode, you could do this:

1. Perform a BIOS/CSM/legacy-mode installation of Linux.
2. In Windows, install rEFInd, which is an EFI-mode boot loader. (Windows installation instructions appear on the rEFInd Web site.)
3. Edit the refind.conf file: Uncomment the "scanfor" line and add "hdbios" to the list of options.
4. Configure the system to boot in EFI mode, but leave the BIOS/CSM/legacy option enabled or set to "auto". (Details vary depending on your firmware; you may need to fiddle with these options.)

The result should be that when you power up, rEFInd will start up and show at least two boot options: One to boot Windows in EFI mode and another to boot a generic BIOS-mode boot loader. The latter will start GRUB, which will in turn launch Linux in BIOS mode. If/when the problem is fixed in the firmware or you're sure you've got a kernel that works around the problem, you can add an EFI filesystem driver for ext4fs, create a /boot/refind_linux.conf file, and remove the "hdbios" option to boot Linux in EFI mode.

This procedure is not guaranteed to work, though; rEFInd's ability to launch a BIOS-mode boot loader varies from one firmware to another. On some it just won't work. Unfortunately, the only way to know if you're in this boat is to try. You may also have problems getting rEFInd to start; unfortunately, some EFIs are buggy and are hard to configure to boot non-Windows boot loaders, and some manufacturers do weird things with their boot loader configurations that further complicate matters. Again, you'll just have to try and cope with the problems if they arise.

[ed2975]

Its nice to see I'm not alone with this problem. Samsung putting unstable firmware on their laptops is the operative factor in this being such a critical bug, and so getting them to address this should be made a top priority for them. I have complained and received the standard boiler-plate response so I doubt it got any attention, but maybe if enough people write to them explaining how annoying and unacceptable this firmware bug is maybe they will realise the commercial liability of seriously upset customers and address it properly. 333 people have looked at this so far; 333 emails would make quite a dint.

[JaZZyCooL]

Hey does it matter whether I install on Linux or Windows 8, it will work the same right?

[srs5694]

Its nice to see I'm not alone with this problem. Samsung putting unstable firmware on their laptops is the operative factor in this being such a critical bug, and so getting them to address this should be made a top priority for them. I have complained and received the standard boiler-plate response so I doubt it got any attention, but maybe if enough people write to them explaining how annoying and unacceptable this firmware bug is maybe they will realise the commercial liability of seriously upset customers and address it properly. 333 people have looked at this so far; 333 emails would make quite a dint.

What will really catch their attention is people returning computers because they're buggy. Complaints cost them little money (although customers writing bad reviews because of the bug might cost them some). Returns hit them in the pocketbook, and that's the best way to attract the attention of a corporation.

Hey does it matter whether I install on Linux or Windows 8, it will work the same right?

If by "it" you mean rEFInd, then in theory you can install it from either OS; however, installing it from Linux requires either installing in BIOS mode and using a hack to get it to launch at startup; or installing in EFI mode, which requires booting in EFI mode, which is risky given the nature of the bug, unless you're certain you're using a kernel that includes at least the first bug fix.