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:
bzt wrote:
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:
zaval wrote:
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.
...
bzt wrote:
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!
...
bzt wrote:
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.
...
bzt wrote:
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.
bzt wrote:
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.
bzt wrote:
zaval wrote:
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).
bzt wrote:
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.
3.4.1.2 Non-removable Media Boot Behavior wrote:
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.
bzt wrote:
zaval wrote:
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
bzt wrote:
zaval wrote:
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.
Any other partitioning tool are happy to create GPT for smaller disks, because you can, here's for example 1MB (MUCH less than 1GB):
