UEFI GPT

[wolfgang kern]

my attempt to manually create a complete UEFI startup with KESYS hexwork
still encounter many obstacles :)

please tell me what I may have missed and what's different to your settings.
TIA
__
wolfgang

what I have so far:
(almost all is in hex, b/w/q/dq/qq mean 8/16/32/64/128 bit)
[LBA_0] MBR:
0000 ... all zero
01BE xx xx xx EE yy yy yy 01 00 00 00 ss ss ss ss
x = start CHS usually 1
y = end CHS usually FFFFFF
0000_0001 start LBA of GPT image
0000_0004 size of this GPT image LBA_0,1,2,3 (in sectors)
specs want much more to waste
01CE ... all zero
01FE 55 AA
------------------
[LBA_1] GPT header
000 45 46 49 20 50 41 52 54 ;"EFI PART" Signature
008 00 00 01 00 Revision for GPT version 1.0
(through at least UEFI version 2.3.1),
00C 5C 00 00 00 Header size (in bytes)
010 q 0 CRC32 of header (offset +0 up to header size),
with this field zeroed during calculation
014 q 0 Reserved; must be zero
018 dq .... Current LBA (location of this header copy)
020 dq .... Backup LBA (location of the other header copy)
028 dq 4 First usable LBA for partitions (primary last LBA + 1)
specs say minimum 6 for 4K sectors and 34dec for 512 byte sectors
what a waste ...
030 dq .... Last usable LBA (secondary partition first LBA - 1)
038 dq ??? Disk GUID (also referred as UUID on UNIXes)
048 dq 2 Starting LBA of array of partition entries
(always 2 in primary)
050 q 00000004 Number of partition entries in array
054 q 00000080 Size of a single partition entry (usually 128)
058 q 0 CRC32 of partition array
05C..end of sector; all ZERO
(420 bytes for 512 byte sectors; but more with larger sector sizes)
---------------------------
[LBA_2] I'd have only four partition entries assigned
GUID partition entry format [128 byte each]
000 qq Partition type GUID
1. ??? boot part ;FAT32
2. "KESYS 64 ddmm2024" to be declared global unique ;KESYS64
3. 28 73 C1 2A-1F F8 D2 11 BA 4B 00 A0 C9 3E C9 3B ;EFI
4. 16 E3 C9 E3 5C 0B B8 4D 81 7D F9 2D F0 02 15 AE ;M$ reserved
??? ;or NTFS
010 qq ??? Unique partition GUID
020 dq 4/x/x/x First LBA (specs say 6 or 34 for first partition)
028 dq Last LBA (inclusive, usually odd)
030 dq Attribute flags
038 str 72 bytes Partition name (36 UTF-16LE code units)

The 64-bit partition table attributes are shared between 48-bit common
attributes for all partition types, and 16-bit type-specific attributes.
<eof>

[Paul Edwards]

On 20/01/24 12:16, wolfgang kern wrote:

> my attempt to manually create a complete UEFI startup with KESYS hexwork
> still encounter many obstacles :)
>
> please tell me what I may have missed and what's different to your
> settings.
> TIA
> __
> wolfgang
>
> what I have so far:
> (almost all is in hex, b/w/q/dq/qq mean 8/16/32/64/128 bit)
> [LBA_0] MBR:
> 0000 ... all zero

Are you aware that you can do a UEFI boot
from an MBR partition?

That might get you further quicker.

BFN. Paul.

[wolfgang kern]

yes, but this limits the size of all other partitions to 2^32-1 sectors.
all of my HDs are larger than 2TB (512 byte sectors), so I need GPT.
GPT allow for more than four start partitions (for future expansion).

I cannot remove a single question mark from your help :(
__
wolfgang

[Paul Edwards]

On 21/01/24 07:56, wolfgang kern wrote:
> On 20/01/2024 16:44, Paul Edwards wrote:

> yes, but this limits the size of all other partitions to 2^32-1 sectors.
> all of my HDs are larger than 2TB (512 byte sectors), so I need GPT.

Ok, fair enough.

> GPT allow for more than four start partitions (for future expansion).
>
> I cannot remove a single question mark from your help :(

Sorry - I've never used GPT myself (for my
own use), so I can't help you with that.

BFN. Paul.

[wolfgang kern]

my attempt to manually create a complete UEFI startup with KESYS hexwork
still encounter many obstacles :)

