Brendan wrote:GRUB's MBR ignores the partition table and loads GRUB's stage 2; it doesn't check the partition table and load the first sector of an active partition (which I assume is the goal here).
But how it can load something from an active partition without checking partition table?
Antti wrote:There is so much controversy that this project probably does not make sense. Actually, the project goal makes sense in itself but there are too many things to take into consideration. Maybe it is better to leave the MBR as a part of the real boot manager. The project is halted for now.
May be it is better to say that the project is paused for some short time?
I mean it is a nice idea to show to all osdevers an open process of a boot manager development (or at least it's first stage).
And to encourage you for resuming your efforts I want to share my understanding of the booting process. There is a common starter for every OS and it sits right in the first disk's sector. It's also true for USB and floppies. But may be UEFI has something different in some incompatible mode, I just don't know. However, to be compatible with many existing bootloaders, UEFI just has to have support for the same common starter and preserve the MBR as it is. So, the first thing to decrease the level of "so much controversy", is the clear understanding of the common starter and MBR roles.
The common starter's role is just to start some more specific starter (or loader). The goal is relatively simple and then it allows us to make a common starter nice enough to have some descriptive error messages in it. But before the goal hunting starts there should be some understanding of the whole picture with the common starter and a more specific ones. First of all we need to remember that the variety of things that can be loaded by a bootloader it too wide to deal with it in just 512 bytes. So, in our picture we can draw some small and very restricted area with the name "common starter" and leave all the rest of the picture for other things. The other things are mostly those more specific loaders, mentioned above. They are created with the information about the actual system to be loaded into computer's memory. When the actual system is, for example, Linux the more specific starter knows the sequence of actions it should execute and is able to locate additional code, that implements those actions. It is also true for any other system, like GRUB, Windows, your OS or whatever - the more specific loader always has information (it knows) about the actual loading process and all the helper code, required during the loading.
And here we can see an important difference between the common starter and a more specific one. The difference is in the amount of information they have to accomplish their tasks. The first has enough information to select and load an appropriate more specific loader. And the second has enough information to select and load all the code, that is required to properly organize and support a target system's data in the computer's memory.
Finally, after there is the clear picture with common loader, more specific ones and actual system bootstrapping code, we can look at some technical details. The first thing you need to consider is the location of the more specific loader. To find such information it is required to understand the partition table. It shows us at least one very useful thing - the location of an active partition. When we know the place where the active partition is, we can relatively safely assume that the bootloader in it's VBR (volume boot record) is just the actual more specific loader we are looking for. But if there's no active partition (and partitions at all, like is the case with floppies), it is much better to place the more specific loader right in the first sector of such disk, because the common starter just have no enough information to find the more specific one. So, we have to restrict the usage area of the common loader to the disks that have partition tables. And if somebody wants to load his system from a floppy, then he should know that it is better to use a more specific loader instead of the common one in such case.
Next it is possible to discuss the actual technics for the tasks of parsing partition table, loading sectors and dealing with errors, but I leave those areas to more experienced developers (like Brendan) because my scope of acquittance with such details is narrower than other people have.
Antti wrote:
The conclusion:
- Worldwide acceptance? A nice dream.
- Boot Manager Partition? Probably a good idea.
- Standard interface between MBR and Boot Manager? A good idea.
- Same MBR code for "Legacy partitions" and "GUID partitions"? Maybe a bad idea.
- Chain of trust? An unknown area.
- Worldwide acceptance? A nice dream.
Why not? The open development process for the common loader is a rare bird. May be this one is even the first on earth.
- Boot Manager Partition? Probably a good idea.
It's good for a general boot manager, but not for a specific system loader. Just because of the nature of a specialized and a generalized code.
- Standard interface between MBR and Boot Manager? A good idea.
The standard interface here is the environment left after the bootloder's code is loaded by the common loader. And this environment has been already defined long ago.
- Same MBR code for "Legacy partitions" and "GUID partitions"? Maybe a bad idea.
Why not? The difference is just in detection and parsing parts of a code. Both are easy to implement and not very space consuming.
- Chain of trust? An unknown area.
For me it's also something still undefined. But may be I even know it, but with some different name.
