Generic bootloader

[bluemoon]

Command line arguments are a method, not an end goal. Specifically, in the "separate boot manager" scenario, there is no way for the boot manager to pass to the boot loader that it would like to load "bcos-17" instead of the newly installed "bcos-18" (because the latter has broken this machine, for example); or that you would like to disable the graphical boot splash (because the machine is hanging during boot and you want to diagnose why)

It depends on how you present the same stuff to end user.
It can be done in this way:

Say, when you upgrade from BCOS17 to BCOS18, you have the "magic switch" within the BCOS's private scope but the boot manager should have no idea about it.

So, To the user you choose to boot from "windows, linux, or BCOS", then the BCOS boot loader could let you choose from kernel 17 and 18.


It's just a trade off between user friendly (mix them into single step) or clean design(but then require 2 click from user)

[Brendan]

Hi,

In addition, an OS should be able to easily change its own boot loader's configuration; but should not be able to touch the boot manager's configuration or any other OS's boot loader configuration. The idea of combining boot manager with boot loader is a very poor design that fails very easily for dual-boot systems (e.g. where multiple different OSs think they "own" the boot configuration and screw each other up) and is also a security disaster.

This is one of the reasons I emphasized every boot option being defined in it's own file; so that OSes don't accidentally trample each other. True, an OS could still screw everyone over by modifying the default= line in the boot manager configuration each time it starts up... but, then again, it could replace the MBR with it's own (with itself marked as primary) each boot...

When you install an OS; the installer should give you a choice:

• Install a default boot manager in the MBR that doesn't do anything except chain-load the OS's boot loader (for PC BIOS systems), or set the appropriate boot variable (UEFI); or
• Don't.

For the second case, the user has to tell their boot manager (whatever it happens to be) about the new OS. The OS should not know or care what the boot manager is. If whichever boot manager the user chose to use actually does have some sort of file (which seems extremely unlikely for most of them), the OS (including the OS's boot loader *and* the OS's installer) should never touch it.

For some examples of actual boot managers:

• GAG
• Plop
• OSL2000
• MasterBooter
• BootIt(r) Bare Metal - Boot Manager
• Smart Boot Manager
• System Selector
• Multiple Boot Manager
• Partition Boot Manager

These are just what I found in about 10 minutes. I didn't examine each of them in great detail; but as far as I can tell they are all "pure" boot managers (e.g. select which partition to chainload, without any boot loading).

I don't understand why a well designed OS would need command line arguments (is it just because Linux is an ugly mess that expects end users to know more than kernel developers, and people make the mistake of assuming it's a good idea?). I also don't understand why a boot manager would need to run entirely in real mode, but I don't really care much because (hopefully) nobody here is talking about implementing a boot manager

Command line arguments are a method, not an end goal. Specifically, in the "separate boot manager" scenario, there is no way for the boot manager to pass to the boot loader that it would like to load "bcos-17" instead of the newly installed "bcos-18" (because the latter has broken this machine, for example); or that you would like to disable the graphical boot splash (because the machine is hanging during boot and you want to diagnose why)

Code: Select all

        Example Boot Manger Version 99

        1) Windows
        2) Linux
        3) BCOS

        Please select an OS to boot: 3

Starting BCOS.

Code: Select all

BCOS Boot Loader Version 123

Detecting memory: Done
Initialising nyan cats: Done
Examining kernels: Multiple kernels detected!

     1) BCOS kernel version 1.2.3.4 (untested)
     2) BCOS kernel version 1.2.2.1 (known good kernel)
     3) BCOS kernel version 1.1.1.0 (known good kernel)

     Please select a kernel to use: 1

Loading BCOS kernel version 1.2.3.4
Starting kernel
...

How is this hard to comprehend?


Cheers,

Brendan

[rdos]

Code: Select all

        Example Boot Manger Version 99

        1) Windows
        2) Linux
        3) BCOS

        Please select an OS to boot: 3

Starting BCOS.

Code: Select all

BCOS Boot Loader Version 123

Detecting memory: Done
Initialising nyan cats: Done
Examining kernels: Multiple kernels detected!

     1) BCOS kernel version 1.2.3.4 (untested)
     2) BCOS kernel version 1.2.2.1 (known good kernel)
     3) BCOS kernel version 1.1.1.0 (known good kernel)

     Please select a kernel to use: 1

Loading BCOS kernel version 1.2.3.4
Starting kernel
...

How is this hard to comprehend?

I'd like it to be like this:

Code: Select all

        Example Boot Manger Version 99

        1) Windows
        2) Linux
        3) BCOS kernel version 1.2.3.4 (untested)
        4) BCOS kernel version 1.2.2.1 (known good kernel)
        5) BCOS kernel version 1.1.1.0 (known good kernel)

        Please select an OS to boot: 3