QUESTIONS still are: what should I enter into
1. the 64 bit Disk GUID (also referred as UUID on UNIXes)?
2. the 64 bit GUID for FAT32 start partition (first entry in LBA_2)?
3. is it really required to waste 33 sectors for never used entries?
or would my short (only one sector) solution work as well?

please tell me what I may have missed and what's different to your
settings.
TIA
__
wolfgang

> what I have so far:
> (almost all is in hex, b/w/q/dq/qq mean 8/16/32/64/128 bit)

corrected (was off by one):
LBA_0: MBR
0000... all Zero
01BE 01 BootIndicator
Set to 0x00 to indicate a non-bootable partition.
If set to any value the behavior of this flag on non-UEFI systems is
undefined.
Must be ignored by UEFI implementations.
01BF 00 02 00 StartingCHS ;means LBA_01
01C2 EE OSType (i.e GPT Protective)
01C3 FF FF FF EndingCHS
01C6 q 01 StartingLBA
01CA q FFFFFFFF Size of whole disk (in sectors-1); less if smaller
01CE ... remaining Partition Records shall each be set to zeros.

[wolfgang kern]

because nobody responded to my questions and I couldn't find anything on
the net it seems some parts of the story are intentional well hidden.
So now I have to try and fail, which may cost me several month.
And whenever/if at all I find these missing info I will keep it a secret
as well.

[Herbert Kleebauer]

On 09.02.2024 15:31, wolfgang kern wrote:

> because nobody responded to my questions and I couldn't find anything on
> the net it seems some parts of the story are intentional well hidden.
> So now I have to try and fail, which may cost me several month.
> And whenever/if at all I find these missing info I will keep it a secret
> as well.

I suppose you will find all this information in the
GRUB documentation/source code or some other Linux
software. It's all open source.

https://www.gnu.org/software/grub/grub-documentation.html

But why not just use GRUB to boot your OS? You don't
write the firmware of the PC yourself, so why do you
want to write the boot loader yourself? Software
development isn't a one man show anymore!

[Scott Lurndal]

wolfgang kern <now...@never.at> writes:
>because nobody responded to my questions and I couldn't find anything on
>the net it seems some parts of the story are intentional well hidden.
>So now I have to try and fail, which may cost me several month.
>And whenever/if at all I find these missing info I will keep it a secret
>as well.
>
>On 27/01/2024 09:50, I wrote:
>> my attempt to manually create a complete UEFI startup with KESYS hexwork
>> still encounter many obstacles :)
>> QUESTIONS still are:  what should I enter into
>> 1. the 64 bit Disk GUID (also referred as UUID on UNIXes)?

Any globally unique 64-bit value.

>> 2. the 64 bit GUID for FAT32 start partition (first entry in LBA_2)?

Another globally unique 64-bit value.

>> 3. is it really required to waste 33 sectors for never used entries?

yes.

[wolfgang kern]

On 09/02/2024 16:54, Herbert Kleebauer wrote:
> On 09.02.2024 15:31, wolfgang kern wrote:
>
>> because nobody responded to my questions and I couldn't find anything on
>> the net it seems some parts of the story are intentional well hidden.
>> So now I have to try and fail, which may cost me several month.
>> And whenever/if at all I find these missing info I will keep it a secret
>> as well.

> I suppose you will find all this information in the
> GRUB documentation/source code or some other Linux
> software. It's all open source.

open source? sounds like C-gruft which I don't understand.

> https://www.gnu.org/software/grub/grub-documentation.html

thanks, but I could not find anything related to my questions.

> But why not just use GRUB to boot your OS?

my KESYS isn't a free OS and the new version will be 64 bit.
I don't want/need to write a boot loader I rather like to create my own
formatting tools which include all MBR+GPT+UEFI+FAT+NTFS+KESYS stuff.

> You don't write the firmware of the PC yourself, so why do you
> want to write the boot loader yourself?

My plan is to use UEFI-support to load my OS which then deploys itself
similar (64 bit now) to the way it did on BIOS machines.

> Software development isn't a one man show anymore!

:) in my world it still is a "one machine code man" show!

