2014-05-23T09:22:06ZFluxBBhttps://bbs.archlinux.org/viewtopic.php?id=157196The offending module, samsung_laptop, has been removed. If you read through the thread, there is apparently still a risk but I have been UEFI booting from that time and have not had any issues once I blacklisted the module (which is now not necessary, of course).]]>https://bbs.archlinux.org/profile.php?id=255792014-05-23T09:22:06Zhttps://bbs.archlinux.org/viewtopic.php?pid=1418390#p1418390I'm looking at getting an early 2013 Samsung Series 9.Like SSTC I'm wondering if this problem is now solved, either by kernel workarounds or Samsung fixes.I've read about a number of Ubuntu users installing in UEFI mode without problems now, but I've got no idea what magic might be in use that I might not think of doing myself with Arch.]]>https://bbs.archlinux.org/profile.php?id=800812014-05-23T09:19:10Zhttps://bbs.archlinux.org/viewtopic.php?pid=1418388#p1418388I consider to buy a Samsung ATIV Book 9 Plus, is this still a problem with Samsung, could not find any updates on the problem]]>https://bbs.archlinux.org/profile.php?id=267092014-04-17T00:14:52Zhttps://bbs.archlinux.org/viewtopic.php?pid=1405458#p1405458Any way to recover bios setup entry without needing windows or booting in UEFI mode?

Because I setup the bios to boot in CMOS mode, so I can't use the gummiboot to reboot in firmware now.

I have a Samsung laptop.

]]>https://bbs.archlinux.org/profile.php?id=153962013-04-02T21:51:50Zhttps://bbs.archlinux.org/viewtopic.php?pid=1253297#p1253297This is what I thought, but I wasn't entirely sure. Though I am not sure why then Matthew Garrett would be telling me that there the newest mainline kernel and stable kernels should have this fix... not sure what to think. For now, I am still using UEFI simply because I still have warranty left on my computer. So for now I am at least covered by that. When that expires in late July, I think I might go back to bios booting unless there is some drastically better solution that comes around.

Thanks for your input srs5694, its always nice to be able to converse with a real expert.

He also told me that in the most recent mainline kernel there is a patch to fix this (though I had thought that it was applied earlier)

The earlier "fix" turned out to only fix one path to the bricking bug -- namely, a Samsung kernel module that could trigger the real bug in the firmware. Other ways to trigger the bricking behavior exist. If the kernel developers have patched this more generally (say, by blocking all writes that they know cause problems), then that would be a new and improved fix.

]]>https://bbs.archlinux.org/profile.php?id=654902013-03-18T18:24:31Zhttps://bbs.archlinux.org/viewtopic.php?pid=1245790#p1245790Since I poted about this earlier in the thread, I thought I should follow up.

I got my laptop back from Lenovo on Thursday. The report/work order indicates that they did indeed have to replace the motherboard. Although this does not confirm my suspicions of the UEFI bug, it does not deny them either.

I contacted Matthew Garrett as sugested by Rod above, and his repsonse was that he had gotten a few reports similar to mine, and that it was not totally unlikely that this may have occurred. He also told me that in the most recent mainline kernel there is a patch to fix this (though I had thought that it was applied earlier) which should also be included in the the most recent stable kernels as well. This confused me a bit, as I am in fact using (and was when this occurred) graysky's linux-ck-ivybridge kernel which was 3.8.2 at the time.

So all is now well, though the new bios is a windows 8 bios. So although the post is very fast, I have not been able to find anyone with the knowledge of how to remove the whitelist from these specific bioses, so I am back to using the realtek wireless my computer came with (though it seems there have been vast improvements on the rtl8192ce module since I last used it).

One more totally OT note. I have seem so many complaints about Lenovo's customer service, so I just want to throw this out there. My experience was amazing. They overnighted me a box on Monday, so Tuesday morning I packed my computer up and shipped it that same day. They then got it on Wednesday, and were able to fix it fast enough that it was again shipped the same day. So I got it back Thursday morning! That is less tie than when I had to take my old MacBook 2,1 to the apple store and have the mobo replaced (it took about a full week which still seemed okay)

nice, thanks. just compiled from git, seems to work fine, now it adds itself add the bottom of the list but the boot order still makes sure it is started first. So was this a bug in gummiboot itself after all or is this new behaviour considered a workaround? I thought this was only the firmware's fault. Either way, good to see this fixed.

This seems to be a fault in gummiboot setup code. I just had a conversation with Kay Sievers over irc about this.

nice, thanks. just compiled from git, seems to work fine, now it adds itself add the bottom of the list but the boot order still makes sure it is started first. So was this a bug in gummiboot itself after all or is this new behaviour considered a workaround? I thought this was only the firmware's fault. Either way, good to see this fixed.

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:

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

]]>https://bbs.archlinux.org/profile.php?id=529022013-03-16T18:11:08Zhttps://bbs.archlinux.org/viewtopic.php?pid=1244917#p1244917Those 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.

]]>https://bbs.archlinux.org/profile.php?id=603122013-03-12T04:50:18Zhttps://bbs.archlinux.org/viewtopic.php?pid=1243068#p1243068WonderWoofy, 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.]]>https://bbs.archlinux.org/profile.php?id=654902013-03-11T22:13:02Zhttps://bbs.archlinux.org/viewtopic.php?pid=1242972#p1242972Rod, 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.

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.

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.