Starting BCOS.

Or even better:

Code: Select all

        Example Boot Manger Version 99

        1) Disc 1, partition 1
        2) Disc 2, Partition 2
        3) Linux
        4) BCOS kernel version 1.2.3.4 (untested)
        5) BCOS kernel version 1.2.2.1 (known good kernel)
        6) BCOS kernel version 1.1.1.0 (known good kernel)
        7) RDOS normal boot
        8) RDOS ok.bin

        Please select an OS to boot: 3

Starting BCOS.

By doing some smart searches on the boot-sectors, it could be clarified (still without user input and configuration files):

Code: Select all

        Example Boot Manger Version 99

        1) Windows on disc 1, partition 1
        2) Rescue tool on disc 2, partition 2
        3) Linux
        4) BCOS kernel version 1.2.3.4 (untested)
        5) BCOS kernel version 1.2.2.1 (known good kernel)
        6) BCOS kernel version 1.1.1.0 (known good kernel)
        7) RDOS normal boot
        8) RDOS ok.bin

        Please select an OS to boot: 3

Starting BCOS.

Also, in the first case, I have no idea how you know how to boot Windows in the boot loader, since Windows is typically chainloaded from some partition. The partition could just as well contain a "missing operating system" loader, a DOS-loader, or system rescue tool as a Windows loader. Or do you expect the end-user to know how Windows has installed itself on this particular machine??

[rdos]

Ideally, when a boot-loader / manager is first started, it should scan boot-sectors for know operating systems / tools, scan the directory structure for know boot-files (with multiboot headers, or new generic bootloader headers), and then present the results in a full list to the end-user something like this:

Code: Select all

    1) Disc 1, partition 1 (suspected Windows, NTLDR)
    2) Disc 2, partition 2 (suspected recovery, RECOV)
    3) Disc 2, partition 3 (unknown, SOMELDR)
    4) Disc 1, partition 1 (/someos.bin, multiboot image)

   Select OS too boot:

Next, the user could select to associate the entry with a name:

Code: Select all

    Input name of entry: 

Then, the next time the boot menu would look like this: (say the user said entry 1 was Windows XP):

Code: Select all

    1) Windows XP
    2) Disc 2, partition 2 (suspected recovery, RECOV)
    3) Disc 2, partition 3 (unknown, SOMELDR)
    4) Disc 1, partition 1 (/someos.bin, multiboot image)

   Select OS too boot:

[Brendan]

Hi,

I'd like it to be like this:

That's fine - just contact everyone that's created a Boot Manager (see the partial list of URLs in my last post) and ask them all to agree on a way of standardising this; then convince them all to implement it. Of course this would only cover boot managers for "PC BIOS" - you'd need to convince the people responsible for the UEFI standards too, then OpenFirmware, then coreboot, then...

Let us know when the entire world has signed up...


Cheers,

Brendan

[bluemoon]

Ideally, when a boot-loader / manager is first started, it should scan boot-sectors for know operating systems / tools, scan the directory structure for know boot-files (with multiboot headers, or new generic bootloader headers), and then present the results in a full list to the end-user something like this:

By definition, files (and file layout) for Hobby OS are excluded in the above list.

[rdos]

Hi,

I'd like it to be like this:

That's fine - just contact everyone that's created a Boot Manager (see the partial list of URLs in my last post) and ask them all to agree on a way of standardising this; then convince them all to implement it. Of course this would only cover boot managers for "PC BIOS" - you'd need to convince the people responsible for the UEFI standards too, then OpenFirmware, then coreboot, then...

Let us know when the entire world has signed up...


Cheers,

Brendan

I think I fail to understand the above objection. I have quite elaborate disc tools (Paragon Partition magic), and I have used GRUB on various machines, so I know that it is possible to boot-up various chainloaded OSes like Windows by looking at the boot sector (this doesn't need any interaction with Windows boot-loader). So for Windows, it is easy to solve. Just look at the relevant fields in the boot sector, and you can identify Windows. If this is not possible, you can let the end user try to do chainloading and see what happens. This is in fact what a typical GRUB user does when configurating dual boot with Windows, expect it will be true trial-and-error because he/she doesn't have information of what the boot-sector looks like, and some boot-sectors could be harmful to run (system recovery).

And when it comes to multiboot compliant kernels, those typically too must be added to the GRUB configuration file, when they could be found automatically with a decent boot manager.

[rdos]

Ideally, when a boot-loader / manager is first started, it should scan boot-sectors for know operating systems / tools, scan the directory structure for know boot-files (with multiboot headers, or new generic bootloader headers), and then present the results in a full list to the end-user something like this:

By definition, files (and file layout) for Hobby OS are excluded in the above list.

Do you mean that typical Hobby OSes doesn't use multiboot? In that case, they will need to use it (it's not hard), or alternatively, you define a new standard for generic bootloader, which compliant OSes must add.