and all I need to do is to convert my old 32bit OS to 64bit.
And I do this like I always did:
manually enter in hex on my own editable disassembler.

if you have access to any UEFI GPT machine can you please copy me a 512
byte hexdump of LBA_1 ?
this would answer all my open questions on GPT.
__
wolfgang

[wolfgang kern]

thanks, do you know a source where I can look up these globally unique?
or do you know this 16 bytes for FAT32 ?
__
wolfgang

[wolfgang kern]

...

>> QUESTIONS still are:  what should I enter into
>> 1. the 64 bit Disk GUID (also referred as UUID on UNIXes)?
> Any globally unique 64-bit value.

can this perhaps be found in the IDENTIFY-DEVICE block?
__
wolfgang

[Scott Lurndal]

By definition, every GPT has an unique 16-byte GUID.

Generate and concatenate 2 64-bit true random numbers.

[Scott Lurndal]

no.

Each one is unique. It's generated from random data when
each GPT is first created. It's different in every GPT
(thus every disk on every system in the universe). It
uniquely identifies the media.

[Herbert Kleebauer]

On 09.02.2024 20:08, wolfgang kern wrote:

>> https://www.gnu.org/software/grub/grub-documentation.html
>
> thanks, but I could not find anything related to my questions.

Maybe a simpler solution:

https://gitlab.com/bztsrc/simpleboot

|| I was wondering what could be the bare minimum and simplest usable
|| implementation of booting a kernel, because let's face it, GRUB
|| and the others sucks big time. They're very overcomplicated, bloated,
|| hard to install and very easy to fuck up their config syntax.

> My plan is to use UEFI-support to load my OS which then deploys itself
> similar (64 bit now) to the way it did on BIOS machines.

https://wiki.osdev.org/UEFI

> and all I need to do is to convert my old 32bit OS to 64bit.
> And I do this like I always did:
> manually enter in hex on my own editable disassembler.

What is the advantage of converting the 32 bit code to 64 bit?

> if you have access to any UEFI GPT machine can you please copy me a 512
> byte hexdump of LBA_1 ?
> this would answer all my open questions on GPT.

I don't think it easily accessible from Windows.



There is plenty of information on the internet, but life
is to short to waste time reading it.

https://uefi.org/specs/UEFI/2.10/05_GUID_Partition_Table_Format.html
https://github.com/rhboot/gnu-efi/blob/328951d3dcb5ff97f5a7c7a362b006626fada000/inc/efigpt.h
https://dox.ipxe.org/dir_4a1b5254013690bf5f8e17eef5bed97c.html
https://de.wikipedia.org/wiki/GUID_Partition_Table
https://github.com/rhboot/shim/wiki
https://github.com/rhboot/gnu-efi/blob/328951d3dcb5ff97f5a7c7a362b006626fada000/README.gnuefi

[wolfgang kern]

On 09/02/2024 22:03, Herbert Kleebauer wrote:
> On 09.02.2024 20:08, wolfgang kern wrote:
>>> https://www.gnu.org/software/grub/grub-documentation.html
>> thanks, but I could not find anything related to my questions.

> Maybe a simpler solution:
> https://gitlab.com/bztsrc/simpleboot

this and also easyboot don't know KESYS ... and are GPL.

> || I was wondering what could be the bare minimum and simplest usable
> || implementation of booting a kernel, because let's face it, GRUB
> || and the others sucks big time. They're very overcomplicated, bloated,
> || hard to install and very easy to fuck up their config syntax.

the above could have be said by me too :)

>> My plan is to use UEFI-support to load my OS which then deploys itself
>> similar (64 bit now) to the way it did on BIOS machines.

> https://wiki.osdev.org/UEFI

been there several times. but found no answer to my question about
what to put as first partition type guide for FAT32.

>> and all I need to do is to convert my old 32bit OS to 64bit.
>> And I do this like I always did:
>> manually enter in hex on my own editable disassembler.

> What is the advantage of converting the 32 bit code to 64 bit?

to have both versions, many opcodes aren't available ion 32 bit.

>> if you have access to any UEFI GPT machine can you please copy me a 512
>> byte hexdump of LBA_1 ?
>> this would answer all my open questions on GPT.

> I don't think it easily accessible from Windows.

