Zaval's issue with GPT and ESP

[bzt]

@PeterX: just ignore zaval, he is obviously trolling.

@zaval: PeterX did not "command" you, he did not pretend to be a moderator either, he just kindly asked you. I understand that you're from Russia, and you're not a native English speaker, but surely you can comprehend the meaning of "please". PeterX wrote "please stop" and "Please play bad guy elsewhere."
You do see the "please" in both, don't you?

Cheers,
bzt

[bzt]

FYI, the card does not interpret the data,

Some of them do. WiFi SD cards are the most obvious example, but you can't tell what ordinary SD cards are doing inside their firmware.

But then it is not a pure general purpose storage card, isn't it? It has additional circuitry, and that's what might pose further restrictions on the card's format. It is the additional circuitry that interprets the card's file system, not the SD hardware (even if that additional WiFi and whatever circuitry is physically on the same card).

Many Android mobile phones has built-in SD cards for their internal storage, and neither of them using FAT (only for the external card). Banana Pi, Orange Pi, etc. do not use FAT as root file system on the SD cards (and these are just the RPi clones, I'm sure there are many others).

Cheers,
bzt

[BenLunt]

so what is the problem if we color outside the lines, right?

SD cards are an unusual case because unlike most other storage media, the SD card itself is allowed to change its contents outside of whatever reading and writing you do. If you don't follow the specifications, you risk confusing the card into corrupting your data.

There are also performance considerations: SD cards may not be able to reach their rated performance if you don't read and write them as the manufacturer intended.

You can probably still get away with a hybrid MBR+GPT scheme (as long as there's no backup GPT), since the specification doesn't explicitly say what you can and can't put in the gap between the MBR and the start of the partition.

I haven't done much, if any, research on SD cards, so I am asking for info here.

For argument's sake, let's assume an SD Card has a set of linear sectors, each 512 bytes in size, starting with LBA 'A' to LBA 'Z'. The SD card can have these sectors spread among the physical media however it wishes, maybe linear, maybe not. However, as far as my software sees the media, it is 'A' through 'Z' and is linear.

If I write to LBA 'N', even if the SD Card changes the location of this sector to a different location, whenever I read from LBA 'N', the SD card returns the same sector contents, even though the contents may now be physically stored somewhere else.

In other words, even if the SD Card moves sectors around, I can still assume that the software driver can still see the sectors as linear from LBA 'A' to LBA 'Z'. Correct?

Therefore, if this is the case, I can treat the SD Card as if it was an IDE Hard drive, USB Thumb Drive, etc., assuming that no matter the media type, I can still assume that if I write to LBA 123456, later in the process, I can read back LBA 123456 and still get the same contents read, even though the card might have moved the sector physically.

Does this make sense, and if so is it a correct assumption? If this is a correct assumption, then I don't need to worry about it being an SD Card in the subject this is a reply to, correct?

Thanks,
Ben

[bzt]

@BenLunt: yes, you're correct. In a nutshell, the thing is, although the physical / logical sector mapping remains hidden from software, drivers can categorize LBA addresses. For example it could tell that LBA 'A' - 'B' contains meta-info (aka. FAT), LBA 'C' contains directory entries, and the rest LBA 'D' - 'Z' stores file contents. This will help the card to make smarter choices on how to map physical / logical (don't ask why or how, nobody knows, but at least that's what the SD spec claims categorization is for). Also, to have full performance, you'll need bulk read and writes, and with some cards this only possible on categorized sectors (actually this makes sense provided different physical sectors are mapped to each category; that means you cannot mix different sectors in one bulk operation without performance penalty). This was originally designed to categorize sector kinds in FAT, however the categories turned out to be common enough to be used for just any file systems as well. (Please don't take this description as a reference, this is really just a loosy overview to help understanding why SD cards are special kind of beasts.)

Cheers,
bzt

[Octocontrabass]

Does this make sense, and if so is it a correct assumption?

As bzt mentioned, the card attempts to categorize sectors based on which part of the filesystem they contain, so your assumption is correct when the card is formatted according to the SD specification. Most SD cards will still function as you've described even when they're not formatted according to the SD specification, but there are documented cases of cards misbehaving and losing data that way.

If this is a correct assumption, then I don't need to worry about it being an SD Card in the subject this is a reply to, correct?

If you're able to detect that a particular storage device is an SD card, you should attempt to warn the user when it's not formatted according to the SD specification. Other than that, I don't think you need to worry about it.

[zaval]

@PeterX: just ignore zaval, he is obviously trolling.

@zaval: PeterX did not "command" you, he did not pretend to be a moderator either, he just kindly asked you. I understand that you're from Russia, and you're not a native English speaker, but surely you can comprehend the meaning of "please". PeterX wrote "please stop" and "Please play bad guy elsewhere."
You do see the "please" in both, don't you?

Cheers,
bzt

It's rather funny, how you pretended to not notice my on topic screenshot and post before it, both illustrating your numerous mistakes in understanding the specification, but still found the time to come up and generate this off topic nonsense, literally noone cares about.

About your statement, you've made and I highlighted - it yet once shows you are unable to perceive written information, because where I am from is written straight under my profile picture. I am as from russia as you are from Romania and as your understanding the discussed things is correct. Yet, you haven't changed the idiotic thread title. Brendan was so right about you. You literally aren't worth a second of attention. what I wrote here, was for other people though, that may happen to get into trouble of trying your horrid bootboot thing.

[bzt]

Okay, I'm bored, so let's play a bit!

It's rather funny, how you pretended to not notice my on topic screenshot and post before it, both illustrating your numerous mistakes

"Numerous"? "Mistakes"? ROTFL! Your screenshot illustrates you can have different tables on different disks, something that nobody ever questioned nor argued.

Let's reiterate the questions to refresh your memories, shall we?

starting without ESP may be easier.

Tell me, how do you boot under UEFI without ESP?

Still waiting for that explanation!

that modifying ESP in some circumstances is harder than an ordinary FAT volume.

Harder how and when?

Still waiting for your answer.

GPT may be unavailable for some (virtual) disk sizes.

Interesting, show me such a case!

Still waiting for such a showcase.

SD cards cannot be formatted with it, without breaking their standard.

You haven't showed a tool which refuses to use GPT on SD cards, and a configuration where SD card does not work with GPT. We are still waiting for those.

Meaning if your storage has GPT (point 1), then EFI shouldn't and won't parse the legacy tables (point 4). Nobody cares if you have another disk which is not the boot disk.

So you see, we are talking about ONE disk, of course you can have different tables on different disks, but we are talking about how the first FS0 (and ONLY the FS0) file system gets mapped from the partitioning tables. And that's because UEFI firmware won't merge more ESP marked partitions into a single FS0.

I kindly ask you to focus on the questions above, and try to answer them all as an intelligent man would.

Cheers,
bzt

[zaval]

Your screenshot illustrates you can have different tables on different disks, something that nobody ever questioned nor argued.

then why you argued with me at all? I, from the beginning, meant, addressing that user, having problems with bootboot, that he can try non-GPT, non-ESP scheme/volume, - it's easier and certainly works, oppositely to what you said to him. and I pointed to your wrong statements, you've made, replying to him:

Not sure what disk utility you're using, but you should create a GPT disk, with a partition that is FAT formatted and copy the three files above to that system partition. Change the type to EFI System Partition (this is important, otherwise EFI won't recognize it). The BOOTBOOT User's Manual Appendix has an example how to use fdisk and mkfs.vfat for this.

this is my response to the above false:

just for the note, despite bzt scares you, that you are required to mark a FAT partition as ESP and use only GPT, it's not true. you can create MBR with an ordinary FAT partition and be sure - it will be recognized by UEFI. since you are only at the start, I'd go this way (it's easier and maybe you'd have less troubles).

then you started to argue with me, telling that with GPT, only GPT is recognized and without ESP, no booting is possible and resort path \efi\boot\bootXXX.efi is the smartest way. and now, trying to slip away from admitting you were wrong (with all points ), you say you meant one disk. but "one disk" makes no sense here, in the context of this argument, of what you said before (the quote above and below too). talking about some imaginable "boot disk" from your fantasies, doesn't make any sense too. forging some more new notions and terms as "ESP merging" - is a complete hallucinating nonsense.
the point was no, you don't need to necessary make a GPT, you don't need to necessary mark FAT volume ESP and you shouldn't use resort path \efi\boot\bootXXX.efi on non-removable storages, especially for the installed loader. on the latter later, and here, yet some of your balderdash from the same song.
...

Meaning if your storage has GPT (point 1), then EFI shouldn't and won't parse the legacy tables (point 4). Nobody cares if you have another disk which is not the boot disk.

One disk always has a single partitioning scheme (a so called Hybrid GPT/MBR is a non-standard lamery and shouldn't ever be considered). if it's GPT, there CANNOT be MBR (Protective MBR is a part of GPT) over there. if all the time, you were talking about "one disk", then you were talking nonsense. ah, wait, you were!
...

No, the UEFI spec says that firmware must recognize volumes only in the GPT if there's a GPT.
Read the spec "Partition Discovery", MBR partitions should not be and are not recognized when there's a GPT.

...

Nope, you must mark that FAT partition in MBR as 0xEF. The UEFI spec is pretty clear about this one. Read sections 5.2.1 Legacy Master Boot Record (MBR) and 12.3.2 Partition Discovery. If your firmware recognizes ESP without a valid 0xEF type, then good for you, but most EFI machines out there won't (and according to the spec they shouldn't). And if you have a GPT, then MBR shouldn't be used at all.

these all are wrong statements. there is no "boot disk" in UEFI, all disks are considered, all are inspected, and both GPT and MBR may coexist. even without ESP on ANY.

Tell me, how do you boot under UEFI without ESP?
...
Still waiting for that explanation!

Because you still can't read? The screenshot and explanation, accompanying it, show the setup in which NONE disks and volumes on it contains ESP, STILL it is pretty much bootable. And this is in a PURE UEFI, btw. How is it possible? hmmm, maybe because ESP per the spec is something, that is expected to be set up, but is not something, whose absence does prevent FW from booting. after all, ESP CAN BE YET NOT CREATED. also, it's a convention, technically it's just a FAT partition, conventionally used for storing OSLs. still the latter may well reside in other volumes.

this comment, in the original thread, I stopped to visit, shows you clearly don't understand things.

with the OS installer, one just sets up BootXXXX variable, the user still can go and change the order

Exactly. Why do you want to take that away from the users? A few sentence earlier you were saying "the user chooses what the default would be".

BootXXXX variables don't define Boot Order and hence - the default, they register an OSL for the UEFI Boot Manager, so that it's aware of them and can load them. every non lame OSL must use this and only this mechanism. The boot order is defined by the BootOrder variable, - this is what user ultimately has control over, to establish the boot order they wish. hard to get, eh?
There is a Load Option descriptor, connected with every BootXXXX variable, that contains Device Path (FilePath, FilePathList array in fact, with the fisrt element - a path to the OSL - required) to your loader, and, possibly, - Device Path to the OS boot volume/directory - the latter is OS specific. The FilePathList[0] is required and it's how UEFI Boot Manager finds normally an OSL. It contains a path to the OSL file in an ESP directory or an ordinary FAT volume. both will work just fine. that's HOW YOU CAN BOOT WITHOUT ESP. GOT IT NOW? (below, is more if didn't).

So you see, we are talking about ONE disk, of course you can have different tables on different disks, but we are talking about how the first FS0 (and ONLY the FS0) file system gets mapped from the partitioning tables. And that's because UEFI firmware won't merge more ESP marked partitions into a single FS0.

fs0 isn't any special. in fact, ironically, it's a volume from the MBR disk in the example. UEFI DOESN'T MERGE ESPs OR ANY VOLUMES AT ALL! it's your fantasies, not closely related to the specification or common sense. in the example, NONE of the volumes are ESP, can't you get it, jesus christ?!! if you had 10 ESPs and 10 ordinary FAT partitions, residing in GPT and MBR, they all would get enumerated as 20 volumes - fs0-fs19, in no particular order and all would be equally accessible and legitimately bootable. no "boot disk", no "merging ESP (wtf is this at all, again smoking weed?)", no special meaning for fs0. just a bunch of accessible, at the file level, volumes.
let's try yet once - UEFI inspects all storage devices it discovered and tries to determine what's partitioning scheme every of them in. it checks first for GPT, then El torito and then MBR. then it enumeartes partitions and volumes on those disks, all of them. then looks at the FS in those. where it finds FAT FS, it installs simple fs protocol on it and lets thus read/write from/to them by OSLs. for others, only block I/O protocol is installed for the raw access.
Boot Manager processes BootXXXX variables, in the order, established by the BootOrder variable. for every BootXXXX (BootOrder variable is an array of numbers, each of which shows its BootXXXX index, i.e. if the BootOrder[0] == 6, then it means, that the first Load Option to try is Boot0006 variable). it tries to load and run the OSL, pointed by the BootXXXX Load Option Descriptor. Normally, the first BootXXXX works, so its OSL takes control over, by exiting Boot Services and then starts OS.
And now ATTENTION: ONLY IF, there is no valid BootXXXX, that resort path \efi\boot\bootXXX.efi MAY BE tried. BUT MAY BE NOT! AT ALL, EVEN IF THERE IS NO VALID LOAD OPTIONS (BootOrder, BootXXXX).It's optional for non-removable devices, what you stick with, - is optional and may be not used. moreover, removable devices in this resort attempt will be tried before non-removable devices.

It is expected that on a non-removable media device, a complete FilePath can be used which includes sub directories and a file name for the boot target and the platform will boot using this FilePath according to normal system policy.
However, in the case where all the Boot#### variables that are referenced in the BootOrder variable point to devices that are not present, the boot devices have timed out, the specific boot file did not exist, or there was no valid boot variable, default boot processing behavior may optionally occur.
This default boot processing will consist of the boot manager searching non-removable media that supports the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL or EFI_BLOCK_IO_PROTOCOL. In general the boot manager will search all candidate media but platform policy may optionally limit the search to a subset of all possible devices connected to a given system; choices for such policy limits are implementation specific.

Read the quote carefully, with the emphasis on the highlighted. The only above quote from the specification is enough to get how lame and wrong the approach you have taken and called "the easiest, smartest, bestest" is. as it's said, "sapientis sat", but it's not about you.

GPT may be unavailable for some (virtual) disk sizes.

Interesting, show me such a case!
...
Still waiting for such a showcase.

last time I faced with this was with diskpart, it rejected to create GPT, the size of the disk was less than 1GB, I don't remember the exact size.

PS. here is yet another picture for you. the size of an attempted disk is 32MB

SD cards cannot be formatted with it, without breaking their standard.

You haven't showed a tool which refuses to use GPT on SD cards, and a configuration where SD card does not work with GPT. We are still waiting for those.

SD Specifications, Part 2, File System Specification - defines MBR/FAT for SD cards.

SD Formatter, the official tool for formatting SD cards from SDA, doesn't let you format GPT, non-FAT.

I faced in my experience an SD card, that worked improperly being formatted with ext4, and returned to normal operation after reformatting with SDA Formatter.

You've been told many times, by many people, that this incompliant formatting MAY or MAY NOT cause malfunctioning the card or slowing it down, or other instabilities. most often, people messing around non-FAT formatted cards, blame cards as "counterfeit", when they start to malfunction. it's indistinguishable. But the specification is not. so, if you can't get this, then PLEASE, enable your brain.

[bzt]

then why you argued with me at all?

Because I believe even the the saddest troll is not hopeless and not a lost cause. What man is a man who does not make the internet a better place?

I, from the beginning, meant, addressing that user, having problems with bootboot, that he can try non-GPT, non-ESP scheme/volume

Here it goes again for the last time, trying to explain the obvious to you:

GPT is expected by UEFI, and it is required by BOOTBOOT (translation: no, he can't try non-GPT scheme), but you'd be a fool not to use it because you can't use legacy partitions with large disks, and GPT is the de facto standard used by all mainstream OSes. It's just a matter of time when legacy support gets removed (from firmware and OSes). We have a saying that fits you perfectly: "he tries to pee against the wind".

ESP is required by UEFI to locate boot files. There's no way to boot without a recognized FS0 volume (translation: no, he can't try non-ESP volume, ESP is a must). Not setting 0xEF type for legacy partitions might work, but hoping that all firmware will support this hack is just foolish. There's absolutely no price for setting the partition type correctly, so what's your point anyway? Why shouldn't we use ESP the way UEFI spec describes it? There's absolutely no benefit not doing so, but in turn you'd risk that certain firmware won't boot your OS. So thanks, but no, thanks.

I'll keep GPT with correct partition types and I'll advise anybody planning to run their OS on real hardware in the foreseeable future to do so.

SD Formatter, the official tool for formatting SD cards from SDA, doesn't let you format GPT, non-FAT.

No. It's not that SD Formatter doesn't let you, it is that SD Formatter can't do. Show us a GPT partitioning tool that refuses to work with SD cards!

last time I faced with this was with diskpart, it rejected to create GPT, the size of the disk was less than 1GB

This is just an artificial limitation created by Microsoft in their tool to force you to buy new and more expensive disks. There's absolutely no technical reason behind it. Don't use Microsoft tools Any other partitioning tool are happy to create GPT for smaller disks, because you can, here's for example 1MB (MUCH less than 1GB):

Code: Select all

$ dd if=/dev/zero of=test.bin bs=1024 count=1024
1024+0 records in
1024+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.0253244 s, 41.4 MB/s
$ fdisk test.bin

Welcome to fdisk (util-linux 2.35.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0x1a4acca5.

Command (m for help): g
Created a new GPT disklabel (GUID: 5CF8224A-FAD9-AD4B-A6A1-1C4F8AE7305C).

Command (m for help): p
Disk test.bin: 1 MiB, 1048576 bytes, 2048 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 5CF8224A-FAD9-AD4B-A6A1-1C4F8AE7305C

Command (m for help): w
The partition table has been altered.
Syncing disks.

$ hexdump -C test.bin
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001c0  02 00 ee ff ff ff 01 00  00 00 ff 07 00 00 00 00  |................|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|
00000210  c1 25 6c ff 00 00 00 00  01 00 00 00 00 00 00 00  |.%l.............|
00000220  ff 07 00 00 00 00 00 00  22 00 00 00 00 00 00 00  |........".......|
00000230  de 07 00 00 00 00 00 00  4a 22 f8 5c d9 fa 4b ad  |........J".\..K.|
00000240  a6 a1 1c 4f 8a e7 30 5c  02 00 00 00 00 00 00 00  |...O..0\........|
00000250  80 00 00 00 80 00 00 00  86 d2 54 ab 00 00 00 00  |..........T.....|
00000260  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000ffe00  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|
000ffe10  ca 0b 1e 4c 00 00 00 00  ff 07 00 00 00 00 00 00  |...L............|
000ffe20  01 00 00 00 00 00 00 00  22 00 00 00 00 00 00 00  |........".......|
000ffe30  de 07 00 00 00 00 00 00  4a 22 f8 5c d9 fa 4b ad  |........J".\..K.|
000ffe40  a6 a1 1c 4f 8a e7 30 5c  df 07 00 00 00 00 00 00  |...O..0\........|
000ffe50  80 00 00 00 80 00 00 00  86 d2 54 ab 00 00 00 00  |..........T.....|
000ffe60  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Works perfectly.

Cheers,
bzt

[PeterX]

You both have good (and verbose) points for either GPT/ESP or MBR.

May I view it from a different angle? I think UEFI is cool! Having full 64bit support, having a C interface etc. Isn't that all great!? And regarding GPT/ESP: Having up to 128 and very large partitions, having a mechanism for loading from a default file system from/with BIOS, that's phantastic, isn't it?

Greetings
Peter

[zaval]

then why you argued with me at all?

Because I believe even the the saddest troll is not hopeless and not a lost cause. What man is a man who does not make the internet a better place?

no, because you wanted to show you are a smartass, when in fact, you made a lot of mistakes there. and judging by your answers, you keep not getting. not surprised.

I, from the beginning, meant, addressing that user, having problems with bootboot, that he can try non-GPT, non-ESP scheme/volume

Here it goes again for the last time, trying to explain the obvious to you:

GPT is expected by UEFI, and it is required by BOOTBOOT (translation: no, he can't try non-GPT scheme)

he can. that what I meant - to not try your horrid lame thing and go his initial way, own OSL, starting with an easy to start MBR disk.

but you'd be a fool not to use it because you can't use legacy partitions with large disks, and GPT is the de facto standard used by all mainstream OSes. It's just a matter of time when legacy support gets removed (from firmware and OSes). We have a saying that fits you perfectly: "he tries to pee against the wind".

MBR will never be removed from UEFI due to 1) backward compatibilty and 2) there are places, when it is STILL and WILL BE a standard partitioning mechanism or de facto standard. SD cards, USB thumdrives respectively.

Here it goes again for the last time, trying to explain the obvious to you:

let's see, you "explain the obvious" that without ESP there is no booting. I show you 1) quotes from the spec, where in Boot Mechanisms, there is no a word about looking up only in ESP and oppositely, - clearly is said, that all FAT volumes are handled at the FS level and Load Options contain full FilePaths on these handled volumes (not just ESP ones, but ANY, where simple fs protocol is installed) and 2) screenshot of the running pure UEFI setup, based on the reference implementation, with 2 non-ESP volumes, perfectly bootable. sooo, what's "obvious" here? again weed?

ESP is required by UEFI to locate boot files. There's no way to boot without a recognized FS0 volume (translation: no, he can't try non-ESP volume, ESP is a must). Not setting 0xEF type for legacy partitions might work, but hoping that all firmware will support this hack is just foolish. There's absolutely no price for setting the partition type correctly, so what's your point anyway? Why shouldn't we use ESP the way UEFI spec describes it? There's absolutely no benefit not doing so, but in turn you'd risk that certain firmware won't boot your OS. So thanks, but no, thanks.

keeping parroting this idiocy, doesn't make it the truth. but you can keep on. You are horrible at perceiving information or you are trying too hard to pretend to look "right", even when have been shown to be wrong.

yet once, the last time, - I showed you an example when you can boot with pure UEFI without ESP. ESP is an OS concern, it may be yet not created, FW won't fail to boot if there is no ESP. there is no such a place in the spec, claiming it will. if the screenshot and numerous quotes from the specification have no effect, it's your problems.

- there is no special meaning for fs0. it's just the first enumerated FAT volume. it's not necessarily ESP. And in the example above, it's not ESP, not even GPT disk. it's MBR. and just because I fed qemu this disk first, so EDK saw it as first. there is no boot disk either.
- ESP can be yet not created, UEFI can't fail just because of this only fact. in fact, UEFI will work if there will be no ESP at all. it's not prohibited in any place in the spec. and I showed a working example, USING REFERENCE implementation, everything else is based on.
- there might be more than one ESP. from 0 to infinity.
- ESP is just a conventional volume for storing OSLs with "fixed" FAT version, not more.
- UEFI CLEARLY describes Boot Mechanisms and there is NO A WORD ABOUT, that it only looks up ESP over there.
- UEFI CLEARLY states it does recognize and HANDLES ALL FAT12/16/32 VOLUMES DISCOVERED

I'll keep GPT with correct partition types and I'll advise anybody planning to run their OS on real hardware in the foreseeable future to do so.

you'd better to not advise where you have no f&cking idea!

SD Formatter, the official tool for formatting SD cards from SDA, doesn't let you format GPT, non-FAT.

No. It's not that SD Formatter doesn't let you, it is that SD Formatter can't do. Show us a GPT partitioning tool that refuses to work with SD cards!

the specification says MBR should be used, they don't use anything except it in their formatter. this is how the logic of rational people works and how a compliant tools should do. or you think, you are the only genius to use GPT? they, unlike you, created a tool, that makes, formatted by it cards, WORK. and not suddenly fail. as may be the case, when some arrogant ignoramuses, think they may decide what in the spec is OK and what is "marketing BS", so they create lamery, that does only one thing well - creates problems for poor users.

and btw, MBR for SD cards is more than enough. GPT is not needed there. it's even a poor choice, since it requires putting a duplicate structures at a specifical place, worse - at the end of LBA space. needless to say, that for flash based devices, it's pointless at the very least. btw, I like GPT, but this requirement is not what I like, even old FAT is more flexible with this, since you may not create duplicate FATs. It's not even problematic from the point of view of remapping sectors (the end of LBA isn't any worse than others in this case), it's problematic in terms of "size" itself and "size discovery". the fisrt is obvious - if the flash block where the end of LBA was mapped got woren out and there is no more blocks from the reserve, the controller has nothing to do as shrink the reported size of the card. this makes GPT invalid. and because of its unnecessary "size accounting" (LastLba), the software needs to do something with this. not too critical, but still an unnecessarily created problem. since the ultimate size reporter is an underlying (disk) controller, there was no need to include yet another size accounting place in the partitioning scheme. the second problem is more obscure, but in practice, it's there - despite the card can report its size, still this GPT size, if it's not like the real size of the card (which almost always the case when flashing those images onto eMMCs/SD cards), again, users get into troubles like "why my 64GB eMMC is reported as only 4GB and I cannot resize it no matter what I do". I saw such reports and don't know what's the original culprit, but apparently, it happens, when GPT (wrong, smaller) size is taken as the ultimate truth. GPT was devised for HDDs.

your multiple ignoring pointing to the spec. requiements is clowning. show yourself what you wish.

last time I faced with this was with diskpart, it rejected to create GPT, the size of the disk was less than 1GB

This is just an artificial limitation created by Microsoft in their tool to force you to buy new and more expensive disks. There's absolutely no technical reason behind it. Don't use Microsoft tools Any other partitioning tool are happy to create GPT for smaller disks, because you can, here's for example 1MB (MUCH less than 1GB):

I knew, you will babble something in this spirit. let me remind you, what we were talking about. I said - there are tools, that can expose limitations on GPT creation, for example - virtual disks of small sizes. It was mentioned by me just as a side note, to the list of possible "troubles for beginners". we WEREN'T talking about if these limitations are "artificial" or not. you demanded me to show, I showed. I didn't ask you to analyse the nature of this limitation. every tool has some limitations and explanations why they're there. but we were not talking about this, only about the existence of such limitations.

more important is the fact and it's laughable, that you both claim to target "embedded" machines with bootboot, that means SD cards may be used often, AND demand using a non-standard to it partitioning scheme. btw, there are yet bare NAND chips in the embedded segment. for them, GPT is plainly stupid btw. unless you wanna kill the chip quick.

I am off of this idiocy.

[nullplan]

Either specifications are important or only real-world implementations are important. Neither of you can have it both ways. bzt, you cannot claim to always stick to specs and then use anything but MBR+FAT for SD cards. That is because the SD card spec standardizes both. The fact that alternatives happen to work most of the time is immaterial to this. And zaval, you cannot keep banging on about your particular UEFI implementation happens to recognize mislabelled partitions when that is not guaranteed by the spec.

Now I've said my piece, I'm quitting this thread, lest I be sucked into the sandbox as well.

[bzt]

Neither of you can have it both ways. bzt, you cannot claim to always stick to specs and then use anything but MBR+FAT for SD cards.

I see what you mean, but there's a big difference. Partitioning and file system interpretation are implemented in the UEFI firmware, which you cannot change, while interpreting SD sector data is up to your code, which you naturally can change. Following the UEFI spec is hardwired in your machine, while following the SD card spec is up to your code, and to your code only (and there are 100 millions cards used without FAT, which clearly means this part of the "spec" is just a marketing bullshit). Just for the records, you could use a non-FAT file system for ESP too, if you're Apple or some other IT giant capable to force manufacturers. It's not that only FAT can be used (for both), but it's only FAT supported because of the lobby of MS. Big difference.

Otherwise I agree, this topic goes nowhere, zaval is incapable of intelligent posts, he's just throwing personal insults. Sad.

I kindly ask the moderators to lock this topic. Thanks.
bzt

[StudlyCaps]

zaval is incapable of intelligent posts, he's just throwing personal insults. Sad.

You're both as bad as each other.

[iansjack]