It's a given that a boot manager cannot load OSes that doesn't adapt any boot standards.

[bluemoon]

In my opinion, an OS do not necessary implement multi-boot standard (yes I know it's good) - Example: DOS, BeOS, OS/2, okay probably no one want to run them but their scale is comparable to hobby OS.
The only standard the boot manager care is the partition table (or GPT or whatever UEFI required).

So, it's already at least two people have different expectation for a boot manager (and OS).

[bluemoon]

so I know that it is possible to boot-up various chainloaded OSes like Windows by looking at the boot sector (this doesn't need any interaction with Windows boot-loader). So for Windows, it is easy to solve.

These are hacks and guess based on experimental data, but for the same reason, my rEFI boot manager thinks my OS is a Windows.

[Brendan]

Hi,

That's fine - just contact everyone that's created a Boot Manager (see the partial list of URLs in my last post) and ask them all to agree on a way of standardising this; then convince them all to implement it. Of course this would only cover boot managers for "PC BIOS" - you'd need to convince the people responsible for the UEFI standards too, then OpenFirmware, then coreboot, then...

I think I fail to understand the above objection. I have quite elaborate disc tools (Paragon Partition magic), and I have used GRUB on various machines, so I know that it is possible to boot-up various chainloaded OSes like Windows by looking at the boot sector (this doesn't need any interaction with Windows boot-loader). So for Windows, it is easy to solve. Just look at the relevant fields in the boot sector, and you can identify Windows. If this is not possible, you can let the end user try to do chainloading and see what happens. This is in fact what a typical GRUB user does when configurating dual boot with Windows, expect it will be true trial-and-error because he/she doesn't have information of what the boot-sector looks like, and some boot-sectors could be harmful to run (system recovery).

Imagine someone already has one of those Boot Managers already installed on their computer, and they've got it setup to boot Windows, FreeBSD, Hiaku and DOS. Now imagine that this person wants to install your OS. They do a little research and find out that your OS is so badly designed that (unlike every other OS that has ever existed) it can't use any existing boot manager and they'd have to completely replace the boot manager that they've been using for years; and by the time they've finished laughing at how crappy your OS is they've forgotten all about installing your OS.

Is this how it's meant to work?


Cheers,

Brendan

[Griwes]

Ideally, when a boot-loader / manager is first started, it should scan boot-sectors for know operating systems / tools, scan the directory structure for know boot-files (with multiboot headers, or new generic bootloader headers), and then present the results in a full list to the end-user something like this:

By definition, files (and file layout) for Hobby OS are excluded in the above list.

Do you mean that typical Hobby OSes doesn't use multiboot? In that case, they will need to use it (it's not hard), or alternatively, you define a new standard for generic bootloader, which compliant OSes must add.

It's a given that a boot manager cannot load OSes that doesn't adapt any boot standards.

Huge problem in this post are words "must" and "need to".

[rdos]

Imagine someone already has one of those Boot Managers already installed on their computer, and they've got it setup to boot Windows, FreeBSD, Hiaku and DOS. Now imagine that this person wants to install your OS. They do a little research and find out that your OS is so badly designed that (unlike every other OS that has ever existed) it can't use any existing boot manager and they'd have to completely replace the boot manager that they've been using for years; and by the time they've finished laughing at how crappy your OS is they've forgotten all about installing your OS.

Is this how it's meant to work?

RDOS is multiboot compliant, so if their boot-loader is multiboot compliant it is easy to setup. Otherwise, they would be better off booting it from an USB stick, floppy or CD.

But how do you propose the generic bootloader would handle this situation?

[Griwes]

The point is, generic bootloader has nothing to do with dual-or-more-booting, so it is wrong tool to address this issue.

[rdos]

The point is, generic bootloader has nothing to do with dual-or-more-booting, so it is wrong tool to address this issue.

I don't think so. The only thing the generic boot-loader could do in Brendan's example is to chain-load, and it doesn't take much code to do that, so if the only thing the generic bootloader is able to do is to chain-load, then I can simply conclude that it is redundant.

Another possibility is that the generic bootloader is made for being put into the partition boot sector, and to load some OS within that partition. If that is the case, I'm not very interested as such a design is intrusive in the client's computer, and needs partition tools and such. I think OSes that can only boot with this method are primitive and not worth supporting. Modern OSes are multiboot compliant or UEFI-compliant, and don't rely on having their own hard-drive partitions. That's why Windows is not a modern OS, but rather an intrusive OS much like a virus. Perhaps Microsoft can afford such bad interoperability, but Hobby OS developpers cannot (unless they prefer testers to use emulators).