YEAH, as I said it's well hidden.

> There is plenty of information on the internet, but life
> is to short to waste time reading it.
>
> https://uefi.org/specs/UEFI/2.10/05_GUID_Partition_Table_Format.html

I already have the whole UEFI-specs
(and I started to convert it from C to RBIL-style)
> https://github.com/rhboot/gnu-efi/blob/328951d3dcb5ff97f5a7c7a362b006626fada000/inc/efigpt.h
not a single word about FAT32 guid
> https://dox.ipxe.org/dir_4a1b5254013690bf5f8e17eef5bed97c.html
moved me back and forth w/o telling the content of the unique GUID

> https://de.wikipedia.org/wiki/GUID_Partition_Table
I copied the list of GUIDs from this one,
it could contain what I search for...
or at least reduce some try and fail attempts.

> https://github.com/rhboot/shim/wiki
M$ bound
> https://github.com/rhboot/gnu-efi/blob/328951d3dcb5ff97f5a7c7a362b006626fada000/README.gnuefi
no GNU here

thanks,
__
wolfgang

[wolfgang kern]

On 09/02/2024 21:34, Scott Lurndal wrote:
...

>> thanks, do you know a source where I can look up these globally unique?
>> or do you know this 16 bytes for FAT32 ?

> By definition, every GPT has an unique 16-byte GUID.

> Generate and concatenate 2 64-bit true random numbers.

you mean I have to create it ?
how could I make sure it's globally unique then ?
__
wolfgang

[wolfgang kern]

I'm totally confused yet,
where do these numbers come from and how to get them ?
__
wolfgang

[Alexei A. Frounze]

On Friday, February 9, 2024 at 8:23:07 PM UTC-8, wolfgang kern wrote:
> how could I make sure [GUID]'s globally unique then ?

Probability of collision is expected to be low enough to treat the number unique in practice.
See
https://en.wikipedia.org/wiki/Universally_unique_identifier
and specifically
ITU-T Rec. X.667 or RFC 4122

Alex

[wolfgang kern]

thanks a lot Alex, I now can add this link to my GPT-docs

https://www.itu.int/en/ITU-T/asn1/Pages/UUID/uuids.aspx

why was it that hard to get this info :)
__
wolfgang

[wolfgang kern]

On 10/02/2024 05:16,I wrote:

>> https://de.wikipedia.org/wiki/GUID_Partition_Table
> I copied the list of GUIDs from this one,
> it could contain what I search for...
> or at least reduce some try and fail attempts.

GPT partition type for FAT32:
46 33 32 00 00 00 00 00 00 00 00 00 00 00; 'F32'

I'll try this one first.
__
wolfgang

[JJ]

On Fri, 9 Feb 2024 15:31:13 +0100, wolfgang kern wrote:
> because nobody responded to my questions and I couldn't find anything on
> the net it seems some parts of the story are intentional well hidden.
> So now I have to try and fail, which may cost me several month.
> And whenever/if at all I find these missing info I will keep it a secret
> as well.
>
> On 27/01/2024 09:50, I wrote:
>> my attempt to manually create a complete UEFI startup with KESYS hexwork
>> still encounter many obstacles :)
>> QUESTIONS still are:  what should I enter into
>> 1. the 64 bit Disk GUID (also referred as UUID on UNIXes)?
>> 2. the 64 bit GUID for FAT32 start partition (first entry in LBA_2)?
>> 3. is it really required to waste 33 sectors for never used entries?
>>    or would my short (only one sector) solution work as well?

Disk and partition IDs (in whatever form they use) are mainly for the upper
level storage drivers to differentiate between them, since they don't
normally deal with storage controller and port numbers (which is a task for
the lower level driver).

Reserved sectors near start of the disk has been around since MBR disk
layout. In MBR, the reserved sector would be up to 62 sectors for disks
which are configured to use 63 sectors per side configuration.

[wolfgang kern]

