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.
]]>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.
]]>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)
]]>the.ridikulus.rat wrote:This has been fixed by upstream in http://cgit.freedesktop.org/gummiboot/c … 432dd9cdff (part of gummiboot v28 release). Please test it.
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.
Also another issue in gummiboot "Configuration files in \loader\entries\*.conf are needed." (in some systems, mostly Asus ones) is fixed in http://cgit.freedesktop.org/gummiboot/c … e43456b9e2 .
]]>This has been fixed by upstream in http://cgit.freedesktop.org/gummiboot/c … 432dd9cdff (part of gummiboot v28 release). Please test it.
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: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
This has been fixed by upstream in http://cgit.freedesktop.org/gummiboot/c … 432dd9cdff (part of gummiboot v28 release). Please test it.
]]>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.
]]>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 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.
]]>