From Newsgroup: comp.os.msdos.misc

Hello all,

I've got a IBM ThinkPad A21e here, and thought that it perhaps could do something for me with DOS 5 installed on it.

So, I booted from a CD with DOS 5 on it, created a bootable primary
partition and did a "format /u /s" (unconditional, copy system files) on the newly-created C: partition.

Alas, after rebooting all I get is a non-responding system with a blinking cursor in the upper-left of the screen.

The thing is that I can't remember anymore what caused or how to fix it.
I could do with a bit of help. :-)

Regards,
Rudy Wieser


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.msdos.misc

The thing is that I can't remember anymore what caused or how to fix it. I could do with a bit of help. :-)

I realised/remembered that its the MBR code which searches for a specific OS file, and than loads & starts it. A quick "fdisk /mbr" (started from the
CD) was all that was needed.

Regards,
Rudy Wieser


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.msdos.misc

On Sat, 26 Sep 2020 19:21:49 +0200, R.Wieser wrote:

I realised/remembered that its the MBR code which searches for a specific OS file, and than loads & starts it.

Actually, it's the partition boot sector (PBR) that finds and loads OS specific boot file. i.e.

MBR -> PBR -> OS boot file

MBR finds the active partition then load its boot sector.

As long as boot manager isn't involved, that is.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.msdos.misc

On 9/26/20 11:21 AM, R.Wieser wrote:

I realised/remembered that its the MBR code which searches for a
specific OS file, and than loads & starts it.

Eh ... I don't quite agree with that. (More below.)

A quick "fdisk /mbr" (started from the CD) was all that was needed.

Rudy, you've caused me to spend the better part of an hour messing with something that has been nagging at me for years.

Why do I have to install the Linux boot loader in the MBR?
Especially when the various installation tools so clearly support
installing into the partition and /not/ the MBR.

So ... I busted out a VM and installed Linux, set the partition active,
and installed LILO to the partition instead of the MBR. Sure enough --
true to my decades of experience -- the VM wouldn't boot.

Then I (re)booted a MS-DOS disk and ran "fdisk /mbr" without changing
anything else. And lo the system booted perfectly fine.

It seems as if the boot code in the /Master/ Boot Record searches the partition table to identify thee /active/ partition and then starts the /Volume/ Boot Record therefrom.

Now where we get to the part that makes me question the veracity of your statement.

It seems to me that the MBR does something other than searches for a
specific OS file to load and start.

Upon researching this further, it seems as if the MBR searches for the /active/ partition and loads the VBR from it. It seems to be the OS
specific VBR that searches for a specific OS file to load and start.

In hindsight, this makes sense if you consider that it's possible to
boot multiple different operating systems on a PC simply by changing the active partition.

Also, thank you for prompting me to finally spend some time answering
the mildly nagging question that I've been ignoring for decades.
--
Grant. . . .
unix || die
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.msdos.misc

JJ,

Actually, it's the partition boot sector (PBR) that finds and loads
OS specific boot file. i.e.

Oh my ... You're absolutily right ofcourse. How the heck could I have forgotten the BR (or PBR as you named it) step - or rather, mixed the MBR
and PBR steps together.

As long as boot manager isn't involved, that is.

Its funny that you say that, as before I installed DOS on it the GRUB bootloader appeared. I guess that it didn't want to play nice with
something as old as DOS.

IOW, in retrospect I think it was GRUB that was freezing up, trying to find
a bootable OS.

Regards,
Rudy Wieser


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.msdos.misc

Grant,

Eh ... I don't quite agree with that. (More below.)

And you're quite right in that. As JJ made clear to me, I (somehow) threw
the MBR and VBR steps together.

Why do I have to install the Linux boot loader in the MBR?

As far as I can tell, you don't. But as long as all your OSes are put into primary partitions there simply is no space elsewhere.

That makes me think that I've never tried to make a logical drive in a secondary partition bootable ...

.... Thats not quite true. I once did put several DOS versions into logical volumes in an extended partition, but could not successfully boot those DOS volumes, because the OS itself expected to be in the first, primary
partition. Bummer.