On 10/02/2024 14:10, JJ wrote:
> On Fri, 9 Feb 2024 15:31:13 +0100, wolfgang kern wrote:
>> because nobody responded to my questions and I couldn't find anything on
>> the net it seems some parts of the story are intentional well hidden.
>> So now I have to try and fail, which may cost me several month.
>> And whenever/if at all I find these missing info I will keep it a secret
>> as well.
>>
>> On 27/01/2024 09:50, I wrote:
>>> my attempt to manually create a complete UEFI startup with KESYS hexwork
>>> still encounter many obstacles :)
>>> QUESTIONS still are:  what should I enter into
>>> 1. the 64 bit Disk GUID (also referred as UUID on UNIXes)?
>>> 2. the 64 bit GUID for FAT32 start partition (first entry in LBA_2)?
>>> 3. is it really required to waste 33 sectors for never used entries?
>>>    or would my short (only one sector) solution work as well?

> Disk and partition IDs (in whatever form they use) are mainly for the upper
> level storage drivers to differentiate between them, since they don't
> normally deal with storage controller and port numbers (which is a task for
> the lower level driver).

Yes I realized that, but I want to manually create an UEFI conform GPT
start up sector with only four entries (FAT32 as the first).

> Reserved sectors near start of the disk has been around since MBR disk
> layout. In MBR, the reserved sector would be up to 62 sectors for disks
> which are configured to use 63 sectors per side configuration.

well known BS, my OS never wasted any sector. my now old KESYS used code
in the MBR as first part of the OS core and it continued on LBA_1.
so the whole OS-image (512MB) is stored in consecutive order on disk.

I'll keep this for the new 64bit version even the start may not be on
LBA_0 due to the UEFI/GPT stuff.
__
wolfgang

[Dan Cross]

In article <uq6tsa$31g7g$3...@dont-email.me>,

They are random numbers. You make them up, in software, or
taking from some kind of entropy source.

- Dan C.

[wolfgang kern]

On 10/02/2024 20:21, Dan Cross wrote:

>>>>>> QUESTIONS still are:  what should I enter into
>>>>>> 1. the 64 bit Disk GUID (also referred as UUID on UNIXes)?

>>> Each one is unique. It's generated from random data when
>>> each GPT is first created. It's different in every GPT
>>> (thus every disk on every system in the universe). It
>>> uniquely identifies the media.

>> I'm totally confused yet,
>> where do these numbers come from and how to get them ?

> They are random numbers. You make them up, in software, or
> taking from some kind of entropy source.

thx, as already mentioned in this thread I found a source.
but I might just use vendor&serial number of the HD instead.
__
wolfgang

[Dan Cross]

In article <uq7ac6$3369l$1...@dont-email.me>,

...it's not? I mean, did you try to look it up?

- Dan C.

[wolfgang kern]

of course I did.
I found several hundreds sites who mentioned globally unique ID and only
two showed a couple of 16 byte values but nothing what I searched for.
And replies except the one from Alex missed to tell that I can download
a never used new GUID.
__
wolfgang

[Dan Cross]

In article <uq9o1p$j2ln$1...@dont-email.me>,

He literally linked you to Wikipedia. Didn't you search
for "how to generate a UUID"?

- Dan C.

[wolfgang kern]

On 11/02/2024 21:08, Dan Cross wrote:
[about globally unique]

>>>> why was it that hard to get this info :)
>>>
>>> ...it's not? I mean, did you try to look it up?
>>
>> of course I did.
>> I found several hundreds sites who mentioned globally unique ID and only
>> two showed a couple of 16 byte values but nothing what I searched for.
>> And replies except the one from Alex missed to tell that I can download
>> a never used new GUID.

> He literally linked you to Wikipedia.

yes, but with useful patterns.

> Didn't you search for "how to generate a UUID"?

yes, but I found just "random" rather than "unique".
timestamps algorithm are by far not guarantied to be unique.
So I could use my disk's VendorID+SerialNr+date+time, even really unique
this wouldn't become registered then (WTF who cares?)
__
wolfgang

[Andy Valencia]

wolfgang kern <now...@never.at> writes:
> yes, but I found just "random" rather than "unique".
> timestamps algorithm are by far not guarantied to be unique.

And MAC addresses on your LAN interfaces _should_ be unique, except for those
vendors who cheap out and don't invest in a properly managed source of MAC
addresses to assign to their adaptors.

And crypto-hard random numbers _should_ be good enough; get 128 bytes and the
collision odds are small even to the heat death of the universe. But you
only find out your numbers weren't "random enough" when it's far too late.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

