Talk:BIOS boot partition

This is an old revision of this page, as edited by 2601:9:3300:5b:e269:95ff:fe35:9f3c (talk) at 04:19, 25 April 2013 (Attribution to Mr. Millan ?). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Latest comment: 12 years ago by 2601:9:3300:5B:E269:95FF:FE35:9F3C in topic Attribution to Mr. Millan ?

GPT-MBR goes to the all-your-base meme page. This probably isnt what you wanted.

Attribution to Mr. Millan ?

Since it appears that GNU GRUB developer User:Robertmh came up with this concept (and integrated it into GRUB), should he be credited? Or should it at least be clearly stated that this is an invention by the GNU GRUB team, so people know where this concept came from? —Hobart (talk) 07:29, 28 February 2012 (UTC)Reply

Not just that, this is proprietary to GRUB. It should be listed as "GRUB BIOS Boot partition"; claiming that it is somehow a standard of some kind is not merely nonsense, but it is actively harmful since the whole point of GUIDs is to avoid collisions. This is the GRUB partition, plain and simple. 2601:9:3300:5B:E269:95FF:FE35:9F3C (talk) 04:17, 25 April 2013 (UTC)Reply

Similarly, the practice of squatting on unpartitioned space in MBR partition tables claiming it is somehow "reserved for the bootloader" also is largely a GRUB "standard" (in fact, a number of utilities are known to squat on that space in a highly uncontrolled manner.) 2601:9:3300:5B:E269:95FF:FE35:9F3C (talk) 04:19, 25 April 2013 (UTC)Reply

Hah!IdontNeedEFI confusion regarding endianness

Much confusion has arisen regarding endianness of the "Hah!IdontNeedEFI" GUID:

Look at the fine history:

Sure you want to report a false positive. 2607:FCD0:100:9:0:0:0:3 (talk) 03:33, 8 August 2012 (UTC)Reply


i accidently looked it up before seeing your discussion:

$ dd if=/dev/sda bs=512 count=40 | xxd | grep 000580
40+0 records in
40+0 records out
20480 bytes (20 kB) copied, 8.4399e-05 s, 243 MB/s
0000580: 4861 6821 4964 6f6e 744e 6565 6445 4649 Hah!IdontNeedEFI


Juli@n (talk) —Preceding undated comment added 13:02, 29 August 2012 (UTC)Reply

I've gathered the following pieces of information in trying to understand it all:

  • The first three fields of a UUID/GUID are a 4-byte value, then 2 2-byte values. All subsequent values are single bytes or byte arrays, so only the first 8 bytes are affected by endianness concerns.
  • The typical way to write a UUID/GUID's string form in RFCs / Linux-centric documentation is big endian.
  • However Microsoft sources tend to write UUID/GUID string forms little endian.
  • The byte order of an on-disk GPT is little endian.

MaxBowsher (talk) 01:57, 19 April 2013 (UTC)Reply