It seems as if the boot code in the /Master/ Boot Record searches the partition table to identify thee /active/ partition and then starts the /Volume/ Boot Record therefrom.

Almost. It as easily could load the first sector of an extended partition (which behaves as another MBR). Which than ofcourse goes nowhere (no
"active partition" flag set) and the machine simply fails to boot.

So ... I busted out a VM and installed Linux, set the partition active,
and installed LILO to the partition instead of the MBR. Sure enough --
true to my decades of experience -- the VM wouldn't boot.

Then I (re)booted a MS-DOS disk and ran "fdisk /mbr" without changing anything else. And lo the system booted perfectly fine.

Hmmm... that sounds mighty strange. You didn't touch the MBR when installing LILO, but rewriting it afterwards (while not removing LILO) made the problems go away ? Thats odd. Almost as if it would not have booted /before/ installing LILO either ...

Did you still have LILO pop up afterwards ? Or was it gone ? If so, how
?

It seems as if the boot code in the /Master/ Boot Record searches the partition table to identify thee /active/ partition and then starts the /Volume/ Boot Record therefrom.

It does when everything works and is configured correctly / as expected.
But again, moving that "active" flag to another record (even if it /doesn't/ point to a primary partitions VBR) isn't difficult - especially not under
DOS.

Also, thank you for prompting me to finally spend some time answering the mildly nagging question that I've been ignoring for decades.

I'm not at all sure which question that was, but you're welcome. :-)

Regards,
Rudy Wieser


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.msdos.misc

On 9/26/20 2:13 PM, R.Wieser wrote:

I guess that it didn't want to play nice with something as old as DOS.

GRUB should play perfectly fine with DOS.
--
Grant. . . .
unix || die
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.msdos.misc

On 9/26/20 3:26 PM, R.Wieser wrote:

Grant,

Hi Rudy,

And you're quite right in that. As JJ made clear to me, I (somehow)
threw the MBR and VBR steps together.

;-)

As far as I can tell, you don't. But as long as all your OSes are
put into primary partitions there simply is no space elsewhere.

No, I was asking why I have to install the Linux boot loader into the
MBR vs the PBR (a.k.a. VBR)

That makes me think that I've never tried to make a logical drive in
a secondary partition bootable ...

What do y ou mean by "/secondary/ partition"?

I'm used to "primary" / "extended" / "logical" partitions in the MS-DOS PC-BIOS nomenclature.

..... Thats not quite true. I once did put several DOS versions into logical volumes in an extended partition, but could not successfully
boot those DOS volumes, because the OS itself expected to be in the
first, primary partition. Bummer.

I think it only mattered that it was a /primary/ partition, not a
logical partition. At least as far as booting is concerned. (Things
other than io.sys, msdos.sys, command.com, config.sys, and autoexec.bat,
can tend to be anywhere and referenced, even in logical partitions on
other drives.)

Aside: Have you ever played with having more than 24 primary + logical partitions? MS-DOS gets unhappy and complains about running out of
drive letters.

Almost. It as easily could load the first sector of an extended
partition (which behaves as another MBR). Which than ofcourse goes
nowhere (no "active partition" flag set) and the machine simply fails
to boot.

I don't think so.

The testing that I did today, along with the recent reading, /really/
suggests that the boot code that MS-DOS puts in the MBR really does
search for the active partition and then loads the VBR / PBR (depending
on what you want to call it). ... Keep reading.

Hmmm... that sounds mighty strange. You didn't touch the MBR when installing LILO, but rewriting it afterwards (while not removing LILO)
made the problems go away ?

That's correct.

Thats odd.

No, it's not.

Take a blank (or first part zeroed) drive and:

1) Partition it into three partitions:
/dev/hda1 - 28 MB for DOS
/dev/hda2 - 2 GB for Linux
/dev/hda3 - 256 MB for swap.
2) Install Linux into the 2 GB partition.
3) Install LILO into the 2 GB partition.

The system won't boot. Here's why. There is no boot code in the MBR.
The only thing in the MBR is the partition table.

The only thing that partitioning did to the MBR was alter the partition
table. The rest of the MBR, specifically the boot code at the start of
thee MBR, is still zeros. Thus there is nothing for the system to boot.