[wolfgang kern]

On 11/02/2024 23:38, Andy Valencia wrote:
> wolfgang kern <now...@never.at> writes:
>> yes, but I found just "random" rather than "unique".
>> timestamps algorithm are by far not guarantied to be unique.
>
> And MAC addresses on your LAN interfaces _should_ be unique, except for those
> vendors who cheap out and don't invest in a properly managed source of MAC
> addresses to assign to their adaptors.
>
> And crypto-hard random numbers _should_ be good enough; get 128 bytes and the
> collision odds are small even to the heat death of the universe. But you
> only find out your numbers weren't "random enough" when it's far too late.

128 byte might be good enough, but GPT uses only 16 bytes for GUID.
so the only save way is download from any reliable source.
I may just create whatsoever and hope UEFI doesn't choke on it.
ie: db ASCII(16) "bought on 311223"
__
wolfgang

[Paul Edwards]

On 10/02/24 03:08, wolfgang kern wrote:

> if you have access to any UEFI GPT machine can you please copy me a 512
> byte hexdump of LBA_1 ?

I checked the replies but didn't see anyone
post the requested hexdump.

> this would answer all my open questions on GPT.

Ok, I don't know anything about GPT, but what I do
know is that my Chinese computer (with Zhaoxin
processor) that has Kylin OS installed has UEFI
enabled, and if I switch to legacy, it no longer
boots.

But legacy boots PDOS, including from USB stick.

So after booting PDOS I have done an xychop from
drv81: for 1024 bytes, and here it is:

000000 00000000 00000000 00000000 00000000 ................
000010 00000000 00000000 00000000 00000000 ................
000020 00000000 00000000 00000000 00000000 ................
000030 00000000 00000000 00000000 00000000 ................
000040 00000000 00000000 00000000 00000000 ................
000050 00000000 00000000 00000000 00000000 ................
000060 00000000 00000000 00000000 00000000 ................
000070 00000000 00000000 00000000 00000000 ................
000080 00000000 00000000 00000000 00000000 ................
000090 00000000 00000000 00000000 00000000 ................
0000A0 00000000 00000000 00000000 00000000 ................
0000B0 00000000 00000000 00000000 00000000 ................
0000C0 00000000 00000000 00000000 00000000 ................
0000D0 00000000 00000000 00000000 00000000 ................
0000E0 00000000 00000000 00000000 00000000 ................
0000F0 00000000 00000000 00000000 00000000 ................
000100 00000000 00000000 00000000 00000000 ................
000110 00000000 00000000 00000000 00000000 ................
000120 00000000 00000000 00000000 00000000 ................
000130 00000000 00000000 00000000 00000000 ................
000140 00000000 00000000 00000000 00000000 ................
000150 00000000 00000000 00000000 00000000 ................
000160 00000000 00000000 00000000 00000000 ................
000170 00000000 00000000 00000000 00000000 ................
000180 00000000 00000000 00000000 00000000 ................
000190 00000000 00000000 00000000 00000000 ................
0001A0 00000000 00000000 00000000 00000000 ................
0001B0 00000000 00000000 1127210C 14D30000 .........'!.....
0001C0 0200EEFF FFFF0100 0000AF12 9E3B0000 .............;..
0001D0 00000000 00000000 00000000 00000000 ................
0001E0 00000000 00000000 00000000 00000000 ................
0001F0 00000000 00000000 00000000 000055AA ..............U.
000200 45464920 50415254 00000100 5C000000 EFI PART....\...
000210 9D526FFC 00000000 01000000 00000000 .Ro.............
000220 AF129E3B 00000000 22000000 00000000 ...;....".......
000230 8E129E3B 00000000 6F892CDF A452F145 ...;....o.,..R.E
000240 96E465FA F34F6C40 02000000 00000000 ..e..Ol@........
000250 80000000 80000000 224BCEB6 00000000 ........"K......
000260 00000000 00000000 00000000 00000000 ................
000270 00000000 00000000 00000000 00000000 ................
000280 00000000 00000000 00000000 00000000 ................
000290 00000000 00000000 00000000 00000000 ................
0002A0 00000000 00000000 00000000 00000000 ................
0002B0 00000000 00000000 00000000 00000000 ................
0002C0 00000000 00000000 00000000 00000000 ................
0002D0 00000000 00000000 00000000 00000000 ................
0002E0 00000000 00000000 00000000 00000000 ................
0002F0 00000000 00000000 00000000 00000000 ................
000300 00000000 00000000 00000000 00000000 ................
000310 00000000 00000000 00000000 00000000 ................
000320 00000000 00000000 00000000 00000000 ................
000330 00000000 00000000 00000000 00000000 ................
000340 00000000 00000000 00000000 00000000 ................
000350 00000000 00000000 00000000 00000000 ................
000360 00000000 00000000 00000000 00000000 ................
000370 00000000 00000000 00000000 00000000 ................
000380 00000000 00000000 00000000 00000000 ................
000390 00000000 00000000 00000000 00000000 ................
0003A0 00000000 00000000 00000000 00000000 ................
0003B0 00000000 00000000 00000000 00000000 ................
0003C0 00000000 00000000 00000000 00000000 ................
0003D0 00000000 00000000 00000000 00000000 ................
0003E0 00000000 00000000 00000000 00000000 ................
0003F0 00000000 00000000 00000000 00000000 ................


