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 subject of the article. |
Article policies
|
| Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
 | Computing Start‑class | |||||||||
| ||||||||||
[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)
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)
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)
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)
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)
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.
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)
still usable gap with GPT
So, there is still a gap with GPT, practically, because of good-practice Alignment (typically 1MB). But this 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)