Formatting (/s or otherwise) C: (/dev/hda1) and installing MS-DOS
doesn't even make the system bootable. Neither does SYSing C:.

Here's the kicker: Both LILO (as used in this case) and SYS (or format
/s) install the PBR (VBR) inside of their respective partitions
(volumes). As such, the actual boot code remains blank. Hence why the
system won't boot.

Enter "fdisk /mbr". fdisk /mbr installs the boot sector code inside of
the MBR. This boot sector code searches for the active partition and
chain loads the PBR (VBR) of the active partition.

Almost as if it would not have booted /before/ installing LILO
either ...

I hope you can tell that installing LILO into the partition puts it in
the PBR (VBR), which is not in and of itself enough to boot the system.
There /must/ be some boot code in the MBR.

Did you still have LILO pop up afterwards ?

Yes, LILO worked perfectly fine /after/ doing the fdisk /mbr.

Remember, LILO wasn't working at all /before/ doing the fdisk /mbr.


So ... you'll love this ... fdisk /mbr actually /fixed/ LILO.

Or was it gone ?

Nope. LILO was exactly like it had been left.

Remember:

1) LILO was in the PBR (VBR), not the MBR.
2) fdisk /mbr altered the MBR, not the PBR (VBR).
3) PBR (VBR) rea MBR. They are two completely different places.

If so, how ?

fdisk /mbr provided the boot code that goes into the MBR.

Said boot code chain loaded the PBR (VBR) of the active partition.

I can change what OS the system boots simply by twiddling which
partition is active.

It does when everything works and is configured correctly / as
expected.

Please clarify your statement. I can't tell if you are agreeing with my statement (copied below for convenience).

"It seems to me that the MBR does something other than searches for a
specific OS file to load and start."

Or if you are defending your original statement (copied below for convenience).

"MBR code which searches for a specific OS file, and than loads & starts
it."

But again, moving that "active" flag to another record ...
isn't difficult - especially not under DOS.

No it is not.

... (even if it /doesn't/ point to a primary partitions VBR) ...

I don't think it's possible to boot (as in load a PBR (VBR)) from an /extended/ partition.

Remember that an /extended/ partition is a special /primary/ partition
in that it contains additional partitions.

At least it's not possible with the tools that Microsoft has provided,
be it MS-DOS or subsequent OSs. This probably extends to the boot code
that Microsoft's fdisk installs with fdisk /mbr.

Perhaps other non-Microsoft boot code -- which can be installed in the
MBR -- does support this.

Aside: I've not tested getting LILO or GRUB to chain load things from /logical/ partitions as I personally try to avoid them. I feel that
/logical/ partitions are an unnecessary abstraction layer. If I don't
need it, I don't use it. Seeing as how I can use primary partitions
directly. Well, there haven't been very many /extended/ partitions
around me.

I'm not at all sure which question that was, but you're welcome. :-)

I think the question was "Why doesn't LILO (or GRUB) boot a system when
it's installed to a partition (PBR / VBR) and the partition is marked active?".

I've come to learn that the answer is that neither LILO nor GRUB install anything into the MBR when they are installed into the PBR (VBR), and
that the system requires boot code in the MBR to be able to boot.
--
Grant. . . .
unix || die
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.msdos.misc

Grant,

PBR - /Logical/ Partition's Boot Record

I have absolutily /no/ idea what a "logical" partition is supposed to be (or what a non-logical one looks like), they all look quite logical to me. :-)

PBR -> an extended partition's boot record.

I believe I saw Partition Boot Record (PBR) used elsewhere in the thread
and simply followed suit.

And so did I.

I've been using the following nomenclature.

/Primary/ Partition - any partition that can be normal PC-BIOS MBR
partition table.

That does not compute : A partition cannot also be a partition table (you probably ment something different there).

/Extended/ Partition - a /special/ primary partition in that it can
contain one or more logical partitions.

An extended partition can contain two types of partitions, you just named
one ...

/Logical/ Partition - a partition that lives inside the extended
partition.

