1 |
On Tue, 24 Sep 2019 09:31:08 +1000, Adam Carter wrote: |
2 |
|
3 |
> > An update of the firmware flashes the UEFI EEPROM and as far as I have |
4 |
> > experienced no settings are retained. |
5 |
> |
6 |
> A backward step from older MBR / BIOS functionality then. I guess that |
7 |
> indicates that code and configuration are not separated. |
8 |
|
9 |
I recently updated a firmware and all worked as before, so I think this |
10 |
is implementation-dependent. |
11 |
|
12 |
> # gdisk -l /dev/nvme0n1 |
13 |
> GPT fdisk (gdisk) version 1.0.4 |
14 |
> |
15 |
> Partition table scan: |
16 |
> MBR: protective |
17 |
> BSD: not present |
18 |
> APM: not present |
19 |
> GPT: present |
20 |
> <snip> |
21 |
> Number Start (sector) End (sector) Size Code Name |
22 |
> 1 2048 1955839 954.0 MiB EF00 boot |
23 |
> 2 1955840 976771071 464.8 GiB 8300 root |
24 |
> |
25 |
> Not sure where the 'MBR: protective' came from as the system has been |
26 |
> linux only from the start. I guess its either the default or I made an |
27 |
> error during the build. AFAIK this is still a valid configuration, so I |
28 |
> assume the signature message is not related to that. |
29 |
> |
30 |
> I guess i could just try re-writing the partition table to see if that |
31 |
> clears it. |
32 |
|
33 |
I've just checked a couple of systems that have never used MBR and they |
34 |
say the same. I'd ignore that. |
35 |
|
36 |
|
37 |
-- |
38 |
Neil Bothwick |
39 |
|
40 |
If at first you don't succeed, you'll get a lot of free advice from |
41 |
folks who didn't succeed either. |