Talk:BIOS boot partition

This is the talk page for discussing improvements to the BIOS boot partition article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

[Untitled]

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:

(cur | prev) 21:54, 5 August 2012‎ Ianweller (talk | contribs)‎ . . (3,425 bytes) (+1)‎ . . (fix grammar) (undo)
(cur | prev) 21:13, 5 August 2012‎ 128.237.182.81 (talk)‎ . . (3,424 bytes) (+62)‎ . . (Reverted to accurate string. You can look this up if you need, it does evaluate to "Hah!IdontNeedEFI") (undo)
(cur | prev) 14:56, 5 August 2012‎ 71.9.39.58 (talk)‎ . . (3,362 bytes) (-54)‎ . . (Remove factually incorrect claim that the GUID decodes to "EFI" (it actually decodes to "Hah!IdontNeedEFI" which is quite different)) (undo)
(cur | prev) 14:49, 5 August 2012‎ DBigXray (talk | contribs)‎ m . . (3,416 bytes) (-13)‎ . . (Reverted edit(s) by 77.176.214.45 identified as unconstructive using STiki) (undo)
(cur | prev) 08:04, 5 August 2012‎ 77.176.214.45 (talk)‎ . . (3,429 bytes) (+13)‎ . . (Learn your ASCII --- Undid revision 504967919 by Fraggle81 (talk)) (undo)
(cur | prev) 17:54, 30 July 2012‎ Fraggle81 (talk | contribs)‎ m . . (3,416 bytes) (-13)‎ . . (Reverted edit(s) by 79.117.145.140 identified as test/vandalism using STiki) (undo)
(cur | prev) 09:46, 26 July 2012‎ 79.117.145.140 (talk)‎ . . (3,429 bytes) (+13)‎ . . (This is not a joke, this is what that GUID actually is when interpreted as ASCII.) (undo)
(cur | prev) 12:15, 13 July 2012‎ ClueBot NG (talk | contribs)‎ m . . (3,416 bytes) (-13)‎ . . (Reverting possible vandalism by 84.206.25.236 to version by M.O.X. False positive? Report it. Thanks, ClueBot NG. (1142638) (Bot)) (undo)
(cur | prev) 12:14, 13 July 2012‎ 84.206.25.236 (talk)‎ . . (3,429 bytes) (+13)‎ . . (undo)
(cur | prev) 11:06, 12 June 2012‎ M.O.X (talk | contribs)‎ m . . (3,416 bytes) (-13)‎ . . (Reverted edit(s) by Mikeloco14 identified as test/vandalism using STiki) (undo)
(cur | prev) 08:09, 12 June 2012‎ Mikeloco14 (talk | contribs)‎ . . (3,429 bytes) (+13)‎ . . (EFI is just 3 bytes, the GUID obviously couldn't read just "EFI" in ASCII.) (undo)

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]

The "Hah!IdontNeedEFI" string is correct; further evidence can be seen in this tweet. The endianness rules for storing GUIDs in binary form can be seen in this Microsoft documentation, and those rules are the cause of all the confusion around the Easter Egg embedded in this GUID.

Rmunn (talk) 07:27, 30 May 2018 (UTC)[reply]

second stages

I find it misleading to talk about second stages, while this is, afaik, in most cases the so called stage 1.5 precding stage 2 in grub . --Itu (talk) 10:40, 14 June 2015 (UTC)[reply]

still usable gap with GPT

So, there is still a gap with GPT, practically, because of good-practice Alignment (typically 1MB) and this gap may be used with fitting or encompassing Partition or without. But without, it may be even less reliable und undefined as the 63-block MBR-gap. Furthermore with GPT it is not to bold to claim a partition, where in MBR this would have cost 1 of only 4 primary partitions. Just saying/thinking. --Itu (talk) 10:56, 14 June 2015 (UTC)[reply]

SSD-Drive with GPT, not accessable by XP (sorry), by BIOS I do not know

My starting point is knowing only MBR. But without a knowing what is a good workable with superordinate, genus.
Until now meeting GPT (on SSD-Drive) there for me was no necessity to it.
The point: XP and/or BIOS (?, sorry) did not recognize it.
To be able to make it accessable I had to work out, what is it, GPT, and how to get to MBR.
Only www.diskpart.com I could find, with software, to change from GPT to MBR.
Some days after these hourful works I could get an other, much more easyer (instead to have to figure all this out until understanding what has to be done and how and with what (software)) way to do it: xfdisk, by familiar with DOS. Else this ´diskpart´ does it really easy, too, if once found first, this does it.
((xfdisk:) An unknown drive, or partition, is shown, this ´partition´ delete and create a partition again just does it, as told to me by a professionell.)
To let it others know, I just do note it now here. But I cannot do the efforts to look for sources to it now, sorry. But in hope, my works and figuring outs, already may be a help.
Thanks the interesst.
--Visionhelp (talk) 11:27, 31 August 2021 (UTC)[reply]
Sorry, found now this: is my comment perhaps better placed there GUID_Partition_Table? Thanks.
--Visionhelp (talk) 11:22, 1 September 2021 (UTC)[reply]