3 ms·

I don't have any technical sources for this bug, but I'm quite certain it would be a bug in either the UEFI firmware or the kernel driver. Firmware can be quite

I don't have any technical sources for this bug, but I'm quite certain it would be a bug in either the UEFI firmware or the kernel driver. Firmware can be quite complicated pieces of software, and if you accidentally change the wrong memory values, you might trigger a firmware update or change configurations of the hardware present in the firmware. All this stuff can be changed because it needs to be configurable, and doing it in software is much cheaper. There will usually be some kind of firmware reset in the hardware, but it might involve processes that only the manufacturer can do. I would say C's memory model can contribute towards this because if you have a buffer overflow, or change the wrong bits of memory, you might accidentally change the code, or execute data. Executing data is why buffer overflows are so serious, and allow malicious code to essentially do anything.

bd_at_rivenhill 14y ago
Seems like the best solution is that there should always be a way to reset the firmware to a hard-coded factory default which represents the state that existed when the machine came off the assembly line. In this way, a bad firmware update can always be rolled back. EDIT: looks like somebody reporting the bug did this the old-fashioned way: "Just to add, on UEFI machines that got bricked like this I removed the battery and disconnected the CMOS NVRAM battery and this restored the machine to the factory default and fixed the issue for me."
- entropy_ 14y ago
  With various laptops I've owned over the years, this almost always fixes the problem when the laptop refuses to boot(except when there's actual hardware failure). It's usually pretty straightforward to do too.
- donrhummy 14y ago
  It appears he didn't do that with a Samsung laptop but other machines in the past and someone replied saying it didn't fix it for them: https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557/comments/24 https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557/comme...

bd_at_rivenhill 14y ago

Seems like the best solution is that there should always be a way to reset the firmware to a hard-coded factory default which represents the state that existed when the machine came off the assembly line. In this way, a bad firmware update can always be rolled back. EDIT: looks like somebody reporting the bug did this the old-fashioned way: "Just to add, on UEFI machines that got bricked like this I removed the battery and disconnected the CMOS NVRAM battery and this restored the machine to the factory default and fixed the issue for me."

entropy_ 14y ago
With various laptops I've owned over the years, this almost always fixes the problem when the laptop refuses to boot(except when there's actual hardware failure). It's usually pretty straightforward to do too.
donrhummy 14y ago
It appears he didn't do that with a Samsung laptop but other machines in the past and someone replied saying it didn't fix it for them: https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557/comments/24 https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557/comme...