On 2014-10-11 03:56, nrickert wrote:
> More of a puzzle, is that a system with BIOS password would allow a BIOS
> update without giving the password. This seems a basic mistake. What’s
> the use of a BIOS password, if the BIOS firmware can be replaced?
Good point…
But the flashing is typically done via some disk from some operating
system. It has control.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2014-10-11 04:36, gogalthorp wrote:
>
>>
>> So some vendors find it easier to switch to defaults.
>>
>>
>
> Lazy you push the setting to a safe lactation flash the BIOS then
> restore the settings. This is not rocket science.
And where would they be? 
There is no storage space in BIOS, specially so if it is being flashed.
It could be on disk… but read ahead.
The “data” is a binary array. In order to migrate it, the updater need
to know the actual data internal structure of the bios that is currently
installed, and copy it to another structure in disk or ram, in his own way.
Then, after the new bios is flashed, it has to read the variables of the
old bios, and store each one on the new and different location of the
new bios.
Notice that it really needs to know the structure of the original data,
the size and location of each setting variable, and do so for every
possible kind of previous bios versions. If it does a mistake, the
machine could be bricked. As this is not feasible, it would have to
first identify with absolute certainty that it knows the previous bios
version, by some kind of signature database. If it matches a known one,
then it may retrieve its data.
But if the programmers do some mistake in retrieving that data, wrong
layout, the translated settings will be rubbish and brick the machine,
or set it in fire. Given the reliability track record of bios
programmers, would you do that?
I wouldn’t. So… flash and reset it all.
What I do not understand is how the password was not reset.
> I write database programs If I ever cleared the settings on a clients
> machine on making an update I’d be out of buisness
That’s high level language, with self-documented structures. Databases
can be read by about any version code, because the databases itself
describe their internal data structure in the header. That is, looking
at the file headers you know exactly how the data is structured in it.
This is assembler code / C low level programming, bios or embedded
machines. Different beast…
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On Sat 11 Oct 2014 11:18:08 AM CDT, Carlos E. R. wrote:
On 2014-10-11 03:56, nrickert wrote:
> More of a puzzle, is that a system with BIOS password would allow a
> BIOS update without giving the password. This seems a basic
> mistake. What’s the use of a BIOS password, if the BIOS firmware can
> be replaced?
Good point…
But the flashing is typically done via some disk from some operating
system. It has control.
Hi
One of the bonuses of using UEFI, my HP ProBooks you can plug in a
usb device with the HP data efi file structure press win+b keys then
power on for recovery or updating.
–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
openSUSE 13.1 (Bottle) (x86_64) GNOME 3.10.1 Kernel 3.11.10-21-desktop
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
On 2014-10-11 16:41, malcolmlewis wrote:
> On Sat 11 Oct 2014 11:18:08 AM CDT, Carlos E. R. wrote:
>> But the flashing is typically done via some disk from some operating
>> system. It has control.
> Hi
> One of the bonuses of using UEFI, my HP ProBooks you can plug in a
> usb device with the HP data efi file structure press win+b keys then
> power on for recovery or updating.
Nice. Certainly. But not all machines have that, do they?
I hope that it asks for your password, or any passerby can flash your
machine.
Idea: could vish_99 revert to an older bios version? Would that help?
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On Sat 11 Oct 2014 04:43:06 PM CDT, Carlos E. R. wrote:
On 2014-10-11 16:41, malcolmlewis wrote:
> On Sat 11 Oct 2014 11:18:08 AM CDT, Carlos E. R. wrote:>> But the flashing is typically done via some disk from some operating
>> system. It has control.
> Hi
> One of the bonuses of using UEFI, my HP ProBooks you can plug in a
> usb device with the HP data efi file structure press win+b keys then
> power on for recovery or updating.
Nice. Certainly. But not all machines have that, do they?
I hope that it asks for your password, or any passerby can flash your
machine.
Idea: could vish_99 revert to an older bios version? Would that help?
Hi
It’s in the manual…?
–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
openSUSE 13.1 (Bottle) (x86_64) GNOME 3.10.1 Kernel 3.11.10-21-desktop
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
read settings to a memory array flash the BIOS restore the settings. Nothing needs to be fancy. If the guys doing these patches can’t figure that out god help us all LOL
On 2014-10-11 18:55, malcolmlewis wrote:
> Hi
> It’s in the manual…?
> http://www.manualslib.com/manual/440323/Acer-Aspire-V3-571g.html?page=64
>
WOW! What a site! Service manuals! What a treasure! :-)))
Well, not all manuals are there. I don’t see MSI, for instance.
But many…
Oh, yes, MSI is there. “Search” finds them.
But not my board, P45 Diamond series, MS-7516 (v1.X) Mainboard. Aka
G52-75161X1.
And for free…
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2014-10-11 19:36, gogalthorp wrote:
>
> read settings to a memory array flash the BIOS restore the settings.
> Nothing needs to be fancy. If the guys doing these patches can’t figure
> that out god help us all LOL
No, not that simple.
Assume, for instance, that the previous bios has settings like these
(invented):
memory type: 2 bytes
memory size: 4 bytes
memory speed: 2 bytes
model: 6 bytes.
All that the updater knows is that the data config area is 8 bytes. It
doesn’t know what is stored, how or where. The new bios may be, instead:
model: 4 bytes.
memory type: 1 byte
memory brand: 1 byte
memory size: 4 bytes
memory speed: 4 bytes
and that’s all it knows. It is impossible to carry over the old
settings, unless you absolutely know the data layout of the previous
bios - and there may be many variants: assume the wrong one, and you may
brick or even destroy the computer.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Come now I deal with change of data structure all the time it is not hard at all.
Besides EFI is supposed to be a standard ergo should have standard data structures. It seem to in the Flash memory structures.
Patches are designed to change one flavor of BIOS they should not be applied to a complete different BIOS
On 2014-10-12 01:36, gogalthorp wrote:
>
> Come now I deal with change of data structure all the time it is not
> hard at all.
Structures that are designed for that.
Assembler and tight code, is not.
It is untagged binary data.
> Besides EFI is supposed to be a standard ergo should have standard data
> structures.
No, that doesn’t necessarily follow. There may be an standard part, an
API, data designed to be used by others. But not the internal data
structures.
> Patches are designed to change one flavor of BIOS they should not be
> applied to a complete different BIOS
They can be, but this not only an issue with different flavours.
For data to be reused, the designer has to be extra careful and design
in advance for this. It is far cheaper not to. I trained for assembler
and low level coding, thus I really know how difficult it is.
That’s the reason most Linux configuration is done on text files, or
variants, such as XML. Or structured data methods. The files contain the
name of the “variables” and the variables, so that different versions of
the code can automatically cope with different versions of the data
files. If the data is binary you need at least a reliable method to
detect the data “version-release”, and then you need a data conversion
routine for each “version-release”, or a binary data definition
structure block of some kind.
You have to build a data importer. Or a data export-import set of
programs: an “exporter” for each “bios” version, and an “importer” for
each version; both exporter and importer sharing a common, text file for
exchange.
All that takes effort and money. A mistake, and you risk bricking a machine.
Risk assessment says “don’t do it”. Don’t bother.
Economics department say “too expensive, don’t do it”.
So they don’t do it.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Seems like by not doing they bricked a machine LOL
All data has structure. Even assembly. If you don’t use structure you should just write in Basic. But even basic has structure though it is easy to lose it. Also in assembly if you are sloppy. I’ve written in almost all forms of computer language. Without structure you have spaghetti. I’d expect an advanced BIOS like UEFI to have well defined structures. Any program that you expect to be be maintained must use defined structure. And yes those structures may change but you are not dealing with unkown code you hopefully dealing commented source so you should know all the registers and memory locations and what they code for. So you read that structure and mode it to the new structure. If you don’t have fully commented source then I guess it is guess and by gully. But I really expect better from multi million dollar operations.
I would say that the User bricked the machine by updating a BIOS while it is password protected with an unknown (forgotten) password.
On 2014-10-12 06:36, gogalthorp wrote:
>
> Seems like by not doing they bricked a machine LOL
>
> All data has structure. Even assembly. If you don’t use structure you
> should just write in Basic. But even basic has structure though it is
Sorry, I didn’t convey my meaning properly. I’m not talking about the
data having an structure. Of course it is always present, be it a mess
or a beauty.
There is a methodology for storing data in which you also store the data
structure definition in the same file or area, “somehow”.
Something like:
etc.
Thus, a program written 20 years from now would read that header and
know where to retrieve each data item, and what each one is.
Without that block, or without exact knowledge of what they are, sizes,
and positions, it is completely impossible to migrate the data from one
bios release to another.
> And yes those structures may change but you are not
> dealing with unkown code you hopefully dealing commented source so you
> should know all the registers and memory locations and what they code
> for.
And can you guarantee that they will not make a single mistake in there?
Not a single mistake? That not a single variable will be missed or
misplaced? Can you ensure that they will distinguish release jhl457 from
release jhi457, which differs in a single byte inserted at position hex
1342, shifting half of it by one byte, so that you can not “copy paste”
the variables because the result would be corrupt?
Knowing that they do make bios releases because they made blunders and
mistakes by the gravel truck load, would you /really/ trust them to read
the data block from another release made a year ago?
Really?
Me, no. Absolutely not.
Nor do their managers… so data is not migrated. Plain simple…
> So you read that structure and mode it to the new structure. If you
> don’t have fully commented source then I guess it is guess and by gully.
> But I really expect better from multi million dollar operations.
Sure. All UEFI code runs as expected :-p
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
And can you guarantee that they will not make a single mistake in there?
Not a single mistake? That not a single variable will be missed or
misplaced? Can you ensure that they will distinguish release jhl457 from
release jhi457, which differs in a single byte inserted at position hex
1342, shifting half of it by one byte, so that you can not “copy paste”
the variables because the result would be corrupt?
Sure I do it all the time it is not hard you just have to be aware and not asleep at the switch. Also you test before release.
Knowing that they do make bios releases because they made blunders and
mistakes by the gravel truck load, would you /really/ trust them to read
the data block from another release made a year ago?
Got a point it is scarey at the level of incompetence that is shown by the amount of bad code shoveled out.
Well I got to say that even though the problem is actually a forgotten password. That if you set some things back to factory then all things should be set back to factory. So in this case secure boot is reset but password is not. arrrgh :X
OK now I’ve got the BIOS password reset. As I had predicted Secure-Boot had been turned on.
I’ve disabled secure-boot and the system boots up perfectly. What can I do in order to avoid the same problem further. How can I change the installation type of openSUSE to secure boot without loosing the data.
Yast –> System –> Boot Loader
Check the box “Enable Secure Boot Support”.
Click “OK”.
You can check the output of
# efibootmgr -v
to see if that worked. It should have a boot entry for “opensuse-secureboot”.
Then, before you reboot, look at “/etc/default/grub”. It should contain the line:
GRUB_USE_LINUXEFI=true
If not, add that and then run
# grub2-mkconfig -o /boot/grub2/grub.cfg
Then reboot, turn on secure-boot in the firmware, then see if it works.
:|Why I didn’t read this post before. Could have saved Rs 500
Yes, nrickert BIOS update disabled F12 boot menu.
Oops! I missed a step. I forgot that you had done this:
bcdedit /set {bootmgr} path \EFI\opensuse\grubx64.efi
While still running opensuse, make sure that the file “/boot/efi/EFI/opensuse/shim.efi” exists.
Then, before turning on secure-boot, login to Windows and do:
bcdedit /set {bootmgr} path \EFI\opensuse\shim.efi
I don’t think so shim.efi is there. I only found shim of fedora. How can I verify? Will I have to mount EFI? I’ve never been able to do that.