I'm sorry, but you're going circular there (back to the "extended
partition"), not clarifying anything.

My definitions :

Primary partition - a logical volume / disk, directly referred to by the
MBR.

Extended partition - a partition that can hold a logical volume / disk as
well as another extended partition.

So, primary partition, extended partition, logical volume / disk.

Huh? /Ofcourse/ there is. And I have no idea how you, in regard to
the above quote, came up with that.

Your choice of words; "...install a partition /manager/ at the
location...".

Yes ? And ? How would that mean that I could/would be thinking that a partition table is the same as a program which manages it ? I do not get
it.

That implies to me that you're talking about something that doesn't manage partitions -> partitioning. Given the overall context of this thread, you are /probably/ referring to a boot manager as in something that picks what to boot. (Supported by your "Yes, I did." statement.)

Bingo !

But, you're right. It would be better if I would have used the description "boot manager"instead of "partition manager". Sorry.

Doing a little bit of research, here's my current understanding.

BIOS -> MBR -> VBR -> OS
-or-
BIOS -> MBR -> EBR -> OS
-or-
BIOS -> MBR -> EBR -> EBR -> OS
-or-
...chain as many EBRs as desired.

Not quite. The squence after the MBR and EBR should (ofcourse) be the
same.

BIOS -> MBR -> VBR -> OS
-or-
BIOS -> MBR -> EBR -> VBR -> OS

Than again, not all VBRs are followed by an OS ... Currently only a primary partition can contain a bootable OS. And not even all of those need to
contain an OS. Just take the Linux swap partition. :-)

Each PBR in that chain would, next to some "boot code", either have the
next Extended Partition flagged as "bootable", or its contained Logical
Volume / Logical Drive.

I'm not 100% sure how the active status would work.

I /think/ it the BIOS -> MBR -> EBR -> EBR -> OS scenario would play out like this:

1) BIOS loads MBR boot code.
2) MBR boot code loads the 1st EBR boot code.
3) 1st EBR boot code loads the 2nd EBR boot code.
4) 2nd EBR boot code loads the OS.

Yep, exactly that.

I'm about 99% certain that I've accessed multiple primary partitions from MS-DOS. So I am not okay with making the assumption that the second partition will be an extended partition.

Why do you think I specifically mentioned "a *simple* conversation" ? :-p

The picture gets a bit different when talking about Linux, where the
second entry in the MBR normally points to the OS partition.

That is a dangerous assumption. It is also heavily date dependent.

Why do you think I said "normally" ?

Have fun with referring to the secondary, primary partition. :-)

/dev/hda2

Really ? Than imagine that the first partition being either empty or an extended partition. That would make the primary partition at the second position in the MBRs partition table the /first/ primary partition, not the secondary one. The secondary, primary partition could even be at the fourth position.

Assuming /dev/hda.

Who just said that making assumptions is dangerous ? Just imagine that
the first physical drive has only a single primary partition. Where could
the secondary, primary partition than be ?

The first partition on the drive could be the 4th primary partition.

And thats yet another way to make that "secondary, primary partition" reference problematic.

I vote "not used anymore".

And so do I. But ofcourse that example was a bit contrivedl. Just look
at our misunderstandings because our definitions of certain things did not align and made it hard to understand what the other was talking about.

Does that happen in MBR style partitioned drives? Or does that jump into GPT style partitioned drives?

I have /very/ little experience with GPT drives I'm afraid

And thats ignoring the Extended Partition. It can have a secondary,
tertiary, etc. chain of Extended Partitions inside it.

The chain of EBRs is actually quite easy to follow and number.

True. But so are primary partitions, and we just figured out that its not /that/ easy.

In that case I hope you only install LILO into a single VBR ... Do it for >> two and the last one might overwrite the info of the first.

Why? I can install different instances of LILO in different VBRs and
choose which one is booted based on the active flag.

Why ? Read the direct line above it again please. Than explain how that
that /doesn't/ happen.

That you /can/ install two instances of LILO means that the LILO guys
realised which problem would occur, and figured something out to fix/forgo
it.

Grub wants / needs more space than is unused in the first track.

Sigh. Every programs gets "features" added until it grows outof proportions. Even under Linux ...

Regards,
Rudy Wieser


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.msdos.misc

On 9/29/20 8:33 PM, Grant Taylor wrote:

