Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Hard disk boot - space for extra code
22 views
Skip to first unread message
James Harris
Apr 19, 2012, 2:55:37 PM4/19/12
to
Before starting I should say that this post is not asking for help to
solve a particular problem. Instead I am putting forward some
suggestions for hard disk boot which you guys might be interested in
and just might be interested in discussing.
The goal is to enhance the user experience of the first stage of the
hard disk booting process of a common or garden PC. I'm thinking of a
solution that we could deploy on any normal PC - i.e. one which has no
special hardware or software and which has a disk with an MBR
containing boot code and a traditional four-entry partition table.
What enhancements?
==================
So then, what enhancements? Basically to do things like
* present a specific boot menu
* scan available disks looking for bootable partitions and
offer a choice of those to the user
* maintain a timer and take a default option if a
certain period elapses before a choice is made
* issue meaningful diagnostics if errors occur
* generate informational messages about boot progress
* provide other pre-OS information to the user
For simplicity I'll generally refer to the use of a boot menu below as
that's the most used but by it I mean any or all of the above.
I'll include notes of what I understand are existing solutions.
The problem
===========
The 512 bytes of the normal master boot record (MBR) can contain
enough code to load the flagged-as-active volume boot record (VBR)
using BIOS calls. However, if we wanted the MBR to do significantly
more than just start the VBR the 512 bytes of space is too small
especially when it also has to contain data such as a partition table.
(In this post, for consistency with the above acronyms I'll call a
sector holding an extended partition table an extended boot record,
EBR. This is to keep the terminology simple. I know it does not have
to contain boot code. So, we have the acronyms MBR, EBR and VBR.)
Potential solutions
===================
The various places that extra boot code can be stored are limited and
each has good and bad points. Here is the list I have come up with.
Four schemes:
1. Immediately following the MBR, i.e. from LBA 1 onwards
- easy to find but
- can be overwritten en bloc
- can have specific bytes changed by certain programs
- may not even exist (if unusual partitioning)
2. In a separate partition
- a segregated boot partition is possibly ideal but
- takes away a partition entry from more normal uses
3. In an EBR
- can add 440 to 446 extra bytes of code but
- that may not be enough extra space
- also takes a partition entry in the MBR
4. In the last sectors of the disk
- could be plenty of space here but
- may not exist
- may be overwritten or changed
- would be inaccessible if the disk is too big
Any others of the same type? All the above are intended to work with
the basic disk structure so don't need a VBR to run. Interestingly, I
haven't come across any boot managers which work using the above
options with the possible exception of Grub 1. It apparently uses
scheme 1 at least in part.
However, I have come across other methods of providing a boot-time
menu such as the following. Corrections and additions welcome.
* Let a VBR run and start code within a partition. Then use that
larger code to present a menu to the user. If necessary go through the
loading of another VBR. I think some versions of Windows work this way
where they present a menu taken from the boot.ini file. Probably
requires a Windows partition and can only be configured from a running
copy of Windows.
* Reading from LBA 1 onwards load code which knows about the structure
of a file system in one of the partitions and uses that knowledge to
find a bigger loader from within a partition. I think some versions of
Grub 1 worked this way. Same problems as above.
* Load code from specific sectors within a partition (e.g. Lilo) which
means that if the file that is meant to be in those sectors gets moved
and the sectors get overwritten the boot will fail. Requires a Linux
partition.
* Load a file starting at a specific sector within a partition (at
least some versions of Grub 2 and Syslinux) which also means that if
the file gets moved the boot will fail. Also, requires a Linux
partition.
I guess there are two main points of discussion here. First, what is
the best way to present a boot menu or similar without using anything
inside a partition?
And second, what do you think about the way the well-known boot
loaders work? I think each, if not loading the OS it is intended for,
will "chain-load" and start the VBR of another partition. This makes
the boot sequence
MBR --> VBR --> boot code --> menu --> selected VBR
By the way, in all the above I am thinking of the eventual outcome to
be nothing more than loading and starting a specific VBR. What that
VBR does thereafter is a separate issue. If possible I'd like to keep
the selection of the VBR separate from the work that the VBR goes on
to do within its own partition so that one is not dependent on the
other.
Hope that makes sense. Sorry it's a long post. Hopefully it is a fun
issue too.
James
solve a particular problem. Instead I am putting forward some
suggestions for hard disk boot which you guys might be interested in
and just might be interested in discussing.
The goal is to enhance the user experience of the first stage of the
hard disk booting process of a common or garden PC. I'm thinking of a
solution that we could deploy on any normal PC - i.e. one which has no
special hardware or software and which has a disk with an MBR
containing boot code and a traditional four-entry partition table.
What enhancements?
==================
So then, what enhancements? Basically to do things like
* present a specific boot menu
* scan available disks looking for bootable partitions and
offer a choice of those to the user
* maintain a timer and take a default option if a
certain period elapses before a choice is made
* issue meaningful diagnostics if errors occur
* generate informational messages about boot progress
* provide other pre-OS information to the user
For simplicity I'll generally refer to the use of a boot menu below as
that's the most used but by it I mean any or all of the above.
I'll include notes of what I understand are existing solutions.
The problem
===========
The 512 bytes of the normal master boot record (MBR) can contain
enough code to load the flagged-as-active volume boot record (VBR)
using BIOS calls. However, if we wanted the MBR to do significantly
more than just start the VBR the 512 bytes of space is too small
especially when it also has to contain data such as a partition table.
(In this post, for consistency with the above acronyms I'll call a
sector holding an extended partition table an extended boot record,
EBR. This is to keep the terminology simple. I know it does not have
to contain boot code. So, we have the acronyms MBR, EBR and VBR.)
Potential solutions
===================
The various places that extra boot code can be stored are limited and
each has good and bad points. Here is the list I have come up with.
Four schemes:
1. Immediately following the MBR, i.e. from LBA 1 onwards
- easy to find but
- can be overwritten en bloc
- can have specific bytes changed by certain programs
- may not even exist (if unusual partitioning)
2. In a separate partition
- a segregated boot partition is possibly ideal but
- takes away a partition entry from more normal uses
3. In an EBR
- can add 440 to 446 extra bytes of code but
- that may not be enough extra space
- also takes a partition entry in the MBR
4. In the last sectors of the disk
- could be plenty of space here but
- may not exist
- may be overwritten or changed
- would be inaccessible if the disk is too big
Any others of the same type? All the above are intended to work with
the basic disk structure so don't need a VBR to run. Interestingly, I
haven't come across any boot managers which work using the above
options with the possible exception of Grub 1. It apparently uses
scheme 1 at least in part.
However, I have come across other methods of providing a boot-time
menu such as the following. Corrections and additions welcome.
* Let a VBR run and start code within a partition. Then use that
larger code to present a menu to the user. If necessary go through the
loading of another VBR. I think some versions of Windows work this way
where they present a menu taken from the boot.ini file. Probably
requires a Windows partition and can only be configured from a running
copy of Windows.
* Reading from LBA 1 onwards load code which knows about the structure
of a file system in one of the partitions and uses that knowledge to
find a bigger loader from within a partition. I think some versions of
Grub 1 worked this way. Same problems as above.
* Load code from specific sectors within a partition (e.g. Lilo) which
means that if the file that is meant to be in those sectors gets moved
and the sectors get overwritten the boot will fail. Requires a Linux
partition.
* Load a file starting at a specific sector within a partition (at
least some versions of Grub 2 and Syslinux) which also means that if
the file gets moved the boot will fail. Also, requires a Linux
partition.
I guess there are two main points of discussion here. First, what is
the best way to present a boot menu or similar without using anything
inside a partition?
And second, what do you think about the way the well-known boot
loaders work? I think each, if not loading the OS it is intended for,
will "chain-load" and start the VBR of another partition. This makes
the boot sequence
MBR --> VBR --> boot code --> menu --> selected VBR
By the way, in all the above I am thinking of the eventual outcome to
be nothing more than loading and starting a specific VBR. What that
VBR does thereafter is a separate issue. If possible I'd like to keep
the selection of the VBR separate from the work that the VBR goes on
to do within its own partition so that one is not dependent on the
other.
Hope that makes sense. Sorry it's a long post. Hopefully it is a fun
issue too.
James
Rod Pemberton
Apr 19, 2012, 4:21:43 PM4/19/12
to
"James Harris" <james.h...@gmail.com> wrote in message
news:b31b63bc-39d3-4b06...@z3g2000vbk.googlegroups.com...
OMG, I'm afraid my replies below are going to make me sound like such a
"negative nelly" or like I'm bursting your bubble. I'm not, for real.
So, I'll describe what I want from booting, so maybe they won't sound so
negative. I want the PC to start and put me at a CLI boot prompt, as
quickly as possible, without any messages or delays or halts. Once I'm at
the command prompt, I can fix whatever problems might exist if the
appropriate utilities are available, or reboot to change BIOS settings. If
it's a GUI or TUI OS, I want a short name to start the GUI or TUI from the
CLI. Otherwise, the BIOS setup, BIOS messages, BIOS diagnostic screen
provide all I need. Sometimes, it's useful to be able to have the CLI start
the TUI or GUI automatically.
> I'm thinking of a
> solution that we could deploy on any normal PC - i.e. one which has no
> special hardware or software and which has a disk with an MBR
> containing boot code and a traditional four-entry partition table.
>
> What enhancements?
> ==================
>
> So then, what enhancements? Basically to do things like
>
> * present a specific boot menu
Why?
- BIOS BBS menu
- slows down booting
> * scan available disks looking for bootable partitions and
> offer a choice of those to the user
Why?
- BIOS boot order in setup
- slows down booting
> * maintain a timer and take a default option if a
> certain period elapses before a choice is made
Ok.
> * issue meaningful diagnostics if errors occur
Why?
- good for scared newb's
- good for when a professional OS has a serious crash and restarts
- slows down booting
- In general, I don't want. Get me to a prompt where I can fix the issue.
> * generate informational messages about boot progress
NO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
- Sorry, I hate that. Linux does that.
- slows down booting
> * provide other pre-OS information to the user
Why?
- BIOS PC setup screen
> [...]
the code there.
> 2. In a separate partition
> - a segregated boot partition is possibly ideal but
> - takes away a partition entry from more normal uses
>
Who really cares about the number of partitions?
Personally, I've only *needed* more than one partition recently. Prior to
that, I've *never wanted* more than one but have frequently been *forced* to
use more because of size limitations. For OSes that allow you to install
multiple drives and partitions into a single filesystem hierarchy, multiple
partitions is even less noticeable.
> 3. In an EBR
> - can add 440 to 446 extra bytes of code but
> - that may not be enough extra space
> - also takes a partition entry in the MBR
>
Why not 512 ... ?
(I'm looking at this cross eyed with a raised eyebrow, figuratively ...)
> 4. In the last sectors of the disk
> - could be plenty of space here but
> - may not exist
> - may be overwritten or changed
> - would be inaccessible if the disk is too big
Yes, I agree that's a bad area too. Certain Int 13h BIOS extenders and some
hard disks (Western Digital) relocate tracks to the outer regions, years
ago. I remember lots of failure related isssues with that ... Today, it's
probably not an issue, except for accessibility.
> However, I have come across other methods of providing a boot-time
> menu such as the following.
There is no point IMO to providing a boot-time menu, unless you're booting
multiple OSes, e.g., one partition Windows, another Linux, ...
With USB booting, it's even more of a "no point" issue IMO. Want a
different OS? Use BBS menu to boot a different USB hard disk or USB stick,
or unplug one and plug in another. Most PCs have numerous USB ports. This
one, now five or six years old has six (net of five): four on the MB and two
on the keyboard. A new laptop I saw has three. Plus, there are USB
expanders for more ports.
> Corrections and additions welcome.
>
> * Let a VBR run and start code within a partition. Then use that
> larger code to present a menu to the user. If necessary go through the
> loading of another VBR. I think some versions of Windows work this way
> where they present a menu taken from the boot.ini file. Probably
> requires a Windows partition and can only be configured from a running
> copy of Windows.
Why does this need to present a menu to the user?
AISI, whatever code you can't put into the partition ends up outside the
partition. So, it depends on how advance or limited or big the code is.
> I guess there are two main points of discussion here. First, what is
> the best way to present a boot menu or similar [...]
Using 16-bit RM code with BIOS calls ... ?
I take it that wasn't what you meant. :-)
> [...] without using anything inside a partition?
Why is that factor to your question?
Obviously, ... ;-)
that code would be located outside the partition.
> And second, what do you think about the way the well-known boot
> loaders work? I think each, if not loading the OS it is intended for,
> will "chain-load" and start the VBR of another partition. This makes
> the boot sequence
>
> MBR --> VBR --> boot code --> menu --> selected VBR
>
"if not loading the OS it is intended for" then something is wrong. Isn't
it? How do you mix-and-(mis)match this code from different OSes? You've
confused me on that. Is the MBR on one device and the other on another? I
did suggest booting from USB stick and loading an OS on a hard disk, but the
chain of booting related code should all be for a single OS.
Rod Pemberton
news:b31b63bc-39d3-4b06...@z3g2000vbk.googlegroups.com...
> Before starting I should say that this post is not asking for help to
> solve a particular problem. Instead I am putting forward some
> suggestions for hard disk boot which you guys might be interested in
> and just might be interested in discussing.
>
> The goal is to enhance the user experience of the first stage of the
> hard disk booting process of a common or garden PC.
Why?
> solve a particular problem. Instead I am putting forward some
> suggestions for hard disk boot which you guys might be interested in
> and just might be interested in discussing.
>
> The goal is to enhance the user experience of the first stage of the
> hard disk booting process of a common or garden PC.
OMG, I'm afraid my replies below are going to make me sound like such a
"negative nelly" or like I'm bursting your bubble. I'm not, for real.
So, I'll describe what I want from booting, so maybe they won't sound so
negative. I want the PC to start and put me at a CLI boot prompt, as
quickly as possible, without any messages or delays or halts. Once I'm at
the command prompt, I can fix whatever problems might exist if the
appropriate utilities are available, or reboot to change BIOS settings. If
it's a GUI or TUI OS, I want a short name to start the GUI or TUI from the
CLI. Otherwise, the BIOS setup, BIOS messages, BIOS diagnostic screen
provide all I need. Sometimes, it's useful to be able to have the CLI start
the TUI or GUI automatically.
> I'm thinking of a
> solution that we could deploy on any normal PC - i.e. one which has no
> special hardware or software and which has a disk with an MBR
> containing boot code and a traditional four-entry partition table.
>
> What enhancements?
> ==================
>
> So then, what enhancements? Basically to do things like
>
> * present a specific boot menu
- BIOS BBS menu
- slows down booting
> * scan available disks looking for bootable partitions and
> offer a choice of those to the user
- BIOS boot order in setup
- slows down booting
> * maintain a timer and take a default option if a
> certain period elapses before a choice is made
> * issue meaningful diagnostics if errors occur
- good for scared newb's
- good for when a professional OS has a serious crash and restarts
- slows down booting
- In general, I don't want. Get me to a prompt where I can fix the issue.
> * generate informational messages about boot progress
- Sorry, I hate that. Linux does that.
- slows down booting
> * provide other pre-OS information to the user
- BIOS PC setup screen
> [...]
>
> The problem
> ===========
>
> The 512 bytes of the normal master boot record (MBR) can contain
> enough code to load the flagged-as-active volume boot record (VBR)
> using BIOS calls. However, if we wanted the MBR to do significantly
> more than just start the VBR the 512 bytes of space is too small
> especially when it also has to contain data such as a partition table.
>
> [...]
> The problem
> ===========
>
> The 512 bytes of the normal master boot record (MBR) can contain
> enough code to load the flagged-as-active volume boot record (VBR)
> using BIOS calls. However, if we wanted the MBR to do significantly
> more than just start the VBR the 512 bytes of space is too small
> especially when it also has to contain data such as a partition table.
>
>
> Potential solutions
> ===================
>
> The various places that extra boot code can be stored are limited and
> each has good and bad points. Here is the list I have come up with.
>
> Four schemes:
>
> 1. Immediately following the MBR, i.e. from LBA 1 onwards
> - easy to find but
> - can be overwritten en bloc
> - can have specific bytes changed by certain programs
> - may not even exist (if unusual partitioning)
>
En bloc is good. It means that simpler utilities can be used to write
> Potential solutions
> ===================
>
> The various places that extra boot code can be stored are limited and
> each has good and bad points. Here is the list I have come up with.
>
> Four schemes:
>
> 1. Immediately following the MBR, i.e. from LBA 1 onwards
> - easy to find but
> - can be overwritten en bloc
> - can have specific bytes changed by certain programs
> - may not even exist (if unusual partitioning)
>
the code there.
> 2. In a separate partition
> - a segregated boot partition is possibly ideal but
> - takes away a partition entry from more normal uses
>
Personally, I've only *needed* more than one partition recently. Prior to
that, I've *never wanted* more than one but have frequently been *forced* to
use more because of size limitations. For OSes that allow you to install
multiple drives and partitions into a single filesystem hierarchy, multiple
partitions is even less noticeable.
> 3. In an EBR
> - can add 440 to 446 extra bytes of code but
> - that may not be enough extra space
> - also takes a partition entry in the MBR
>
(I'm looking at this cross eyed with a raised eyebrow, figuratively ...)
> 4. In the last sectors of the disk
> - could be plenty of space here but
> - may not exist
> - may be overwritten or changed
> - would be inaccessible if the disk is too big
hard disks (Western Digital) relocate tracks to the outer regions, years
ago. I remember lots of failure related isssues with that ... Today, it's
probably not an issue, except for accessibility.
> However, I have come across other methods of providing a boot-time
> menu such as the following.
multiple OSes, e.g., one partition Windows, another Linux, ...
With USB booting, it's even more of a "no point" issue IMO. Want a
different OS? Use BBS menu to boot a different USB hard disk or USB stick,
or unplug one and plug in another. Most PCs have numerous USB ports. This
one, now five or six years old has six (net of five): four on the MB and two
on the keyboard. A new laptop I saw has three. Plus, there are USB
expanders for more ports.
> Corrections and additions welcome.
>
> * Let a VBR run and start code within a partition. Then use that
> larger code to present a menu to the user. If necessary go through the
> loading of another VBR. I think some versions of Windows work this way
> where they present a menu taken from the boot.ini file. Probably
> requires a Windows partition and can only be configured from a running
> copy of Windows.
AISI, whatever code you can't put into the partition ends up outside the
partition. So, it depends on how advance or limited or big the code is.
> I guess there are two main points of discussion here. First, what is
Using 16-bit RM code with BIOS calls ... ?
I take it that wasn't what you meant. :-)
> [...] without using anything inside a partition?
Why is that factor to your question?
Obviously, ... ;-)
that code would be located outside the partition.
> And second, what do you think about the way the well-known boot
> loaders work? I think each, if not loading the OS it is intended for,
> will "chain-load" and start the VBR of another partition. This makes
> the boot sequence
>
> MBR --> VBR --> boot code --> menu --> selected VBR
>
it? How do you mix-and-(mis)match this code from different OSes? You've
confused me on that. Is the MBR on one device and the other on another? I
did suggest booting from USB stick and loading an OS on a hard disk, but the
chain of booting related code should all be for a single OS.
Rod Pemberton
s_dub...@yahoo.com
Apr 19, 2012, 7:40:27 PM4/19/12
to
On Apr 19, 1:55 pm, James Harris <james.harri...@gmail.com> wrote:
> Before starting I should say that this post is not asking for help to
> solve a particular problem. Instead I am putting forward some
> suggestions for hard disk boot which you guys might be interested in
> and just might be interested in discussing.
>
> The goal is to enhance the user experience of the first stage of the
> hard disk booting process of a common or garden PC. I'm thinking of a
> solution that we could deploy on any normal PC - i.e. one which has no
> special hardware or software and which has a disk with an MBR
> containing boot code and a traditional four-entry partition table.
>
I have to jump in right here. It had always been a 'gentleman's
> Before starting I should say that this post is not asking for help to
> solve a particular problem. Instead I am putting forward some
> suggestions for hard disk boot which you guys might be interested in
> and just might be interested in discussing.
>
> The goal is to enhance the user experience of the first stage of the
> hard disk booting process of a common or garden PC. I'm thinking of a
> solution that we could deploy on any normal PC - i.e. one which has no
> special hardware or software and which has a disk with an MBR
> containing boot code and a traditional four-entry partition table.
>
agreement' regarding the MBR that one OS wouldn't step on another's
partition. This is because the whole purpose of the MBR was to allow
up to 4 OS's to reside on a hard disk. period. Of course each OS
needs to read the MBR to identify where its partition begins and ends,
CHS, in order to properly locate itself (the starting cluster := the
correct C,H,S for Fats, for example).
Any OS needs access to the MBR to read the partition tables in such a
scheme, it 'knows' itself by the Partition Type Byte at offset 04h of
each partition table entry record. So for type byte 0DBh, cp/m-86
knows 'this is me', for example, and finds its start by the C,H,S
entry. Same for msDos, xenix, or any other...
http://en.wikipedia.org/wiki/Partition_type
..in the context of..
http://en.wikipedia.org/wiki/Master_boot_record
..so a pox on any OS that touches another OS's partition.
That held pretty well until the period of time when msft began selling
msdos preinstalled on OEM's hard drives. It was the only OS on the
media, and acted that way, it still used a MBR however, but didn't
leave any free space of course. However you could still buy it 'stand
alone, i.e. off-the-shelf', so fdisk still respected other existing OS
partitions and operated on free space c.h.s. for installation (as an
option).
Under MBR then, it was typical for whomever's OS, being the first to
install to begin the partition at C,H,S := 0,1,1 which effectively
left the first track under head 0 as free space. Remaining partition
installs used Cn,0,1 as the beginning of their partition.
Again, OS's didn't step outside their own partition, this is a
requirement otherwise the mbr scheme breaks down.
Third party boot managers came along to do what you want to do. They
used the remaining of C=0,H=0,S>1
to offer a boot selection menu.
The 'cheap' man's way is to write a utility to change the active
partition byte to take effect on the next reboot. For example, Freek
Heite wrote a program to run under CP/M-86 to switch to the msdos
primary partition on a following reboot by changing the the CP/M-86
active partition byte to null and setting the msdos active partition
byte from null to 80h. He also wrote a separate program for msdos to
go the other way, msdos to cp/m-86, by changing those active partition
bytes appropriately. If you are brave you can use debug.com and
sid.cmd to do this. I'm not brave anymore with the modern hardware
and severely bad consequences of a foul-up. Drives are cheap, used
drives are cheaper, so I swap drives (actually just the data cable) in
about 30 seconds with these clamshell desktop cases. Of course this
is 'oldschool' in light of USB boots.
Steve
> 2. In a separate partition
> - a segregated boot partition is possibly ideal but
> - takes away a partition entry from more normal uses
>
> 3. In an EBR
> - can add 440 to 446 extra bytes of code but
> - that may not be enough extra space
> - also takes a partition entry in the MBR
>
> 4. In the last sectors of the disk
> - could be plenty of space here but
> - may not exist
> - may be overwritten or changed
> - would be inaccessible if the disk is too big
>
s_dub...@yahoo.com
Apr 20, 2012, 9:58:06 AM4/20/12
to
On Apr 19, 1:55 pm, James Harris <james.harri...@gmail.com> wrote:
modern MBR since LBA and EFI, I see that..
http://en.wikipedia.org/wiki/GUID_Partition_Table
GUID is the way forward, esp. since LBA size is transitioning to 4kb.
Since GUID allows for 128 partitions, then perhaps (2) is the better
idea as it preserves the GUID convention of storage area mapping.
Steve
> 3. In an EBR
> - can add 440 to 446 extra bytes of code but
> - that may not be enough extra space
> - also takes a partition entry in the MBR
>
> 4. In the last sectors of the disk
> - could be plenty of space here but
> - may not exist
> - may be overwritten or changed
> - would be inaccessible if the disk is too big
>
> Any others of the same type? All the above are intended to work with
> the basic disk structure so don't need a VBR to run. Interestingly, I
> haven't come across any boot managers which work using the above
> options with the possible exception of Grub 1. It apparently uses
> scheme 1 at least in part.
>
> However, I have come across other methods of providing a boot-time
> menu such as the following. Corrections and additions welcome.
>
>
> James
Antoine Leca
Apr 20, 2012, 1:40:31 PM4/20/12
to
James Harris wrote:
> Four schemes:
>
> 1. Immediately following the MBR, i.e. from LBA 1 onwards
> Four schemes:
>
> 1. Immediately following the MBR, i.e. from LBA 1 onwards
> 2. In a separate partition
> 3. In an EBR
> 4. In the last sectors of the disk
>
>
> Any others of the same type? All the above are intended to work with
> the basic disk structure so don't need a VBR to run. Interestingly, I
> haven't come across any boot managers which work using the above
> options with the possible exception of Grub 1. It apparently uses
> scheme 1 at least in part.
IBM's boot manager (around 1994, for OS/2) used #2, but there is a big
> the basic disk structure so don't need a VBR to run. Interestingly, I
> haven't come across any boot managers which work using the above
> options with the possible exception of Grub 1. It apparently uses
> scheme 1 at least in part.
BUT here: they used a FAT (private) volume with only ONE FAT copy; as a
result Windows 2000 install program mis-detected it... and quietly made
that partition unusable as part as its enumeration of volumes
initialisation (OS/2 conspiracionists always said this was deliberate.)
Compaq and Dell use(d) #2 (mainly for the maintenance partition); I am
sure there are other examples or it.
RPM (http://www.ranish.com/part/) used a variant of #2: it installs
itself in a partition which is usually addressed using a specific
partition entry unusually stored at bytes 1AEh-1BDh, but it could use a
separate entry for this (and it is even recommended to improve
compatibility with softwares which erase the code part of the MBR.)
NetBSD's uses in part #3: only datas are stored there (actually the name
of the OS to bootstrap in each logical partitions.)
#4 is definitively a bad idea IMHO, but Veritas and Microsoft used it
for LDM (Logical Disk Manager.)
> However, I have come across other methods of providing a boot-time
> menu such as the following. Corrections and additions welcome.
(and NO, you do NOT want to invent another standard here! please!)
Note this outright kills the "pure" #1 and #4 schemes: GPT datas are
stored in two places for redundancy, with the master copy are at the
start of the disk, before any actual partitition and indexed from LBA#1,
while the backup copy is at the end of the disk, after all partitions
and indexed from the "last" sector.
And GPT's (more exactly, EFI's) idea is to go with #2, using a separate
partition for "pre-boot", preferably FAT since it is the most widely
compatible thing.
Just do not repeat IBM's (or Microsoft's) mistake, use 2 FATs.
> I guess there are two main points of discussion here. First, what is
> the best way to present a boot menu or similar without using anything
> inside a partition?
along the years, and made bootstarpping a so complex task it ends
lasting too much seconds: at the end this allowed UEFI to come with the
speed as an argument, which is pretty surprising when you consider the
big complexity that UEFI adds to the boot process itself (entering
protected mode, intializing everything using pseudo OO, etc.)
> And second, what do you think about the way the well-known boot
> loaders work? I think each, if not loading the OS it is intended for,
> will "chain-load" and start the VBR of another partition.
limited number of options:
- chain-load, which is really stepping back once and continue as if that
OS it is intended for was not there;
- calling INT 18h (what BBS mandates, but not often done except when
something goes wrong early, like in MBR code);
- reset the platform;
- hang (busy loop.)
Logically, I fail to see other options at all.
"Chain-loading" is really the PC-BIOS way to invoke an installed OS;
other platforms usually have more elaborate ways to invoke an OS.
For example, the Multiboot specification defines it in a way which eases
a lot the work of the kernel developer (whether multiboot is successful
is another debate.)
Usually though, the platforms provide some way to load the code from
some support (ROM, disk or network); PC-BIOS provide the INT 13h
interface, and expects the code loaded the first sector of the boot
media to load the rest and to bootstrap: this is the very definition of
chain-loading!
EFI and other firmwares usually just defines an interface for the OS to
load itself, and provides easy-to-call "methods" (like reading a sector
or writing to the screen) adapted to the hardware.
The same idea can be encountered in pure software with Microsoft's Boot
manager and its separate loader ("boot applications", like WinLoad.exe;
undocumented.)
Antoine
James Harris
Apr 21, 2012, 4:20:08 AM4/21/12
to
On Apr 20, 2:58 pm, "s_dubrov...@yahoo.com" <s_dubrov...@yahoo.com>
wrote:
...
> > 2. In a separate partition
> > - a segregated boot partition is possibly ideal but
> > - takes away a partition entry from more normal uses
>
> So since you've spurred me to do alittle research on what is up with
> modern MBR since LBA and EFI, I see that..
>
> http://en.wikipedia.org/wiki/GUID_Partition_Table
>
> GUID is the way forward, esp. since LBA size is transitioning to 4kb.
> Since GUID allows for 128 partitions, then perhaps (2) is the better
> idea as it preserves the GUID convention of storage area mapping.
I've been trying very hard to avoid discussing EFI, GPT and 4k sectors
yet because they are good topics to come back to later, for me, once I
understand the traditional model better. I suspect others may be in
the same position.
Nevertheless, as you suggest, since GPT promotes use of a boot
partition then scheme 2, above, is at least similar. Even if the
details may differ it will carry a resemblance with what is intended
to be used in the future.
James
wrote:
...
> > 2. In a separate partition
> > - a segregated boot partition is possibly ideal but
> > - takes away a partition entry from more normal uses
>
> So since you've spurred me to do alittle research on what is up with
> modern MBR since LBA and EFI, I see that..
>
> http://en.wikipedia.org/wiki/GUID_Partition_Table
>
> GUID is the way forward, esp. since LBA size is transitioning to 4kb.
> Since GUID allows for 128 partitions, then perhaps (2) is the better
> idea as it preserves the GUID convention of storage area mapping.
yet because they are good topics to come back to later, for me, once I
understand the traditional model better. I suspect others may be in
the same position.
Nevertheless, as you suggest, since GPT promotes use of a boot
partition then scheme 2, above, is at least similar. Even if the
details may differ it will carry a resemblance with what is intended
to be used in the future.
James
James Harris
Apr 21, 2012, 5:36:27 AM4/21/12
to
On Apr 20, 6:40 pm, Antoine Leca <r...@localhost.invalid> wrote:
> James Harris wrote:
> > Four schemes:
>
> > 1. Immediately following the MBR, i.e. from LBA 1 onwards
> > 2. In a separate partition
> > 3. In an EBR
> > 4. In the last sectors of the disk
...
> James Harris wrote:
> > Four schemes:
>
> > 1. Immediately following the MBR, i.e. from LBA 1 onwards
> > 2. In a separate partition
> > 3. In an EBR
> > 4. In the last sectors of the disk
> RPM (http://www.ranish.com/part/) used a variant of #2: it installs
> itself in a partition which is usually addressed using a specific
> partition entry unusually stored at bytes 1AEh-1BDh, but it could use a
> separate entry for this (and it is even recommended to improve
> compatibility with softwares which erase the code part of the MBR.)
is normally the first one - and that partition entry:
* would not be seen as an entry by most utilities
* would occupy space Microsoft used (possibly later) for a disk ID
Perhaps the really bad part about the RPM scheme as you describe it is
that normal disk partitioning utilities would see the space the RPB
code used as unused and may unknowingly allocate something else over
the top of it. Unless it overlaid part of another partition (which has
its own issues) then as far as anything else is concerned the space
RPM used would be seen as free. To put boot code there, therefore,
would be no better that putting the code in an unallocated part of the
disk!
...
> You must accomodate GPT, which is the only standard in town for >2TB
> (and NO, you do NOT want to invent another standard here! please!)
not! ;-)
Seriously, for what we are doing (OS dev) I wouldn't discourage
someone from defining something different. After all, OS dev is all
about breaking new ground. If we wanted to use something that exists
we wouldn't be writing something new. Having said that, however,
there's no need to do something different just for the sake of it. For
me, in this case, existing standards are fine.
Specifically about GPT, from what I have found, MBR and GPT formats
are effectively mutually exclusive even despite the attempt at
compatibility. However, GPT would be a great issue to come back to.
> Note this outright kills the "pure" #1 and #4 schemes:
GPT the whole disk setup is different so a GPT disk would have
different code in the MBR sector if it had code there at all.
Therefore I would say that schemes #1 and #4 are not killed for a disk
under the MBR system. Does that make sense?
...
> And GPT's (more exactly, EFI's) idea is to go with #2, using a separate
> partition for "pre-boot", preferably FAT since it is the most widely
> compatible thing.
> Just do not repeat IBM's (or Microsoft's) mistake, use 2 FATs.
definitely go with that if it is practical. (I'll explain my
reservations in a separate post.)
As for the comments about using a FAT filesystem:
1. FAT does, IIRC, allow for a block of reserved sectors which would
make an ideal place to store the boot code. But I am not sure I'd want
any other files stored in that partition with the system boot code and
data so it may be best to keep that partition opaque to normal tools.
Not sure.
2. There are copyright issues with, IIRC, support of long file names
in FAT so even if FAT was used it would be good to prohibit long file
names.
...
> > And second, what do you think about the way the well-known boot
> > loaders work? I think each, if not loading the OS it is intended for,
> > will "chain-load" and start the VBR of another partition.
>
> If the boot loader does not load the OS it is intended for, it has a
> limited number of options:
> - chain-load, which is really stepping back once and continue as if that
> OS it is intended for was not there;
> - calling INT 18h (what BBS mandates, but not often done except when
> something goes wrong early, like in MBR code);
> - reset the platform;
> - hang (busy loop.)
start code that sits within an OS partition before selecting the OS to
boot) require not just that the code in that partition is not moved
and overwritten but that they are overly tied in with the OS which
occupies that partition.
Say you had a Windows partition, for example, and decided to remove
it. Any boot menu would also go away taking with it any menu options
that the user had defined for other OSes.
This suggests that it would be better for any initial boot code and
data to be stored entirely separately from what is in the normal
partitions.
...
> For example, the Multiboot specification defines it in a way which eases
> a lot the work of the kernel developer (whether multiboot is successful
> is another debate.)
In fact I probably don't know enough about it to comment but the
downsides I am thinking of are
1. Multiboot stores code and menu data (whether by design or just in
practice) in an OS partition so that if the OS partition is taken
away, e.g. with fdisk, then the user will lose all other menu options
set up.
2. The sectors storing stage2 are part of a normal filesystem but are
accessed from the MBR by location so that if any of those sectors are
overwritten it will also fail.
> Usually though, the platforms provide some way to load the code from
> some support (ROM, disk or network); PC-BIOS provide the INT 13h
> interface, and expects the code loaded the first sector of the boot
> media to load the rest and to bootstrap: this is the very definition of
> chain-loading!
of PC boot, as a boot manager or some other non-simple piece of boot
code getting control via its own VBR and, rather than going on to boot
the OS it is intended for, it is told by menu choice or similar to
boot another OS so loads and starts that VBR.
The MBR starting the first VBR I don't take as chain loading in the
above context but I can see it being called that.
By the way, you mentioned the network. A pre-OS boot manager would be
a great place to add network boot if it wasn't provided by the BIOS.
Even if it was provided by the BIOS a pre-OS set of PXE or other
routes would be ideal, if the user wanted that.
That said, pre-OS network boot may have some much bigger issues.
AFAIK, the BIOS provides no network device calls and I'm not sure
whether there is a practical way to control network cards in what I
envisage as a boot partition.
James
James Harris
Apr 21, 2012, 6:41:25 AM4/21/12
to
On Apr 19, 7:55 pm, James Harris <james.harri...@gmail.com> wrote:
...
> The various places that extra boot code can be stored are limited
...
> 2. In a separate partition
> - a segregated boot partition is possibly ideal but
> - takes away a partition entry from more normal uses
>
> 3. In an EBR
> - can add 440 to 446 extra bytes of code but
> - that may not be enough extra space
> - also takes a partition entry in the MBR
Thanks for all the replies to the original post. Based on those there
seem to be good reasons to keep just the above two schemes on the
list. Of these, #2 is probably ideal if it is practical.
By the way, I like the term that someone used that this is all "pre-
OS". That expresses it well. Better than existing boot managers which
store their code in an OS partition it is for code to run before any
OS partition is used and could even run before any OS partition is
defined on the disk. So it is pre-OS not just in the sense of running
before an OS starts but running before anything from an OS-containing
partition runs.
How practical are the two schemes?
Say we take scheme #3 first, extra boot code in an EBR. One concern is
whether the MBR would accept an EBR as bootable. Similarly, would a
partitioning program allow an EBR to be marked as the bootable/active
partition?
I've never heard of a bootable EBR but perhaps they are used.
From what I have seen of MBR code (and there are many variants) they
would have no problem executing an EBR instead of a VBR but if you
know otherwise please say. Similarly, Linux fdisk does allow an EBR to
be marked as bootable. I don't know about fdisk under Windows or DOS.
The biggest downside of the scheme on its own is the small amount of
space that it adds.
What about scheme #2, pre-OS boot code in a separate partition? It has
two basic requirements:
* some free disk space
* at least one unused partition table entry
Can we expect those to be available? I think both these are reasonable
to expect because if someone wants to install another OS on an
existing disk these are requirements whether there is to be a pre-OS
system or not. A new OS would require free space. It would also
require a partition for it to be installed in.
In terms of space, since the pre-OS partition will be small it also
won't take away anything significant from the space the user might
plan to install the OS on.
However, the requirement for an unused partition table entry is more
interesting. Say the disk has just one partition table entry which is
not already in use. It could be used for the OS or it could be used
for the pre-OS partition but not both.
So the question is; "if we use such a scheme how could we install both
our OSes and a pre-OS partition on a disk which has just one free
partition table entry?"
One option: use a couple of EBRs. Remember, these normally form a
chain where each one is pointed at by the preceding boot record. So
MBR --> EBR --> EBR --> EBR --> EBR --> EBR
and so on depending on how many extended partitions there are.
Each EBR normally contains the definition of one partition and a
pointer to the next EBR (or no pointer if it is the last).
(Possibly more accurately, a disk has just one extended partition. It
is defined in the MBR and all EBRs define parts of that extended
partition.)
Given the structure, say we take the only remaining MBR partition
entry and create an extended partition. We can then split that
extended partition into a small piece for the pre-OS partition and a
larger piece for the OS.
That would make space for the pre-OS partition and leave space
available for an OS. Does that sound workable so far? If it is we then
have the final problem of how to get the pre-OS partition to boot. It
would have to be something like the following.
1. MBR loads and starts the first EBR.
2. That EBR loads and starts the VBR sector of the pre-OS partition.
3. The VBR loads the pre-OS code.
Sorry if that seems complicated. In a sense it is but only as much as
it has to be to cope with there being only one partition table entry
free. If there were two partition table entries free in the master
boot record we could put the pre-OS partition in one of those and thus
leave at least one for an OS. But if it works it may be good to do
even when there are free MBR partition table entries.
In practice it is probably not overly complicated - especially when
compared with existing pre-OS boot systems!
The main potential issue is possibly whether the MBR will invoke the
EBR.
Can anyone see anything that would stop this working? Any other
comments?
James
...
> The various places that extra boot code can be stored are limited
> 2. In a separate partition
> - a segregated boot partition is possibly ideal but
> - takes away a partition entry from more normal uses
>
> 3. In an EBR
> - can add 440 to 446 extra bytes of code but
> - that may not be enough extra space
> - also takes a partition entry in the MBR
seem to be good reasons to keep just the above two schemes on the
list. Of these, #2 is probably ideal if it is practical.
By the way, I like the term that someone used that this is all "pre-
OS". That expresses it well. Better than existing boot managers which
store their code in an OS partition it is for code to run before any
OS partition is used and could even run before any OS partition is
defined on the disk. So it is pre-OS not just in the sense of running
before an OS starts but running before anything from an OS-containing
partition runs.
How practical are the two schemes?
Say we take scheme #3 first, extra boot code in an EBR. One concern is
whether the MBR would accept an EBR as bootable. Similarly, would a
partitioning program allow an EBR to be marked as the bootable/active
partition?
I've never heard of a bootable EBR but perhaps they are used.
From what I have seen of MBR code (and there are many variants) they
would have no problem executing an EBR instead of a VBR but if you
know otherwise please say. Similarly, Linux fdisk does allow an EBR to
be marked as bootable. I don't know about fdisk under Windows or DOS.
The biggest downside of the scheme on its own is the small amount of
space that it adds.
What about scheme #2, pre-OS boot code in a separate partition? It has
two basic requirements:
* some free disk space
* at least one unused partition table entry
Can we expect those to be available? I think both these are reasonable
to expect because if someone wants to install another OS on an
existing disk these are requirements whether there is to be a pre-OS
system or not. A new OS would require free space. It would also
require a partition for it to be installed in.
In terms of space, since the pre-OS partition will be small it also
won't take away anything significant from the space the user might
plan to install the OS on.
However, the requirement for an unused partition table entry is more
interesting. Say the disk has just one partition table entry which is
not already in use. It could be used for the OS or it could be used
for the pre-OS partition but not both.
So the question is; "if we use such a scheme how could we install both
our OSes and a pre-OS partition on a disk which has just one free
partition table entry?"
One option: use a couple of EBRs. Remember, these normally form a
chain where each one is pointed at by the preceding boot record. So
MBR --> EBR --> EBR --> EBR --> EBR --> EBR
and so on depending on how many extended partitions there are.
Each EBR normally contains the definition of one partition and a
pointer to the next EBR (or no pointer if it is the last).
(Possibly more accurately, a disk has just one extended partition. It
is defined in the MBR and all EBRs define parts of that extended
partition.)
Given the structure, say we take the only remaining MBR partition
entry and create an extended partition. We can then split that
extended partition into a small piece for the pre-OS partition and a
larger piece for the OS.
That would make space for the pre-OS partition and leave space
available for an OS. Does that sound workable so far? If it is we then
have the final problem of how to get the pre-OS partition to boot. It
would have to be something like the following.
1. MBR loads and starts the first EBR.
2. That EBR loads and starts the VBR sector of the pre-OS partition.
3. The VBR loads the pre-OS code.
Sorry if that seems complicated. In a sense it is but only as much as
it has to be to cope with there being only one partition table entry
free. If there were two partition table entries free in the master
boot record we could put the pre-OS partition in one of those and thus
leave at least one for an OS. But if it works it may be good to do
even when there are free MBR partition table entries.
In practice it is probably not overly complicated - especially when
compared with existing pre-OS boot systems!
The main potential issue is possibly whether the MBR will invoke the
EBR.
Can anyone see anything that would stop this working? Any other
comments?
James
Rod Pemberton
Apr 21, 2012, 9:32:20 PM4/21/12
to
"James Harris" <james.h...@gmail.com> wrote in message
news:88d934ae-6dbe-4eba...@h12g2000yqi.googlegroups.com...
...
> 2. There are copyright issues with, IIRC, support of long file names
> in FAT so even if FAT was used it would be good to prohibit long file
> names.
Well, you can use some completely unrelated method for long filenames for
FAT, e.g., like UMSDOS once did for Linux, that's legal. Linux used
utilities coded in C to keep the long filenames in --LINUX-.--- upto date
between booting DOS and Linux. That's slow and tedious. For DOS, it's just
a matter of coding a DOS TSR to save long filename info in UMSDOS'
--LINUX-.--- file, instead of writing into the directory where MS
style LFNs are stored. That shouldn't be outrageously difficult. The
MSCDEX, i.e., CD-ROM, API should provide most of what is needed for DOS.
It's actually an IFS API. Also, for non-DOS FAT, the C++ code to implement
UMSDOS is available. If someone combined UMSDOS perhaps with Philip
Erdelsky's "Reentrant DOS-Compatible File System" which is in C, it could
be or become an acceptable filesystem ...
Alternately, you could come up with your own method to implement long
filenames on FAT or for DOS.
<MS LFN patent rant>
You only need not violate MS' patents to use MS style LFNs, but "there's the
rub". Their patents protect specific implementation methods for LFNs with
FAT. E.g., if you use a different implementation method than MS to do the
exact same thing, technically that's legal. You still might get sued though
via a harassment lawsuit, be forced to prove in court why you aren't
violating, costing you lots of time and money, encouraging you to change or
settle, etc...
The problem is nobody knows what the MS patents actually protects.
Programmers aren't patent attorneys and so don't understand what is
protected and isn't. Also, there hasn't been many court cases defining what
is or isn't protected by the patents. I.e., a court could declare patent(s)
entirely or partially invalid, but no one wants to get involved in an
expensive court case with MS to find out. Even when the court upholds a
patent, no one - well, those without access to expensive attorneys - still
knows what it protects. Patents describe the entire context of use, but
only protect a small amount of what's mentioned in the patent. That
uncertainty about what is and isn't means that even Linux changed it's
strategy of just using a different method of implementing DOS compatible
LFNs. Linux switched to allowing only one or the other, long or short,
under the presumption that using both together could violate a patent.
MS has moved on to NTFS anyway. I'm really not sure why they keep
protecting patents for a filesystem that they no longer use and which they
declared to be obsolete and flawed: FAT32. IIRC, some have argued FAT32 is
unpatentable because MS provided it for standardization as part of open
specification ... typical. AFAICT, it seems to be to gain access to other
patent collections by other companies. I.e., a corporation infringed on MS'
patents and settles with money and access to their patents. So far, this
seems to be primarily affecting manufacturers of cameras, video recorders,
and external disks. It's the MS version of "open patents":
"Small corporation, you're more likely to infringe us than us infringing you
because we've got a better patent collection. And, when you do, you'll
settle financially. Then, we'll get the rights to your patents without
license fees. Effectively, you'll pay us for accessing your patents! You
should've signed the undervalued patent license agreement we proffered years
ago ..."
Rod Pemberton
James Harris
Apr 22, 2012, 3:32:22 PM4/22/12
to
On Apr 19, 9:21 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:
(Have replied to the earlier of your comments in a separate thread.)
...
> > The various places that extra boot code can be stored are limited and
> > each has good and bad points. Here is the list I have come up with.
>
> > Four schemes:
...
> > 3. In an EBR
> > - can add 440 to 446 extra bytes of code but
> > - that may not be enough extra space
> > - also takes a partition entry in the MBR
>
> Why not 512 ... ?
> (I'm looking at this cross eyed with a raised eyebrow, figuratively ...)
Some of the 512 are used. I'm not sure exactly how many would be
available - hence the range - but an EBR has a partition table and
0x55, 0xaa signature the same as an MBR.
http://en.wikipedia.org/wiki/Extended_boot_record
...
> There is no point IMO to providing a boot-time menu, unless you're booting
> multiple OSes, e.g., one partition Windows, another Linux, ...
Yes, that's the idea but only if that's what the user wants.
By the way, a menu can have other than just partitions on it and that
can be useful at times. After a Ubuntu upgrade one machine I have was
unable to control a specific PCI card. It turned out to be a bug in
the new Linux kernel. Fortunately Grub leaves other kernels in its
boot menu. I was able to work round it by telling Grub to boot each
time into an old kernel that did not have the bug.
...
> > * Let a VBR run and start code within a partition. Then use that
> > larger code to present a menu to the user. If necessary go through the
> > loading of another VBR. I think some versions of Windows work this way
> > where they present a menu taken from the boot.ini file. Probably
> > requires a Windows partition and can only be configured from a running
> > copy of Windows.
>
> Why does this need to present a menu to the user?
I wasn't saying it had to. This is just what some programs do. For
Windows I think it is after the user presses F8 or something like
that.
> AISI, whatever code you can't put into the partition ends up outside the
> partition. So, it depends on how advance or limited or big the code is.
Doesn't sound good. Code which is not in a partition is not recorded
anywhere and there is nothing to tell other code not to overwrite it.
> > I guess there are two main points of discussion here. First, what is
> > the best way to present a boot menu or similar [...]
>
> Using 16-bit RM code with BIOS calls ... ?
> I take it that wasn't what you meant. :-)
Yes, RM code using the BIOS. It *was* what I meant!
> > [...] without using anything inside a partition?
>
> Why is that factor to your question?
>
> Obviously, ... ;-)
> that code would be located outside the partition.
Badly worded on my part. I meant without using anything inside an OS-
containing partition. It would be OK to have a partition set aside for
the purpose and, indeed, that was scheme #2.
Code which is not in a partition is a bad thing!
> > And second, what do you think about the way the well-known boot
> > loaders work? I think each, if not loading the OS it is intended for,
> > will "chain-load" and start the VBR of another partition. This makes
> > the boot sequence
>
> > MBR --> VBR --> boot code --> menu --> selected VBR
>
> "if not loading the OS it is intended for" then something is wrong. Isn't
> it? How do you mix-and-(mis)match this code from different OSes? You've
> confused me on that.
I think this is how some systems work. Take your old favourite, Grub.
AIUI Grub 2 does the following if told to boot another OS.
MBR --> stage 2 boot code --> menu --> selected VBR
The stage 2 code is usually located within a Linux partition but if it
is told to boot another partition it chain-loads the VBR for the
target partition.
Any OS loading code like ntldr.sys or linuxload or whatever it is
called would exist within the partition.
> Is the MBR on one device and the other on another? I
> did suggest booting from USB stick and loading an OS on a hard disk, but the
> chain of booting related code should all be for a single OS.
A boot load system could be stored on any bootable medium, I guess,
but the hard disk is ideal as it should always be present.
James
wrote:
(Have replied to the earlier of your comments in a separate thread.)
...
> > The various places that extra boot code can be stored are limited and
> > each has good and bad points. Here is the list I have come up with.
>
> > Four schemes:
> > 3. In an EBR
> > - can add 440 to 446 extra bytes of code but
> > - that may not be enough extra space
> > - also takes a partition entry in the MBR
>
> Why not 512 ... ?
> (I'm looking at this cross eyed with a raised eyebrow, figuratively ...)
available - hence the range - but an EBR has a partition table and
0x55, 0xaa signature the same as an MBR.
http://en.wikipedia.org/wiki/Extended_boot_record
...
> There is no point IMO to providing a boot-time menu, unless you're booting
> multiple OSes, e.g., one partition Windows, another Linux, ...
By the way, a menu can have other than just partitions on it and that
can be useful at times. After a Ubuntu upgrade one machine I have was
unable to control a specific PCI card. It turned out to be a bug in
the new Linux kernel. Fortunately Grub leaves other kernels in its
boot menu. I was able to work round it by telling Grub to boot each
time into an old kernel that did not have the bug.
...
> > * Let a VBR run and start code within a partition. Then use that
> > larger code to present a menu to the user. If necessary go through the
> > loading of another VBR. I think some versions of Windows work this way
> > where they present a menu taken from the boot.ini file. Probably
> > requires a Windows partition and can only be configured from a running
> > copy of Windows.
>
> Why does this need to present a menu to the user?
Windows I think it is after the user presses F8 or something like
that.
> AISI, whatever code you can't put into the partition ends up outside the
> partition. So, it depends on how advance or limited or big the code is.
anywhere and there is nothing to tell other code not to overwrite it.
> > I guess there are two main points of discussion here. First, what is
> > the best way to present a boot menu or similar [...]
>
> Using 16-bit RM code with BIOS calls ... ?
> I take it that wasn't what you meant. :-)
> > [...] without using anything inside a partition?
>
> Why is that factor to your question?
>
> Obviously, ... ;-)
> that code would be located outside the partition.
containing partition. It would be OK to have a partition set aside for
the purpose and, indeed, that was scheme #2.
Code which is not in a partition is a bad thing!
> > And second, what do you think about the way the well-known boot
> > loaders work? I think each, if not loading the OS it is intended for,
> > will "chain-load" and start the VBR of another partition. This makes
> > the boot sequence
>
> > MBR --> VBR --> boot code --> menu --> selected VBR
>
> "if not loading the OS it is intended for" then something is wrong. Isn't
> it? How do you mix-and-(mis)match this code from different OSes? You've
> confused me on that.
AIUI Grub 2 does the following if told to boot another OS.
MBR --> stage 2 boot code --> menu --> selected VBR
The stage 2 code is usually located within a Linux partition but if it
is told to boot another partition it chain-loads the VBR for the
target partition.
Any OS loading code like ntldr.sys or linuxload or whatever it is
called would exist within the partition.
> Is the MBR on one device and the other on another? I
> did suggest booting from USB stick and loading an OS on a hard disk, but the
> chain of booting related code should all be for a single OS.
but the hard disk is ideal as it should always be present.
James
Rod Pemberton
Apr 22, 2012, 8:24:49 PM4/22/12
to
"James Harris" <james.h...@gmail.com> wrote in message
news:7b8acc56-37e7-4608...@2g2000yqp.googlegroups.com...
> On Apr 19, 9:21 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
> wrote:
>
> (Have replied to the earlier of your comments in a separate thread.)
Ok ...
> wrote:
>
> (Have replied to the earlier of your comments in a separate thread.)
> > > 3. In an EBR
> > > - can add 440 to 446 extra bytes of code but
> > > - that may not be enough extra space
> > > - also takes a partition entry in the MBR
>
> > Why not 512 ... ?
> > (I'm looking at this cross eyed with a raised eyebrow, figuratively ...)
>
> Some of the 512 are used. I'm not sure exactly how many would be
> available - hence the range - but an EBR has a partition table and
> 0x55, 0xaa signature the same as an MBR.
>
Well, I assumed you meant VBR. You had been discussing MBR/VBR then
switched to MBR/EBR.
> > There is no point IMO to providing a boot-time menu, unless you're
> > booting multiple OSes, e.g., one partition Windows, another Linux, ...
>
> Yes, that's the idea but only if that's what the user wants.
desirable for most. A user typically is only running one OS. When one does
run multiple OSes, the other OSes are on typically a separate device, and a
physical device is swapped or a cable is connected.
Those who want to do that use existing programs. Don't they?
> > AISI, whatever code you can't put into the partition ends up outside the
> > partition. So, it depends on how advance or limited or big the code is.
>
> Doesn't sound good. Code which is not in a partition is not recorded
Uh, that's not exactly what I meant ... Some code needed for booting an OS
has to be loaded early, i.e., prior to the ability to load from the
partition's filesystem. Other code needed for booting an OS can be loaded
after filesystem drivers (and associated code) has been executed. I.e.,
some code most likely will be outside the partition.
The code outside the partition will *also* be on the partition, i.e., what
you call "recorded somewhere". But, that's not where it's actually loaded
from. E.g., if you have a utility to write the MBR code, the MBR code is
part of the utility or a separate file the utility reads. That utility
writes the code from a file on the partition or it's internal codespace to
the MBR area on disk. E.g., if you have a utility to write a bootloader to
a specific region, not within a partition, the bootloader will be a file on
the partition too.
You can use 'dd' command in Linux to read or write the MBR. Does Linux
have a special command to write the kernel, e.g., "vmlinuz" etc., somewhere
or does the bootloader get it from the partition?
DOS has SYS.com to write system files to specific tracks and sectors. The
files are also listed within the filesystem. In DOS, if you copy new
versions of the system files, replacing the old, they'll write to the same
allocated tracks, space permitting. There is alot I'm not sure about with
how DOS handles this. I'm not sure if the tracks are or aren't preallocated
to prevent use of those tracks. I'm not sure if SYS relocates tracks if in
use. And, I'm not sure if the tracks are inside or outside of partition
space. But, DOS uses a method that is likely different from Linux and which
works for itself.
> ... there is nothing to tell other code not to overwrite it.
That's true, but ...
1) That's why the use of special utilities to write system files.
2) That's generally why filesystems don't write to outside their partition
space, i.e., system areas, other partitions, and possibly filesystem control
structures (depending on implementation).
> Code which is not in a partition is a bad thing!
Aren't the following code pieces typically or sometimes installed outside a
partition: MBR, PBR or VBR, EBR, bootloader (possibly multiple stages),
OS kernel?
Yes, copies of each are also available, directly (file) or indirectly
(within an application), within the partition too, typically.
> > > And second, what do you think about the way the well-known boot
> > > loaders work? I think each, if not loading the OS it is intended for,
> > > will "chain-load" and start the VBR of another partition. This makes
> > > the boot sequence
>
> > > MBR --> VBR --> boot code --> menu --> selected VBR
>
> > "if not loading the OS it is intended for" then something is wrong.
> > Isn't it? How do you mix-and-(mis)match this code from different
> > OSes? You've confused me on that.
>
> I think this is how some systems work. Take your old favourite, Grub.
> AIUI Grub 2 does the following if told to boot another OS.
>
> MBR --> stage 2 boot code --> menu --> selected VBR
>
> The stage 2 code is usually located within a Linux partition but if it
> is told to boot another partition it chain-loads the VBR for the
> target partition.
text diagram. You apparently meant "each" as "well-known boot loaders".
Confusion resolved.
> Any OS loading code like ntldr.sys or linuxload or whatever it is
> called would exist within the partition.
most probably specific to each OS.
Rod Pemberton
Antoine Leca
Apr 23, 2012, 4:55:47 AM4/23/12
to
James Harris wrote:
> On Apr 20, 6:40 pm, Antoine Leca <r...@localhost.invalid> wrote:
>> RPM (http://www.ranish.com/part/) used a variant of #2: it installs
>> itself in a partition which is usually addressed using a specific
>> partition entry unusually stored at bytes 1AEh-1BDh, but it could use a
>> separate entry for this (and it is even recommended to improve
>> compatibility with softwares which erase the code part of the MBR.)
>
> Interesting. So Ranish defined a partition immediately prior to what
> is normally the first one - and that partition entry:
>
> * would not be seen as an entry by most utilities
> * would occupy space Microsoft used (possibly later) for a disk ID
Yes on both counts.
> On Apr 20, 6:40 pm, Antoine Leca <r...@localhost.invalid> wrote:
>> RPM (http://www.ranish.com/part/) used a variant of #2: it installs
>> itself in a partition which is usually addressed using a specific
>> partition entry unusually stored at bytes 1AEh-1BDh, but it could use a
>> separate entry for this (and it is even recommended to improve
>> compatibility with softwares which erase the code part of the MBR.)
>
> Interesting. So Ranish defined a partition immediately prior to what
> is normally the first one - and that partition entry:
>
> * would not be seen as an entry by most utilities
> * would occupy space Microsoft used (possibly later) for a disk ID
> Perhaps the really bad part about the RPM scheme as you describe it is
> that normal disk partitioning utilities
other utility.
In fact, with the MBR scheme, any partitioning tool in command is always
the only one (at a given instant); if the disk owner choose to use
another utility, she has to abide every aspect of the new tool, thus
inherently makes any unconventional feature of the preceding tool to
become void.
Usually the partitioning tools show warnings before writing anything on
disk, exactly for this reason. And the ones which did write bits of
their own (usually at install time) in "unused" or "reserved" areas have
always been bashed for that.
>> You must accomodate GPT, which is the only standard in town for >2TB
>> (and NO, you do NOT want to invent another standard here! please!)
>
> Well, custom OS development is all about breaking new ground so, why
> not! ;-)
round one is already there!
Said otherwise, if you really insist in designing a new scheme to
supplant GPT, it has to be better than GPT, not just different.
> Specifically about GPT, from what I have found, MBR and GPT formats
> are effectively mutually exclusive even despite the attempt at
> compatibility.
between both formats, probably in a attempt to avoid maintenance
headaches later; but at the design level, they are compatible, as things
like Hackintoshes or even Boot Camp show.
Remember, even if some marketing people would like you to think
otherwise, EFI and GPT are really two separate things.
>> Note this outright kills the "pure" #1 and #4 schemes:
>
> True, if a disk is set up for GPT it does kill #1 and #4 but then with
> GPT the whole disk setup is different so a GPT disk would have
> different code in the MBR sector if it had code there at all.
on so-called "hybrid GPT" disks, with several distinct solutions.
I believe the fact there were not much enthusiasm about it is more
because partitioning and multi-booting is much less of interest these
days, because of lower HD costs and the rising use of virtualization.
> There is another issue. ISTM most/all of such boot loaders (which
> start code that sits within an OS partition before selecting the OS to
> boot) require not just that the code in that partition is not moved
> and overwritten but that they are overly tied in with the OS which
> occupies that partition.
of their own, just that their running lifetime is expected to be short
and their outcome is NOT to manage the whole hardware just like a
operating system does.
Whenever any system relies on some data storage, there is a link
created; if the boot loader choose to store its files (including the
code bits) in a data volume, it obviously has a dependency on that data
volume. Since this is a point of weakness, many designers tried to avoid
it and stored their data "elsewhere"... which is another weakness,
particularly with the MBR scheme, in effect that that data can be
disposed of without notice...
> Say you had a Windows partition,
partition"; at most there are a partition created by Windows, which
hosts the (NTFS) system volume of a Windows system. But of course you
are perfectly allowed to access that volume using other systems.
> Say you had a Windows partition, for example, and decided to remove it.
any future use of any data stored on it; whether you installed an
operating system, a boot loader, or a database on it does not change
anything: all become useless.
Just because a boot loader being a smaller system makes it easier to be
forgotten about; but the same can be said on anything which is stored on
the disk.
> That said, pre-OS network boot may have some much bigger issues.
> AFAIK, the BIOS provides no network device calls and I'm not sure
> whether there is a practical way to control network cards in what I
> envisage as a boot partition.
attempts at standardization, but the dust has settled now and any
non-EFI BIOS uses Universal Network Device Interface (usually seen as a
part of "PXE booting".)
Antoine
James Harris
Apr 27, 2012, 4:42:29 PM4/27/12
to
On Apr 23, 9:55 am, Antoine Leca <r...@localhost.invalid> wrote:
...
> > Well, custom OS development is all about breaking new ground so, why
> > not! ;-)
>
> Because there is no value wasting time inventing square wheels; and the
> round one is already there!
An amusing illustration but essentially overstated. It is good to use
what exists in some cases and to invent something new in others.
Yes, early wheels were round but a lot of them were solid!! If people
never invented anything new we would not have had pneumatic tyres.....
Let's not take this too far. Sometimes compatible is good. Sometimes
new is good. And sometimes knowing which is best is also good. ;-)
> Said otherwise, if you really insist in designing a new scheme to
> supplant GPT, it has to be better than GPT, not just different.
Of course. My comment was more abstract: not to discourage someone
from at least considering breaking new ground.
> > Specifically about GPT, from what I have found, MBR and GPT formats
> > are effectively mutually exclusive even despite the attempt at
> > compatibility.
>
> I disagree. Some implementations specifically excludes compatibility
> between both formats, probably in a attempt to avoid maintenance
> headaches later; but at the design level, they are compatible, as things
> like Hackintoshes or even Boot Camp show.
They may be similar but the MBRs are different. See below.
> Remember, even if some marketing people would like you to think
> otherwise, EFI and GPT are really two separate things.
>
> >> Note this outright kills the "pure" #1 and #4 schemes:
>
> > True, if a disk is set up for GPT it does kill #1 and #4 but then with
> > GPT the whole disk setup is different so a GPT disk would have
> > different code in the MBR sector if it had code there at all.
>
> Again I disagree: people have successfully installed multi-boot systems
> on so-called "hybrid GPT" disks, with several distinct solutions.
I think I see your point in principle but consider: if the disk has a
traditional partition table the MBR code would normally locate the
bootable partition and start it. If the disk is GPT partitioned the
MBR code would (I guess, tell me if I am wrong) look for a bios boot
partition by UUID. My inference was that if the MBR code is different
then the fact that GPT kills #1 and #4 only applies to GPT. There's
nothing to stop scheme #1 being used on a non-GPT disk, for example.
That said, this is an academic point. I think we've agreed that a boot
partition is a better idea.
> I believe the fact there were not much enthusiasm about it is more
> because partitioning and multi-booting is much less of interest these
> days, because of lower HD costs and the rising use of virtualization.
Agreed. There are good reasons to move away from having multiple
bootable operating systems on one disk. That said, not everyone has
realised that there can be other reasons for presenting a boot menu.
> > There is another issue. ISTM most/all of such boot loaders (which
> > start code that sits within an OS partition before selecting the OS to
> > boot) require not just that the code in that partition is not moved
> > and overwritten but that they are overly tied in with the OS which
> > occupies that partition.
>
> I do not see it this way. For me, those boot loaders are really systems
> of their own, just that their running lifetime is expected to be short
> and their outcome is NOT to manage the whole hardware just like a
> operating system does.
> Whenever any system relies on some data storage, there is a link
> created; if the boot loader choose to store its files (including the
> code bits) in a data volume, it obviously has a dependency on that data
> volume. Since this is a point of weakness, many designers tried to avoid
> it and stored their data "elsewhere"... which is another weakness,
> particularly with the MBR scheme, in effect that that data can be
> disposed of without notice...
Right. The idea which seemed most popular on this thread seems much
better in a number of ways.
...
> > That said, pre-OS network boot may have some much bigger issues.
> > AFAIK, the BIOS provides no network device calls and I'm not sure
> > whether there is a practical way to control network cards in what I
> > envisage as a boot partition.
>
> If with BIOS you mean the IBM PC architecture, there have been several
> attempts at standardization, but the dust has settled now and any
> non-EFI BIOS uses Universal Network Device Interface (usually seen as a
> part of "PXE booting".)
OK
James
...
> > Well, custom OS development is all about breaking new ground so, why
> > not! ;-)
>
> Because there is no value wasting time inventing square wheels; and the
> round one is already there!
what exists in some cases and to invent something new in others.
Yes, early wheels were round but a lot of them were solid!! If people
never invented anything new we would not have had pneumatic tyres.....
Let's not take this too far. Sometimes compatible is good. Sometimes
new is good. And sometimes knowing which is best is also good. ;-)
> Said otherwise, if you really insist in designing a new scheme to
> supplant GPT, it has to be better than GPT, not just different.
from at least considering breaking new ground.
> > Specifically about GPT, from what I have found, MBR and GPT formats
> > are effectively mutually exclusive even despite the attempt at
> > compatibility.
>
> I disagree. Some implementations specifically excludes compatibility
> between both formats, probably in a attempt to avoid maintenance
> headaches later; but at the design level, they are compatible, as things
> like Hackintoshes or even Boot Camp show.
> Remember, even if some marketing people would like you to think
> otherwise, EFI and GPT are really two separate things.
>
> >> Note this outright kills the "pure" #1 and #4 schemes:
>
> > True, if a disk is set up for GPT it does kill #1 and #4 but then with
> > GPT the whole disk setup is different so a GPT disk would have
> > different code in the MBR sector if it had code there at all.
>
> Again I disagree: people have successfully installed multi-boot systems
> on so-called "hybrid GPT" disks, with several distinct solutions.
traditional partition table the MBR code would normally locate the
bootable partition and start it. If the disk is GPT partitioned the
MBR code would (I guess, tell me if I am wrong) look for a bios boot
partition by UUID. My inference was that if the MBR code is different
then the fact that GPT kills #1 and #4 only applies to GPT. There's
nothing to stop scheme #1 being used on a non-GPT disk, for example.
That said, this is an academic point. I think we've agreed that a boot
partition is a better idea.
> I believe the fact there were not much enthusiasm about it is more
> because partitioning and multi-booting is much less of interest these
> days, because of lower HD costs and the rising use of virtualization.
bootable operating systems on one disk. That said, not everyone has
realised that there can be other reasons for presenting a boot menu.
> > There is another issue. ISTM most/all of such boot loaders (which
> > start code that sits within an OS partition before selecting the OS to
> > boot) require not just that the code in that partition is not moved
> > and overwritten but that they are overly tied in with the OS which
> > occupies that partition.
>
> I do not see it this way. For me, those boot loaders are really systems
> of their own, just that their running lifetime is expected to be short
> and their outcome is NOT to manage the whole hardware just like a
> operating system does.
> Whenever any system relies on some data storage, there is a link
> created; if the boot loader choose to store its files (including the
> code bits) in a data volume, it obviously has a dependency on that data
> volume. Since this is a point of weakness, many designers tried to avoid
> it and stored their data "elsewhere"... which is another weakness,
> particularly with the MBR scheme, in effect that that data can be
> disposed of without notice...
better in a number of ways.
...
> > That said, pre-OS network boot may have some much bigger issues.
> > AFAIK, the BIOS provides no network device calls and I'm not sure
> > whether there is a practical way to control network cards in what I
> > envisage as a boot partition.
>
> If with BIOS you mean the IBM PC architecture, there have been several
> attempts at standardization, but the dust has settled now and any
> non-EFI BIOS uses Universal Network Device Interface (usually seen as a
> part of "PXE booting".)
James
Harry Vaderchi
Apr 28, 2012, 10:25:32 AM4/28/12
to
On Fri, 27 Apr 2012 21:42:29 +0100, James Harris
<james.h...@gmail.com> wrote:
> On Apr 23, 9:55 am, Antoine Leca <r...@localhost.invalid> wrote:
>
> Agreed. There are good reasons to move away from having multiple
> bootable operating systems on one disk. That said, not everyone has
> realised that there can be other reasons for presenting a boot menu.
I'd really like a boot menu with mouse support (just scroll up and down
<james.h...@gmail.com> wrote:
> On Apr 23, 9:55 am, Antoine Leca <r...@localhost.invalid> wrote:
>
> Agreed. There are good reasons to move away from having multiple
> bootable operating systems on one disk. That said, not everyone has
> realised that there can be other reasons for presenting a boot menu.
text menus), but I guess that would make the system bloated.
>
> James
--
[dash dash space newline 4line sig]
Albi CNU
BGB
Apr 28, 2012, 10:38:23 AM4/28/12
to
installable EFI;
allows booting the OS as if it were EFI but without needing an EFI BIOS.
then again, I think something like this already exists...
back in my OS development days, I usually just booted from a FAT
filesystem (later on with a PE/COFF kernel no-less), and FAT is also the
defined FS of EFI as well.
so, say:
MBR loads, finds boot partition in GPT;
jumps to boot loader there;
boot loader there pulls up menu, and allows doing the usual thing
(booting default OS after N seconds, or allowing the user to hit a key
to do something different).
or such...
0 new messages