I assume that is GPT, but since UEFI can boot from MBR
(as I mentioned before), maybe it isn't.

I haven't attempted to analyze it.

BFN. Paul.

[wolfgang kern]

On 13/02/2024 06:57, Paul Edwards wrote:
> On 10/02/24 03:08, wolfgang kern wrote:
>
>> if you have access to any UEFI GPT machine can you please copy me a 512
>> byte hexdump of LBA_1 ?
>
> I checked the replies but didn't see anyone
> post the requested hexdump.
>
>> this would answer all my open questions on GPT.
>
> Ok, I don't know anything about GPT, but what I do
> know is that my Chinese computer (with Zhaoxin
> processor) that has Kylin OS installed has UEFI
> enabled, and if I switch to legacy, it no longer
> boots.
>
> But legacy boots PDOS, including from USB stick.
>
> So after booting PDOS I have done an xychop from
> drv81: for 1024 bytes, and here it is:

thanks a lot:
I convert it to explain what's where
LBA_0_MBR
0000.. all zero
01b8 0c 21 27 11 ;mark from formatting
01bc 00 00
01be d3 it's bootable but an unusual value
01bf 14 02 00 ;boot sector start CHS
01c2 EE ;this is an EFI partition
01c3 FF FF FF ;last CHS sector (>> here)
01c6 01 00 00 00 ;GPT is on LBA_1 yet
01ca 3b 9e 12 af ;total disk size (sectors)
2'937'232'955 sectors are 1.5 TB with 512 byte sectors
01ce ... ;all zero
01fe 55 aa
----------
LBA_1 (GPT)
0200 45464920 50415254 ;"EFI PART"
0208 00000100 ;version 1.0020c 5C000000 ;header size
0210 9D526FFC ;CRC
0214 00000000 ;align filler
0218 01000000_00000000 ;header copy LBA (points to itself here)
0220 AF129E3B_00000000 ;backup LBA (the last on disk here)
0228 22000000_00000000  ;first usable LBA (aka wast count)
0230 8E129E3B_00000000 ;last usable LBA (wast 32 at the end too?)
0238 6F892CDF_A452F145  ;DISK GUIDE (now guess where this come from)
0240 96E465FA_F34F6C40 ; _"_
0248 02000000 00000000  :LBA start of GPT entries array (always 2)
0250 80000000 ;number of GPT entries (128 here ???)
0254 80000000 ;size of a GPT entry (128 as usual)
0258 224BCEB6 ;CRC32 of partition array
------------- ;end of header
025c ..3ff ;all zero

> I assume that is GPT, but since UEFI can boot from MBR
> (as I mentioned before), maybe it isn't.

yeah it is.

> I haven't attempted to analyze it.

my pleasure to do such:)
and it confirms my ideas on how it shall look like.
__
wolfgang

[wolfgang kern]

On 13/02/2024 08:40, I wrote:
line unwrapped

[wolfgang kern]

Hi JJ,
I can only read bot not post to CLAX anymore.
please tell Rudy to ask his question again on either ALA or AOD.
I have all answers for him.
__
wolfgang