I'm doing another test that's going to take a while.-a I'll reply with
the results later.

Yep. I was able to do what I thought I could do.

I installed four copies of Linux, each into it's own /primary/
partition. (Swap was a /primary/ partition on a different drive.)

I installed LILO as the /Volume/ Boot Record inside of each /partition/ (/volume/).

Then I used "fdisk /mbr" to add boot code to the /Master/ Boot Record.

The MS-DOS boot code in the /MBR/ looked for the active partition
(volume) and chain loaded the /VBR/ -> LILO.

To make sure that I wasn't confusing things, I added a unique message to
each of the partition's LILO so that I could differentiate them from
each other.

Sure enough, I have /four/ different and unique instances of LILO
installed. One in each /V/BR.

Aside: MS-DOS's boot code doesn't like multiple partitions being marked active. Something that can be done from Linux's fdisk.
--
Grant. . . .
unix || die
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.msdos.misc

Because of who I am and the type of person that I am, I kept ... messing.

On 9/29/20 9:12 PM, Grant Taylor wrote:

I installed LILO as the /Volume/ Boot Record inside of each /partition/ (/volume/).

Then I used "fdisk /mbr" to add boot code to the /Master/ Boot Record.

I have /now/ /added/ LILO to the /Master/ Boot Record.

The MS-DOS boot code in the /MBR/ looked for the active partition
(volume) and chain loaded the /VBR/ -> LILO.

LILO in the /MBR/ presents a menu to choose which /VBR/ I want to chain
load.

The /VBR/ still loads LILO too.

To make sure that I wasn't confusing things, I added a unique message to each of the partition's LILO so that I could differentiate them from
each other.

Each LILO has a different message file.

MBR = "mbr"
VBR(1) = "hda1"
VBR(2) = "hda2"
VBR(3) = "hda3"
VBR(4) = "hda4"

Sure enough, I have /four/ different and unique instances of LILO installed.-a One in each /V/BR.

/Now/ I have /five/ different and unique instances of LILO installed.
One in the /M/BR and one in each /V/BR..
--
Grant. . . .
unix || die
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.msdos.misc

On 9/29/20 9:50 PM, Grant Taylor wrote:

Because of who I am and the type of person that I am, I kept ... messing.

I really can't leave well enough alone.

It took some doing -- there are a LOT of fiddly little bits -- but I got
LILO installed in the following locations:

- MBR (hda)
- vbr1 - chain load VBR1
- ebr3 - chain load EBR3
- VBR1 (hda1)
- hda1 - loads kernel off of hda1
- mbr - chain load MBR
- EBR3 (hda3)
- vbr5 - chain load VBR5
- mbr - chain load MBR
- VBR5 (hda5)
- hda5 - loads kernel off of hda5
- mbr - chain load MBR

So, I can do the following:

BIOS -> MBR -> EBR3 -> VBR5 -> OS (kernel)

So, I have now successfully booted code out of an extended and logical partition.
--
Grant. . . .
unix || die
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.msdos.misc

Grant,

What can I say. 20 years of "/Primary/ partition" ... "/Extended/ partition" ... "/Logical/ ..." and I didn't see the forest for the trees.

Sorry about that.

Don't worry about it. I'm no stranger to making (similar?) mistakes myself (VMB vs VBR). :-)

To me, the extended partition is the entry defined in one of the primary partition slots in the MBR partition table.

I was busy writing a full reply pointing out how rejecting existing definitions without offering something else, let alone better, is rather counter productive until I noticed thats pretty-much all you're doing.

Also, when you reject a definition such as "a secondary/embedded Extended Partition" (the one(s?) inside the first/main one) than you definitily
should /not/ refer to that secondary/embedded Extended Partitions first
sector as an EBR. You can't have it both ways.

As I do not see you come up with replacement definitions for the ones that
you have been rejecting I don't think that further conversation about this subject is possible (as I already mentioned, I have no wish to be part of a guessing game, nor do I wish to use full sentences for what earlier was defined by as little as two words).

As such, I'm going to end our conversation here. Goodbye.

Regards,
Rudy Wieser


--- Synchronet 3.21d-Linux NewsLink 1.2