OSDev.org

bluemoon wrote:I don't think so. Chain-loading mechanism does not require fail-over to next OS.
If I were about to choose my OS from boot manager, and it somehow failed to boot, I want it to halt (with message) but not show up a Windows or Linux on other partition.

As you like. Overwriting loader's area over 7C00h when loading sectors still applies.

Combuster wrote:My point was that it's only practical use is as an MBR, or as a template for other bootsectors.

And that's what a tutorial for! Use as a template for your own filesystem's VBR code if you want. Or use as it is, and load a 2nd stage from a file from your own filesystem.

Don't question it's usability as VBR until you've TESTED IT. Show me details of the bug if you found any, in the meantime stop modifying the wiki page.

And no, it does not support f*cking floppies, nor CHS (LBA support is more than a decade old, and CHS is meaningless on modern media such as pendrives) deal with it.

turdus wrote:Overwriting loader's area over 7C00h when loading sectors still applies.

MBR code has nothing more to do since it passed control to volume boot record. So, there are no bad things in overwriting it's code after that.

Yoda wrote:

turdus wrote:Overwriting loader's area over 7C00h when loading sectors still applies.

MBR code has nothing more to do since it passed control to volume boot record. So, there are no bad things in overwriting it's code after that.

I was speaking of overwriting something above 7C00h. As I wrote, my 2nd stage is loaded to 800h-7C00h, therefore my loader has a limit of 28k. It's because I load the boot partition (or the GPT table) at 7C00h, that should not overwrite the loader. If you're not interested in chainloading (eg. it does not matter for you what's placed at 7C00h), it's not for you.

Solar wrote:<design rant>

Very silently inserting my opinion that no OS should come with a first-stage bootloader of any kind. MBR is user/admin's business, and should never need tampering with once installed. The admin decides whether to use LILO, GRUB, Vamos, or whatever, to boot-select the various installed systems, and the realm of your OS starts with the partition boot sector (if you're chainloaded) or the kernel proper (if you're Multibooted). Provide an option to install a simple chainloading MBR for systems that have no other OS, but don't ever rely on having a say on the MBR contents (i.e. fancy stuff being done by stage 1). Even Microsoft doesn't, or many multi-booting users would be in deep trouble. That they unquestioningly overwrite the MBR on installation is already very bad manners.

</design rant>

This kind of thing would be less of an issue if the Grub/Lilo guys would stop putting their stage 1 in the MBR. Theoretically, all you should have to do in order to re-select GRUB (or whatever) should be to mark your /boot partition as active. There is no reason why GRUB should not live in the volume boot record.

This would also remove the BIOS Boot Partiton monstrosity on GPT systems.

Owen wrote:This would also remove the BIOS Boot Partiton monstrosity on GPT systems.

What monstrosity?

Owen wrote:This kind of thing would be less of an issue if the Grub/Lilo guys would stop putting their stage 1 in the MBR. Theoretically, all you should have to do in order to re-select GRUB (or whatever) should be to mark your /boot partition as active. There is no reason why GRUB should not live in the volume boot record.

1 point was added to your score. Installing GRUB into MBR as default option is a bad policy of *NIX developers. I'm preparing special version of MBR boot loader to resolve this problem. But still now I move GRUB's stage 1 from MBR to VBR to install my MBR boot loader into MBR.

I have discussion about this matter with Solar early. We should understand that OS setup programs replace MBR boot loader to guarantee booting the OS. Perhaps, to give choice to user to install MBR boot loader/to change active partition or not would be better.

Hi,

For booting from partitioned hard disks; in theory, there should be "boot managers" and "boot loaders".

The boot manager is responsible for starting a boot loader, and may be a simple thing that is only capable of starting one boot loader, or could be a more complex thing that presents a menu for the user to choose which boot loader to start from a list. For "PC BIOS" the boot manager lives in the MBR (and possibly the extra space between the MBR and the first partition, and/or other space somewhere else on the disk). For UEFI the boot manager may be UEFI itself or could be a UEFI application. The user should be able to use any boot manager they like, and replace it with something else if they want to without any problems (and without messing with any OS's boot loader).

A boot loader is the first part of an OS's boot code. For "PC BIOS" it should live in the OS's partition (e.g. VBR). For UEFI it has to be a file in the system partition. It should never have a "what would you like to boot" menu (as that's the boot manager's job).

When an OS is installed, the OS installer should install the OS's boot loader and configure any configuration that the OS's boot loader wants. An OS installer must not install a boot manager without the user's permission; but may ask the user if they want a boot manager installed as a convenience (e.g. in case the system has no boot manager).

The problem with GRUB is that it combines "boot manager" with "boot loader". This is a design flaw. When used as a boot loader (e.g. in a VBR) it's a massive pig of a thing with lots of unnecessary features intended for a boot manager; when used as a boot manager it's a massive pig of a thing with lots of unnecessary features intended for a boot loaders; and when used as both at the same time it leads to problems when there's 2 or more OSs fighting for control over their own boot loaders (basically, each OS's screws up the GRUB configuration that other OS's are relying on).


Cheers,

Brendan