old IBM ThinkPad boots fine from a CDROM with DOS 5 but doesn't from HD

[R.Wieser]

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

[R.Wieser]

> 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

[JJ]

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.

[Grant Taylor]

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

[R.Wieser]

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

[R.Wieser]

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

[Grant Taylor]

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 Taylor]

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) ≠ 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.

[R.Wieser]

Grant,

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

Ah, than we have a definition confusion. I understood the VBR to be the
Volume boot record, alike the BR of a floppy, the first sector of a logical
drive & primary partition (a primary partition is a defacto logical drive).

I took the PBR to be the first sector of an extended partition. It has a
partition table with just two entries : the first pointing to another PBR of
the next "extended partition" (inside the current one), and the second
pointing to the VBR of a logical drive. Each PBR is followed by unused
(filler) sectors, just like with and for the same reason as, the MBR.

So, three BR types. The MBR (the start of the physical drive), The VBR (the
start of a logical volume) and the PBR (the start of an extended partition).

It /should/ be possible to install a partition manager at the location of a
PBR just as with an MBR. It would have to be a bit different manager
though, as it would need to gather the logical volumes by following the
chain of PBRs.

And ofcourse the partition manager would need to be run by having a series
of "bootable" flags in the MBR and following PBR sectors (the PBR would also
need to have boot code alike the MBR).

> What do y ou mean by "/secondary/ partition"?
>
> I'm used to "primary" / "extended" / "logical" partitions in the MS-DOS
> PC-BIOS nomenclature.

The problem is that "secondary partition" is ambigue to me. I always take
it as referring to the second MBR entry - which could point to another
primary partition (not unexpected in a multi-boot environment), or more
commonly to an extended partition (on a DOS configuration with multiple
logical drives).

And in our context you might even have referred to the second "extended
partition" inside a first one ...

> I think it only mattered that it was a /primary/ partition, not a logical
> partition.

AFAICR it was even worse : DOS only wanted to boot from the first partition
(which ofcourse needed to be a primary one). As if it ignored the "offset
sectors" (from the start of the drive to the VMB, stored in the VMB), but
just took the number of sectors-per-track for it. At least, that was my
guess at the time.

> 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.

I never did (never had a drive large enough :-) ), but remember that there
was at least one DOS version which, after exhausting the first letter,
happily used two letters for the drive (AA, AB, etc).

> 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

No, and yes. The MBR code searches for a /record/ (inside the MBR itself)
that has that flag set. It than simply loads the pointed-to sector
(normally a VMB) and jumps to the first byte of it. It could not care
less of if that sector is actually the start of a partition, much less if
its a primary one. Its code is just that dumb.

>> 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.

I just checked where LILO could be installed. It looks like to be small
enough to be placed in the VMB. One mistery down.

> 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.

:-) That was what I ment with that the system probably would not have
booted /before/ you installed LILO either. IOW, your mentioning of LILO was
just a red herring.

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

Yup, and exactly that which I had forgotten and the reason for me having
started this thread. Though in my case the MBR contained the (remnants of)
the GRUB boot manager (I used the DOS 5 FDISK to erase the old ones and
create new DOS partitions).

> 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.

I didn't know that LILO could be put in the VBR (assumed it needed a number
of sectors, limiting it to the MBR and perhaps PBR), hence my confusion.

And to be pedantic about it : Not "/some/ boot code", but /working/ boot
code - mine did still contain (remnants of ?) the GRUB bootloader. :-p

>> Did you still have LILO pop up afterwards ?
>
> Yes, LILO worked perfectly fine /after/ doing the fdisk /mbr.

I can imagine that.

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

Another red herring : LILO was not called (the boot process broke down
before it), so it /ofcourse/ didn't attempt to do any work.

>> It does when everything works and is configured correctly / as expected.
>
> Please clarify your statement.

My expectation was that the GRUB bootloader would keep working even after I
deleted the old partitions and created a few new ones. It didn't. Looking
back either GRUB didn't work anymore, or it was, for the new situation,
misconfigured.

> 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."

:-) The very first thing I did in my first reply to you was to agree that I
made a mistake in the latter. In other words, I rescinded my position in
that and agreed to yours (and JJ's).

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

Why not ? Its just a matter of (pretty-much) copying the MBR boot-code into
the PBR and setting the "bootable" flag for the second record (pointing to
the VBR of a logical volume).

> At least it's not possible with the tools that Microsoft has provided,

Says the man who just used LILO. :-)

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

No, you would not not need to touch the code in the MBR for that. Just
moving the "bootable" flag to a record pointing to a PBR should be enough to
load that PBR sector and (presuming it has the the AA 55 signature in its
last two bytes) jump to its first byte (just as for a VBR).

>> 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.

And I've come to learn that LILO can be installed in the VBR of a logical
drive, whereas I presumed it could only be installed in/over the MBR (and
following "filler" sectors). Also that, when you repartition everything
(especially to another OS), its a good idea to run an "fdisk /mbr"
afterwards.

... which does make this a good thread.

Regards,
Rudy Wieser

[Grant Taylor]

On 9/27/20 3:49 AM, R.Wieser wrote:
> Grant,

Hi,

> Ah, than we have a definition confusion. I understood the VBR to be
> the Volume boot record, alike the BR of a floppy, the first sector of
> a logical drive & primary partition (a primary partition is a defacto
> logical drive).
>
> I took the PBR to be the first sector of an extended partition.

Please expand the "PBR" abbreviation that you were using. Because I get
the impression that "P" wasn't "Partition".

For clarity, I thought that Volume Boot Record (VBR) and Partition Boot
Record (PBR) were synonymous and that's how I had been using them.

> It has a partition table with just two entries : the first pointing to
> another PBR of the next "extended partition" (inside the current one),
> and the second pointing to the VBR of a logical drive. Each PBR is
> followed by unused (filler) sectors, just like with and for the same
> reason as, the MBR.

Hum. I need to do some more reading about how Extended & Logical
partitions work in MS-DOS. I glossed over the actual partition table
structure while focusing on the various boot records (xBR).

> So, three BR types. The MBR (the start of the physical drive),
> The VBR (the start of a logical volume) and the PBR (the start of an
> extended partition).

Oy vey. "logical volume" is overloaded there. It seems as if you are
using it to reference any partition that is not defined by the drive's
physical properties. But it can also reference what Microsoft calls a
"Logical Partition" inside of an Extended Partition.

> It /should/ be possible to install a partition manager at the location
> of a PBR just as with an MBR. It would have to be a bit different
> manager though, as it would need to gather the logical volumes by
> following the chain of PBRs.

To me there is a difference in a partition table and a utility to manage
the partition table (partition manager).

Or are you making some sort of reference to a boot manager?

> And of course the partition manager would need to be run by having

> a series of "bootable" flags in the MBR and following PBR sectors
> (the PBR would also need to have boot code alike the MBR).

Now it sounds like you're talking about a boot manager.

/If/ such were to work, I would expect there to be two bootable (active)
flags. The first in the partition table in the MBR and the second in
the partition table in the extended partition.

Of course, this is a two layer system. Hypothetically, we can go
turtles all the way down how ever deep we want to go. But each layer
gets more complicated.

> The problem is that "secondary partition" is ambigue to me. I always
> take it as referring to the second MBR entry - which could point to
> another primary partition (not unexpected in a multi-boot environment),
> or more commonly to an extended partition (on a DOS configuration
> with multiple logical drives).

So you're using "secondary" as a reference to the second partition in
the main MBR partition table.

Does that mean that "tertiary" is a reference to the third partition?

> And in our context you might even have referred to the second "extended
> partition" inside a first one ...

True.

Which is why I always disliked referencing the partition by count as
they appear on the drive.

I strongly prefer how under Linux, the primary / extended partitions
show up as partitions 1-4, and logical partitions show up as 5+.

> AFAICR it was even worse : DOS only wanted to boot from the first

> partition (which of course needed to be a primary one).

I had somehow forgotten that limitation.

> As if it ignored the "offset sectors" (from the start of the
> drive to the VMB, stored in the VMB), but just took the number of
> sectors-per-track for it. At least, that was my guess at the time.

What do you mean by "VMB"?

I don't think it can be as simple as an offset from the start of the
drive. I can successfully boot when the first partition is multiple
cylinders (?) in from the start of the drive.

> I never did (never had a drive large enough :-) ),

I did it playing with tiny logical partitions in a VM.

> but remember that there was at least one DOS version which, after
> exhausting the first letter, happily used two letters for the drive
> (AA, AB, etc).

I wonder what DOS that was. I'd like to play with it.

MS-DOS 6.22 gets quite perturbed. It also prevents things like CD-ROMs
and network drive mappings from working because there are no more drive
letters.

> No, and yes. The MBR code searches for a /record/ (inside the MBR
> itself) that has that flag set. It than simply loads the pointed-to
> sector (normally a VMB) and jumps to the first byte of it.

VMB?

> It could not care less of if that sector is actually the start of
> a partition, much less if its a primary one. Its code is just
> that dumb.

Um ... I question that.

Nothing about installing the VBR (SYSing C: or LILO or GRUB) alters the
partition table. So I think that the VBR /must/ go in a specific
location inside the volume to align with where the MBR references.

I'd have to look up more details to be sure.

> I just checked where LILO could be installed. It looks like to be
> small enough to be placed in the VMB. One mistery down.

LILO installs in multiple places. There is the very small amount of
code that can go in the MBR or the VBR. LILO stores configuration data
somewhere outside of the MBR. I think it lands in the unused space in
the first track before the first partition starts. This configuration
data references the address that needed files are at. That's why you
have to re-run LILO when you modify the files in the file system, to
update these references.

> :-) That was what I ment with that the system probably would not have
> booted /before/ you installed LILO either. IOW, your mentioning of
> LILO was just a red herring.

No, LILO was not a red herring. LILO is a necessary part of the boot
chain. It's just not functional without the earlier necessary part.

> Yup, and exactly that which I had forgotten and the reason for me
> having started this thread. Though in my case the MBR contained the
> (remnants of) the GRUB boot manager (I used the DOS 5 FDISK to erase
> the old ones and create new DOS partitions).

And (re)partitioning alone does not alter the MBR's boot code.

> I didn't know that LILO could be put in the VBR (assumed it needed
> a number of sectors, limiting it to the MBR and perhaps PBR), hence
> my confusion.

That comes back to my long standing question of why wasn't the VBR / PBR
/alone/ sufficient to boot LILO (or GRUB).

> And to be pedantic about it : Not "/some/ boot code", but /working/
> boot code - mine did still contain (remnants of ?) the GRUB
> bootloader. :-p

Fair enough.

I'll counter with the computer thought it did launch an Operating
System. It was just a tiny little one that didn't do much at all.
Remember, as far as the computer, specifically the BIOS, is concerned,
LILO and GRUB /are/ operating system code. We humans just don't think
so because they are of such limited use.

> Another red herring : LILO was not called (the boot process broke
> down before it), so it /ofcourse/ didn't attempt to do any work.

Yep.

> My expectation was that the GRUB bootloader would keep working
> even after I deleted the old partitions and created a few new ones.
> It didn't. Looking back either GRUB didn't work anymore, or it was,
> for the new situation, misconfigured.

GRUB is even more complex than LILO. GRUB has multiple stages that need
to be loaded. (I'm assuming MBR like your configuration probably was.)
The first stage is the code that goes in the MBR boot sector. The
second stage stashes a file /somewhere/. This second stage can be in
the slack space between the MBR and the start of the first partition, if
that space is available. The second stage can also be in it's own tiny
(1-8 MB) partition (typically without a file system). The third stage
lives as files on a file system that GRUB knows how to work with.

The first stage only knows how to find and load the second stage. The
second stage knows how to find and load the third stage.

The first stage is minimal boot code. The second stage loads minimal
drivers (think soft-raid / file system). The third stage reads the
configuration to build and display the menu as well as ultimately the
kernel (et al.) that will be booted / chain loaded.

It is quite common for the first stage to be left intact. Obviously
this doesn't work without the other stages.

This makes sense seeing as how the MBR boot code is not altered when
altering partitions.

;-)

> :-) The very first thing I did in my first reply to you was to agree
> that I made a mistake in the latter. In other words, I rescinded
> my position in that and agreed to yours (and JJ's).

:-)

> Why not ? Its just a matter of (pretty-much) copying the MBR boot-code
> into the PBR and setting the "bootable" flag for the second record
> (pointing to the VBR of a logical volume).

I agree that it's hypothetically possible.

I don't know if it's technically possible or not. As in do the on disk
structures that make up an extended partition table provide room for
boot code?

At the very least, I think there are artificial limitations that various
utilities impose to prevent it.

> Says the man who just used LILO. :-)

Remember, that non-Microsoft tools do things that they want to be
compatible with Microsoft operating systems. Thus they are beholden to
Microsoft's rules for interoperability reasons.

You can slice and dice things the way that you want to. But at the end
of it, you need to look reasonable enough to Microsoft products so that
said Microsoft products don't stomp all over your hard work.

> No, you would not not need to touch the code in the MBR for that.
> Just moving the "bootable" flag to a record pointing to a PBR should
> be enough to load that PBR sector and (presuming it has the the AA
> 55 signature in its last two bytes) jump to its first byte (just as
> for a VBR).

I agree in the hypothetical.

See technical and procedural comments above.

> And I've come to learn that LILO can be installed in the VBR of a
> logical drive,

Um ... I'm fairly certain that LILO (and GRUB) /won't/ work as desired
in a logical partition. Where logical is the partition that goes inside
of an extended partition.

> whereas I presumed it could only be installed in/over the MBR (and
> following "filler" sectors).

You can install LILO (and GRUB) in a /primary/ partition in addition to
the MBR.

> Also that, when you repartition everything (especially to another OS),
> its a good idea to run an "fdisk /mbr" afterwards.

Presuming that you have access to boot media to be able to run fdisk
/mbr. Which could be a dangerous presumption.

Which brings us back to an earlier question I had. What is the Linux
equivalent of fdisk /mbr?

After much ado, I've come to the conclusion that there /isn't/ one for
when you are installing LILO (or GRUB) to the /VBR/. More specifically,
I've come to the conclusion that the ability to install LILO (or GRUB)
to the VBR is a /compatibility/ /feature/ meant to exclusively be used
when there is an existing boot loader in the MBR that you want to not
replace.

> .... which does make this a good thread.

Indeed!

[R.Wieser]

Grant,

> Please expand the "PBR" abbreviation that you were using. Because I get
> the impression that "P" wasn't "Partition".

Actually, it is. The extended partition to be precise about it, as the
starting sector of a primary partition is already a VBR. The name itself
(PBR) came from you, I just used it. :-)

> Oy vey. "logical volume" is overloaded there.

I kept using the name "logical volume" (to forgo a confusion alike the VBR /
PBR one), but I should maybe have clarified that I took it as a double to
"logical drive" (as used in FDISK).

> But it can also reference what Microsoft calls a "Logical Partition"
> inside of an Extended Partition.

:-) And which one of the two entries in an Extended Partition is referring
to the "logical partition" ? Assuming that it isn't the next Extended
Partition only one remains : the partition that is commonly referred to as a
"logical drive" - starting with a VBR. And the V in VBR made me refer to
partitions starting with it as Volumes. Either that, or I would have needed
to redefine it to something like DBR (D for Drive) - but that would be
ambigue, as it could also be referring to the first sector of the /physical/
drive (the MBR) :-(

>> It /should/ be possible to install a partition manager at the location of
>> a PBR just as with an MBR. It would have to be a bit different manager
>> though, as it would need to gather the logical volumes by following the
>> chain of PBRs.
>
> To me there is a difference in a partition table and a utility to manage
> the partition table (partition manager).

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

> Or are you making some sort of reference to a boot manager?

Huh ? Yes, I did. Twice. "install a partition manager" and "a bit
different manager".

> Now it sounds like you're talking about a boot manager.

:-) And at that point, not anymore. Remember how the MBR finds the active
partition, loads its first sector and than transfers control to it ? The
PBRs could have similar code, enabeling the boot-process to work its way
thru to a Logical Volume / Logical Drive deep in an Extended Partition(s
chain), load its VBR and transfer control to it.

> /If/ such were to work, I would expect there to be two bootable (active)
> flags.

Or (many) more. It depends on how deep the Logical Volume / Logical Drive
is down in the chain of Extended Partitions. 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.

>> The problem is that "secondary partition" is ambigue to me. I always
>> take it as referring to the second MBR entry

...

> So you're using "secondary" as a reference to the second partition in the
> main MBR partition table.

:-) If I would, why than would I say that its ambigue to me ?

But yes, in a *simple* conversation about prepping a drive *for usage under
DOS* I would do that. Why ? Because there the Extended Partition is
normally at the second position in the MBR. IOW, regardless of which of the
definitions is used, you would get the same partition.

The picture gets a bit different when talking about Linux, where the second
entry in the MBR normally points to the OS partition. Which is ofcourse a
Primary Partition. Have fun with referring to the secondary, primary
partition. :-)

Similary, under Windows the first MBR entry nowerdays often (but not always)
points to a recovery partition, with the second MBR entry pointing to the OS
partition.

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

As we are talking about both DOS as well as Linux as well as going deeper
into the Extended Partitions structure we now have multiple possibilities
for that "secondary partition" phrase, so it needs to be clearly defined (or
rather : not used anymore).

> Does that mean that "tertiary" is a reference to the third partition?

To be pedantic about it ? No. "tertiary" is just refering to "the third".
No indication what or where of. :-)

And as mentioned, it depends on the context if there is a *the*
(non-ambigue) third partition.

> Which is why I always disliked referencing the partition by count as they
> appear on the drive.

As long as there is nothing in those partitions that index number is all you
have to refer to them.

> I strongly prefer how under Linux, the primary / extended partitions show
> up as partitions 1-4, and logical partitions show up as 5+.

The only difference between that and what DOS FDISK offers is that you need
to select the Extended Partition to see the "logical partitions" (asuming to
be Logical Volumes / Logical Drives). Not much of a difference.

> What do you mean by "VMB"?

Apologies. I ment "VBR" there (no idea why I typed VMB instead).

> Nothing about installing the VBR (SYSing C: or LILO or GRUB) alters the
> partition table.

That was not at question.

> So I think that the VBR /must/ go in a specific location inside the volume
> to align with where the MBR references.

Nope. Regardles of using the track-head-sector or block notation, the MBR
references have a granularity of a single sector.

And its the other way around: The location for a new partition is determined
(by FDISK or similar), and than that location (and size) is written into the
MBR.

There is ofcourse the limitation that, for track-head-sector adressing, all
of the ?BRs /must/ start on the first sector of a track (I've forgotten if
that is still true for true block adressing though ...)

> LILO stores configuration data somewhere outside of the MBR. I think it
> lands in the unused space in the first track before the first partition
> starts.

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.

>> :-) That was what I ment with that the system probably would not have
>> booted /before/ you installed LILO either. IOW, your mentioning of LILO
>> was just a red herring.
>
> No, LILO was not a red herring.

...

>> Another red herring : LILO was not called (the boot process broke down
>> before it), so it /ofcourse/ didn't attempt to do any work.
>
> Yep.

You're contradicting yourself there.

> Remember, as far as the computer, specifically the BIOS, is concerned,
> LILO and GRUB /are/ operating system code.

The last time I spoke to the BIOS about this it refused to comment upon
that, other than with responding "its a human thing, no concern of mine".
:-)

The sting is in what you left out : If GRUB / LILO (installed in the MBR) is
OS code, than what kind/type was the boot code origionally there ? And if
not also OS code, for what reason ?

> GRUB is even more complex than LILO. GRUB has multiple stages that need
> to be loaded. (I'm assuming MBR like your configuration probably was.)
> The first stage is the code that goes in the MBR boot sector. The second
> stage stashes a file /somewhere/.

You got me there I'm afraid. I was still assuming that the boot manager
would fully reside in the "slack space" after the MBR.

> Um ... I'm fairly certain that LILO (and GRUB) /won't/ work as desired in
> a logical partition. Where logical is the partition that goes inside of
> an extended partition.

Currently ? Agreed. After updating the PBRs with bootcode and setting
"bootable" flags ? Well, that depends on those boot managers. It could
fail to work for a similar reason why running DOS from anywhere from the
first, primary partitions fails. Though as the bootable Linux partition
normally isn't the first one I don't think that that will be a problem.

>> Also that, when you repartition everything (especially to another OS),
>> its a good idea to run an "fdisk /mbr" afterwards.
>
> Presuming that you have access to boot media to be able to run fdisk /mbr.
> Which could be a dangerous presumption.

It would be a rather bad idea to go and repartition everything /without/
having bootable media at hand. I mean, how else are you going to put an OS
into the active partition ? :-)

> Which brings us back to an earlier question I had. What is the Linux
> equivalent of fdisk /mbr?

I have not got a clue, I would need to look it up on Google. And ass there
are quite a few versions of Linux I don't think there is a single answer
either.

> More specifically, I've come to the conclusion that the ability to install
> LILO (or GRUB) to the VBR is a /compatibility/ /feature/ meant to
> exclusively be used when there is an existing boot loader in the MBR that
> you want to not replace.

A rather logical conclusion, one I can agree with.

Regards,
Rudy Wieser

[Grant Taylor]

On 9/28/20 4:57 AM, R.Wieser wrote:
> Grant,

Hi,

> Actually, it is. The extended partition to be precise about it,
> as the starting sector of a primary partition is already a VBR.

Okay.

So you are using the following terms:

MBR - Drive's /Master/ Boot Record
VBR - /Primary/ Partition's Boot Record
PBR - /Logical/ Partition's Boot Record

> The name itself (PBR) came from you, I just used it. :-)

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

> I kept using the name "logical volume" (to forgo a confusion alike
> the VBR / PBR one), but I should maybe have clarified that I took it
> as a double to "logical drive" (as used in FDISK).

I've been using the following nomenclature.

/Primary/ Partition - any partition that can be normal PC-BIOS MBR
partition table.
/Extended/ Partition - a /special/ primary partition in that it can
contain one or more logical partitions.
/Logical/ Partition - a partition that lives inside the extended partition.

I just say "partition" if I don't want to specify / imply which type of
partition it is. "Partition" could be primary or extended or logical.
I usually only call out what type of partition if the context needs it.

> :-) And which one of the two entries in an Extended Partition is
> referring to the "logical partition" ?

I think (hope) I answered that above.

> Assuming that it isn't the next Extended Partition only one remains
> : the partition that is commonly referred to as a "logical drive" -
> starting with a VBR. And the V in VBR made me refer to partitions
> starting with it as Volumes. Either that, or I would have needed
> to redefine it to something like DBR (D for Drive) - but that would
> be ambigue, as it could also be referring to the first sector of the
> /physical/ drive (the MBR) :-(

I've not had enough caffeine to correctly unpack that.

> 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...".

> Huh ? Yes, I did. Twice. "install a partition manager" ...

"...partition /manager/..." hence my previous question.

> ... and "a bit different manager".

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.)

> :-) And at that point, not anymore.

Oy vey!

> Remember how the MBR finds the active partition, loads its first
> sector and than transfers control to it ?

Yes.

> The PBRs could have similar code, enabeling the boot-process to work
> its way thru to a Logical Volume / Logical Drive deep in an Extended
> Partition(s chain), load its VBR and transfer control to it.

I would use different terms to describe it, but, I largely agree with
what you have said here.

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.

EBR - Extended (Partition) Boot Record

The EBR is very similar to an MBR, but /inside/ the first sector of an
/extended/ partition. The EBR is structured identical to the MBR. The
first and second partition entry inside the EBR are used to specify the
logical partition's parameters and optionally the location of the next
EBR in the chain.

> Or (many) more. It depends on how deep the Logical Volume / Logical
> Drive is down in the chain of Extended Partitions. 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.

> :-) If I would, why than would I say that its ambigue to me ?
>
> But yes, in a *simple* conversation about prepping a drive *for usage
> under DOS* I would do that. Why ? Because there the Extended
> Partition is normally at the second position in the MBR. IOW,
> regardless of which of the definitions is used, you would get the
> same partition.

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.

I'm not certain how these partitions were created. This may be the
point where artificial and arbitrary limitations are imposed by tools,
like MS-DOS's fdisk.

> 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.

I remember MANY Linux installations that the first partition (hda1) was
boot & root on one partition and the second partition (hda2) was swap.

Contemporary Ubuntu (et al.) like to have the first partition (hda1) be
boot, followed by an extended partition (unnamed?) which contains two
logical partitions, root (hda5), and swap (hda6).

> Which is ofcourse a Primary Partition.

I disagree.

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

/dev/hda2

Assuming /dev/hda.

Primary partitions refer to the slot in the MBR's partition table.

Logical partitions refer to the slot in the EBR(s) in the extended
partition (chain).

There is no ambiguity as to which slot is which partition number. 1-4
are slots 1-4 in the MBR (respectively). 5+ are the is (are) the EBR(s)
(in chain order).

There is far more ambiguity of what drive will have what designation.

> Similary, under Windows the first MBR entry nowerdays often (but not
> always) points to a recovery partition, with the second MBR entry
> pointing to the OS partition.

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

> 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.

> As we are talking about both DOS as well as Linux as well as going
> deeper into the Extended Partitions structure we now have multiple
> possibilities for that "secondary partition" phrase, so it needs to
> be clearly defined (or rather : not used anymore).

I vote "not used anymore".

If you do want to use something like that, I'd prefer "second logical
partition".

> To be pedantic about it ? No. "tertiary" is just refering to
> "the third". No indication what or where of. :-)
>
> And as mentioned, it depends on the context if there is a *the*
> (non-ambigue) third partition.
>

> As long as there is nothing in those partitions that index number is
> all you have to refer to them.

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

> The only difference between that and what DOS FDISK offers is that you
> need to select the Extended Partition to see the "logical partitions"
> (asuming to be Logical Volumes / Logical Drives). Not much of
> a difference.

Ah, but there is. MS-DOS's drive letter C: could be assinged to
/dev/hda4 or even /dev/hda5, with zero other partitions on the drive.

Okay. You have to have an extended partition in slot #4 to be able to
have a logical partition in slot #5. But I suspect you understand why I
elided it in my previous statement.

> Apologies. I ment "VBR" there (no idea why I typed VMB instead).

ACK

Typos happen.

> That was not at question.

ACK

> Nope. Regardles of using the track-head-sector or block notation,
> the MBR references have a granularity of a single sector.
>
> And its the other way around: The location for a new partition is
> determined (by FDISK or similar), and than that location (and size)
> is written into the MBR.

Sorry. I meant to imply that the VBR must go in the first sector of the
partition. Where that sector / the partition starts on the drive is
extremely flexible. But the VBR has a fixed location inside of a partition.

> There is ofcourse the limitation that, for track-head-sector adressing,
> all of the ?BRs /must/ start on the first sector of a track (I've
> forgotten if that is still true for true block adressing though ...)

Agreed for CHS. LBA makes this more ... entertaining.

> 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.

> The last time I spoke to the BIOS about this it refused to comment
> upon that, other than with responding "its a human thing, no concern
> of mine". :-)

Yep.

> The sting is in what you left out : If GRUB / LILO (installed in the
> MBR) is OS code, than what kind/type was the boot code origionally
> there ? And if not also OS code, for what reason ?

The boot sector code in the MBR? That's OS code as far as the BIOS is
concerned.

> You got me there I'm afraid. I was still assuming that the boot
> manager would fully reside in the "slack space" after the MBR.

Ah.

Nope.

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

There's also the contention for said unused space.

> Currently ? Agreed. After updating the PBRs with bootcode
> and setting "bootable" flags ? Well, that depends on those boot
> managers. It could fail to work for a similar reason why running DOS
> from anywhere from the first, primary partitions fails. Though as
> the bootable Linux partition normally isn't the first one I don't
> think that that will be a problem.

I largely agree.

Conceptually, the BIOS can load the boot code from the MBR which can
load boot code from the EBR which loads code from the next EBR which
loads the VBR (if I can use that term) from inside the second logical
partition (/dev/hda6).

> It would be a rather bad idea to go and repartition everything
> /without/ having bootable media at hand. I mean, how else are you
> going to put an OS into the active partition ? :-)

Oh ... there are ways.

Rather there are utilities that will shuffle existing things around in
really surprising ways. Partition Magic being one of the earlier
quintessential examples. Acronis True Image being one of my more recent
preferences.

> I have not got a clue, I would need to look it up on Google. And ass
> there are quite a few versions of Linux I don't think there is a
> single answer either.

The answer that I keep running into is LILO or GRUB.

> A rather logical conclusion, one I can agree with.

:-)

[R.Wieser]

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

[Grant Taylor]

On 9/29/20 4:01 PM, R.Wieser wrote:
> Grant,

>
> 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. :-)

It's a Microsoft term. From fdisk (from MS-DOS 6.22)

"""
FDISK Options

Current fixed disk drive: 1

Choose one of the following:

1. Create DOS partition or Logical DOS Drive
2. Set active partition
3. Delete partition or Logical DOS Drive
4. Display partition information

Enter Choice: [1]
"""

Select #1.

"""
Create DOS Partition or Logical DOS Drive

Current fixed disk drive: 1

Choose one of the following:

1. Crate Primary DOS Partition
2. Create Extended DOS Partition
3. Create Logical DOS Drive(s) in the Extended DOS Partition

Enter Choice: [1]
"""

So ... I currently do, and always have, taken a /Logical/ Partition to
be the thing that gets created inside of an /Extended/ Partition.

> PBR -> an extended partition's boot record.

I think what you are calling an PBR is what I've seen documented as the EBR.

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

No, I meant what I said. It seems it was a schism. So I'll try saying
it another way.

A /Primary/ Partition is one of the four possible partitions in the
PC-BIOS / MBR partition table. Read: Something that is defined in one
of the four available slots.

Does that help?

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

What is the other type of partition that an extended partition can contain?

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

No, I don't think so.

It's completely possible to define an /extended/ partition and never use it.

To utilize an /extended/ partition, you must define a /logical/
partition inside of the /extended/ partition. Choice #3 of the Create
DOS Partition... menu.

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

I object to your use of the word "logical" there because it directly
conflicts with Microsoft's use thereof. -- No offense intended, but I
think they are more authoritative on the matter.

> Extended partition - a partition that can hold a logical volume /
> disk

I agree with this part.

> as well as another extended partition.

I don't agree with this part.

I think it's a nomenclature issue.

The /extended/ partition is one of the four possible primary partitions
that's meant to contain /logical/ partitions.

The /logical/ partitions are defined by the EBR. The EBR can point to
another EBR, thus forming a chain of /logical/ partitions.

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

;-)

It's okay.

I've found that a lot of learning, especially about minutia of things,
is also learning what terms other people are using, and why they are
using them, as part of the process of common understanding to enable the
conversation. Lest the parties be saying and thinking different things.

> Not quite.

I disagree.

A Volume Boot Record, which lives inside of a primary partition, does
contain code to boot the volume (partition). However I can't find
anything that indicates that a VBR also has a partition table in it.
(Why would it?)

Conversely, an Extended (Partition) Boot Record, which also lives inside
of a primary partition, does contain code to boot the volume
(partition). It also contains a partition table. The first slot of the
partition table defines the /logical/ partition that the EBR is
associated with. The second slot optionally contains information
pointing to the next EBR in the chain. The third and fourth slots are
unused.

I think it's self evident that the VBR and EBR are different from each
other.

Aside: I suppose you could re-use the same structure / template inside
of a VBR as is used for the MBR and EBR. Though I've not seen any
evidence to this effect. Also, Parsimony & Occam's Razor would
discourage this.

I've not (yet) looked at a an erased disk that has been partitioned and
SYSed to see what the on disk bytes of the VBR are.

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

Also, what comes after the /first/ EBR will of course vary depending if
there are additional EBRs before getting to the OS in a chain.

> Than again, not all VBRs are followed by an OS ...

Why would you go through the BIOS boot straping the MBR to boot strap
the VBR and not boot strap an OS?

Not booting an OS would mean that the computer is an unusable state.

Note: I was referring to the boot sequence, not the location of things.

I see no need for a VBR on a volume (partition) that is not used to boot
the system.

> Currently only a primary partition can contain a bootable OS.

I agree in that matches my experience.

However, after reading more about MBR / VBR / EBR pursuant to this
thread, I believe that it is (more than) theoretically possible to boot
from an /extended/ and /logical/ partition. It's just that such is not
done.

> And not even all of those need to contain an OS. Just take the
> Linux swap partition. :-)

I agree that partitions (volumes) aren't required to contain a VBR, much
less an OS. But I don't think that they are in scope of a discussion
about how a system boots.

> Yep, exactly that.

This is why I think it's theoretically possible to /boot/ an OS from a
logical partition.

It just seems to be that some artificial limitations are imposed on us
by Microsoft and those that followed suit. Probably out of lack of
perceived need than malicious intent.

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

> Why do you think I said "normally" ?

I think we have different ideas of what "simple" and "normally" are.
Probably based on our different experiences.

> Really ? Than imagine that the first partition being either empty
> or an extended partition.

The first partition slot, used or not, will always be referred /dev/xxx1.

The second partition slot, used or not, will always be referred to as
/dev/xxx2.

The third partition slot, used or not, will always be referred to as
/dev/xxx3.

The fourth partition slot, used or not, will always be referred to as
/dev/xxx4.

All four of these partitions are a /primary/ (as in lives in the MBR
partition table) partition. One (and only one) of them can be an
/extended/ partition. The /extended/ partition can contain zero or more
/logical/ partitions.

The first /logical/ partition (in the first partition slot of the first
EBR), will always be referred to as /dev/xxx5.

The second /logical/ partition (in the first partition slot of the
second EBR), will always be referred to as /dev/xxx6.

The third /logical/ partition (in the first partition slot of the third
EBR), will always be referred to as /dev/xxx7.

...

> 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.

That is a very good example of why referring to partitions in the order
you come to them is such a problem and prone to error.

How would you describe the following partitions?

Slot Start End
1 30 39
2 20 29
3 10 19
4 00 09

The fact that they are slots in the MBR's partition table means that
they are primary partitions.

Aside: My personal opinion is that an /extended/ partition /is/ a
/primary/ partition, just meant for special use via subsequent EBR(s).

Which partition is first? The one in slot 1 at address ranges 30-39?
Or the one at address ranges 00-09 in slot 4?

Yet again, saying the /numeric/ /sequence/ is ambiguous.

Despite the numerical sequence ambiguity, it's extremely easy to
predictably and consistently say what each slot will be called;
/dev/xxx<slot #>. It does not matter where the partition is on the
disk. It matters what slot it's in.

Or for logical partitions, it matters which link in the chain they are;
/dev/xxx<4+EBR link #>. It doesn't matter which of the four primary
slots is the extended partition.

> Who just said that making assumptions is dangerous ?

I did.

That's why I called out the assumption that I made so that you would
have an opportunity to object to it.

> Just imagine that the first physical drive has only a single primary
> partition. Where could the secondary, primary partition than be ?

In Linux, partition numbers are scoped /within/ a drive. IDE drives
have a specific device assigned to them based on their I/O interface.

Primary Master = /dev/hda
Primary Slave = /dev/hdb
Secondary Master = /dev/hdc
Secondary Slave = /dev/hdd

I've not seen what happens in systems with more than two IDE
controllers. I assume the pattern continues.

SCSI on the other hand is less predictable. The SCSI device names are
dependent on the order that the drives are detected.

First drive found is /dev/sda
Second drive found is /dev/sdb

These drives could be on the same SCSI bus, on different SCSI buses on
the same SCSI controller, or on different SCSI busses on different SCSI
controllers.

Usually, drives are identified in SCSI ID order. But not always. SCSI
drivers normally enumerate the SCSI bus(es) as part of loading. But not
always. Maybe you forgot to power on an external drive or had it
disconnected and need to rescan the first SCSI bus after all the drives
were found on the first and second SCSI bus. Things can get messy with
SCSI in Linux.

Fibre Channel ... oy vey!

Contemporary Linux does have some /dev/by-... options that make things
MUCH more predictable.

However, all of that aside, the partitions on each disk are easily
identified via their partition number.

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

Yep.

That's why I always prefer to use, or make reference to,
/dev/hd<bla><partition bla> whenever possible.

I like to use /dev/sd<bla><partition bla> whenever possible too. SCSI
just makes it less predictable than IDE.

Aside: SATA shows up as SCSI under contemporary Linux.

> And so do I. But ofcourse that example was a bit contrivedl.

As is my example of partitions being in the opposite order on the disk.

> 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.

It's chosen to point out the limitations of identifying order of partitions.

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

It's okay. I don't have much. Mostly because MBR can't deal with
drives > 2 TB.

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

Identifying the /slot/ (within the drive) is trivial. ;-)

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

LILO can be installed /inside/ the partition as the (Partition's) Volume
Boot Record.

I believe that we've already established that each partition (volume)
can have it's own VBR.

The MBR boot code identifies and chain loads the VBR from the /active/
partition.

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

> 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.

No, it does not.

It's /extremely/ /dependent/ on /where/ LILO gets installed.

LILO can be installed in the MBR and / or the VBR.

I don't know about an EBR. I might have to try that some other time.

But seeing as how there are four VBRs, and one MBR, I can technically
install LILO into five independent and non-conflicting locations.

Remember, the start of my not-so-small /sub/ thread was about installing
LILO in the partition -> VBR and needing something else in the MBR.

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

I completely agree with that. Some programs just take a LOT longer to
do it than others.

[Grant Taylor]

On 9/29/20 8:33 PM, Grant Taylor wrote:
> I'm doing another test that's going to take a while.  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 Taylor]

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.  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 Taylor]

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.

[R.Wieser]

Grant,

> It's a Microsoft term. From fdisk (from MS-DOS 6.22)

I'm not sure if you're noticed, but the term "logical partition" doesn't
appear in the results taken from it ...

The closest thing is "logical DOS drive", which I've been referring to as
"logical volume / disk".

> So ... I currently do, and always have, taken a /Logical/ Partition to be
> the thing that gets created inside of an /Extended/ Partition.

*both* of them ? :-)

>> PBR -> an extended partition's boot record.
>
> I think what you are calling an PBR is what I've seen documented as the
> EBR.

I didn't want to use /Extended/ Boot Partition, as currently the MBR might
consist outof more than a single sector (UEFI related IIRC). Which causes
that name to be(come) ambigue. :-\

> A /Primary/ Partition is one of the four possible partitions in the
> PC-BIOS / MBR partition table. Read: Something that is defined in one of
> the four available slots.
>
> Does that help?

The keyword there is *defined*. The record defining the partition isn't
the same as the partition itself. For starters, you do not try to put a VBR
into that record ...

> What is the other type of partition that an extended partition can
> contain?

:-( I've already mentioned that a few times now. One that is normaly
always there is a logical volume /drive, the other is a possible (if there
is space left after creating the logical volume /drive) next-deeper extended
partition.

> I object to your use of the word "logical" there because it directly
> conflicts with Microsoft's use thereof.

Pardon me, but I think that my usage of "logical volume / drive" is much
closer to what you've found in DOS 6.22 FDISK than your "logical partition".

> No offense intended, but I think they are more authoritative on the
> matter.

I have not taken any (offense). If you can support your stance than I'm no
stranger to go with it. But as I've just pointed out that you do not seem
to do that (support it) ...

But, as we disagree I resorted to the most hineous of methods to tackle that
: I googled to see what others would be saying about it. :-)

To support my position :
https://docs.microsoft.com/en-us/windows/win32/fileio/basic-and-dynamic-disks

The phrase "logical partition" doesn't appear in there, while "logical
drive" does (no "logical volume" though).
Also notice it says "Create and delete logical drives within an extended
partition".

I also found a result equating "logical partition" to "logical drive", and
another using the phrase "logical partitions" to refer to anything that
isn't a primary one. Which could stand to reason, as a Linux swap
partition is neither a primary (as in: a logical drive) nor an extended
partition.

>> Extended partition - a partition that can hold a logical volume / disk

>> ... as well as another extended partition.

>
> I don't agree with this part.

Thats too bad, as that is simply the way it is. Sorry.

> I think it's a nomenclature issue.

Call a rose something else, and it will still be a rose, regardless of its
name.

But OK, you disagree. So, what would you call what I refer to as an
extended partition inside another extended partition ? And, what hould you
call their first PBR / EBR sectors (and why, as they are exactly the same as
the one of a "real" extended partition) ?

> The /logical/ partitions are defined by the EBR. The EBR can point to
> another EBR, thus forming a chain of /logical/ partitions.

I'm sorry, but as long as you can't decide what to call the two (possible)
different(!) partitions in an extended partition I'm going to stop
discussing extended partitions here. I have no wish to play a guessing
game. :-(

>> Than again, not all VBRs are followed by an OS ...
>
> Why would you go through the BIOS boot straping the MBR to boot strap the
> VBR and not boot strap an OS?

Who said anything about bootstrapping that VBR ? I sure didn't.

Lets keep it simple and think of a DOS environment. Imagine four primary
partitions, with (ofcourse) only one being set as "bootable". Lets refer to
it as the C: drive. Would you be able to create D: , E: and F: drives
/without/ putting a VBR into the other three primary partitions ?

>> Not quite.
>
> I disagree.

You snipped to much / quoted to little. No idea what this is about.

> A Volume Boot Record, which lives inside of a primary partition, does
> contain code to boot the volume (partition).

Disagree.

The VBR has got /nothing/ to do with a partition. A floppy also has a VBR
but has no partitions. Besides that, a VBR can indicate a logical disk that
is /smaller/ than the partition its placed in.

> anything that indicates that a VBR also has a partition table in it. (Why
> would it?)

I can't remember ever having claimed that. Quote please.

> Conversely, an Extended (Partition) Boot Record, which also lives inside
> of a primary partition,

So, /all/ partitions referred to by the partition table inside an MBR are
now "primary partitions" ? If that is so, what are you now going to call a
primary partition which holds a logical drive - you know, the "primary
partition" as refered to by FDISK ?

> does contain code to boot the volume (partition).

At this moment ? Nope. Why would it ?

> I think it's self evident that the VBR and EBR are different from each
> other.

Again, who claimed that they wheren't ?

> Aside: I suppose you could re-use the same structure / template inside of
> a VBR as is used for the MBR and EBR.

No, you can't. While the MBR and PBR / EBR are the same in structure, a
VBR is a fully different beast.

> I've not (yet) looked at a an erased disk that has been partitioned and
> SYSed to see what the on disk bytes of the VBR are.

https://thestarman.pcministry.com/asm/mbr/DOS50FDB.htm

> Also, what comes after the /first/ EBR will of course vary depending if
> there are additional EBRs before getting to the OS in a chain.

Yeah, I thought that that would be obvious (you already indicated you knew
that), so I snipped that part of your list off.

> However, after reading more about MBR / VBR / EBR pursuant to this thread,
> I believe that it is (more than) theoretically possible to boot from an
> /extended/ and /logical/ partition.

As I mentioned way back, I thought the same & tried to make it work for a
few versions of DOS. Only to discover that DOS doesn't like not being run
from anything but a (first-on-disk) primary partition.

> > Really ? Than imagine that the first partition being either empty or an
> > extended partition.
>
> The first partition slot, used or not, will always be referred /dev/xxx1.

Odd, that DOS 6.22 FDISK example you started with doesn't do that at all ...

How would you describe the following partitions?

> Slot Start End
> 1 30 39
> 2 20 29
> 3 10 19
> 4 00 09

Probably just as "partitions".

But in the context of a computer I wouldn't, as there is information
missing. Like the /kind/ of partition - enableing me to refer to it as a
"primary", "extended" or "other" partition.

> The fact that they are slots in the MBR's partition table means that they
> are primary partitions.

Disagree. I denounce you redefinition of "primary partition" to mean
/any/ partition that is referred to by the MBRs partition table. As
already mentioned, your redefinition clashes with an earlier usage of the
same phrase, causing it to become ambigue. :-(

> Aside: My personal opinion is that an /extended/ partition /is/ a
> /primary/ partition, just meant for special use via subsequent EBR(s).

I agree with that stance. Just not with your hijacking of the phrase
"primary partition".

> In Linux, partition numbers are scoped /within/ a drive.

Good for you. Now, how does that work under DOS, Window and possible other
OSes ?

>> True. But so are primary partitions, and we just figured out that its
>> not /that/ easy.
>
> Identifying the /slot/ (within the drive) is trivial. ;-)

Nope. Which I already tried to make clear to you. The word "secondary"
doesn't necessarily refer to a "slot". And doesn't even need to refer to a
partition on the current drive.

> LILO can be installed /inside/ the partition as the (Partition's) Volume
> Boot Record.

It certainly would be a nice trick to have LILO just in the VBR, as the
amount of bytes for available the DOS bootcode and strings is rather minimal
(about 450 bytes). And thats for both the boot managing as well as booting
the OS itself ofcourse.

> But seeing as how there are four VBRs, and one MBR, I can technically
> install LILO into five independent and non-conflicting locations.

I wasn't talking about where its installed, but where it *saves its
configuration data*. Five LILOs installed means five blobs of configuration
data (possibly four, as the MBR has everything available). You mentioned
that that configuration data could possibly be stored on the MBR track. The
question was/is : don't those configurations stored there not overwrite each
other ?

= = = = = = Next message

> I installed four copies of Linux, each into it's own /primary/ partition.

...

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

You've proven that it works for Linux. Do you think it would work for DOS
too ?

Suggestion: Make a snapshot of the first few sectors of such a Linux OS
partition just before and after installing LILO. Chances are that LILO uses
a bit more than just a single sector (and pushes the OS itself down a bit)
...

> Aside: MS-DOS's boot code doesn't like multiple partitions being marked
> active.

Read: the DOS MBR code specifically checks for multiple partitions being
marked "active" and errors-out if found. :-)

Regards,
Rudy Wieser

[Grant Taylor]

On 9/30/20 5:34 AM, R.Wieser wrote:
> Grant,

Hi Rudy,

> I'm not sure if you're noticed, but the term "logical partition"
> doesn't appear in the results taken from it ...
>
> The closest thing is "logical DOS drive", which I've been referring
> to as "logical volume / disk".

Son of a ....

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.

> *both* of them ? :-)

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

EBR's go inside the /extended/ /partition/. The first partition slot in
the EBR defines a /logical/ DOS drive.

As previously established, the EBR only defines one logical DOS drive.
How it does that is immaterial to what it does.

The EBR uses the first partition slot to define the actual logical DOS
drive and the second partition slot to point the next EBR if there is one.

> I didn't want to use /Extended/ Boot Partition, as currently the MBR
> might consist outof more than a single sector (UEFI related IIRC).
> Which causes that name to be(come) ambigue. :-\

I want to not do anything more with UEFI / GPT than I need to other than
acknowledge it and set it aside. Particularly for this conversation.
My brain is growing it's working understanding as this thread evolves.

> The keyword there is *defined*. The record defining the partition
> isn't the same as the partition itself. For starters, you do not
> try to put a VBR into that record ...

Okay.

> :-( I've already mentioned that a few times now. One that is normaly
> always there is a logical volume /drive, the other is a possible
> (if there is space left after creating the logical volume /drive)
> next-deeper extended partition.

See above.

I don't consider the information in the second partition slot of an EBR
to actually be a partition definition.

Just because the same data structure was used in the EBR as the MBR does
not mean that the EBR does the same thing as the MBR. Defining multiple
partitions in this case.

> Pardon me, but I think that my usage of "logical volume / drive"
> is much closer to what you've found in DOS 6.22 FDISK than your
> "logical partition".

Pursuant to above, I stand down.

> I have not taken any (offense). If you can support your stance than
> I'm no stranger to go with it. But as I've just pointed out that
> you do not seem to do that (support it) ...
>
> But, as we disagree I resorted to the most hineous of methods to tackle
> that : I googled to see what others would be saying about it. :-)

How is that heinous? ;-)

> To support my position :
> https://docs.microsoft.com/en-us/windows/win32/fileio/basic-and-dynamic-disks
>
> The phrase "logical partition" doesn't appear in there, while "logical
> drive" does (no "logical volume" though). Also notice it says
> "Create and delete logical drives within an extended partition".
>
> I also found a result equating "logical partition" to "logical drive",
> and another using the phrase "logical partitions" to refer to anything
> that isn't a primary one.

That's what I /was/ guilty of. I'm /trying/ to retrain my brain.

> Which could stand to reason, as a Linux swap partition is neither a
> primary (as in: a logical drive) nor an extended partition.

Why do you say that?

Remember, the partition is the container, and not dependent on said
container's contents.

Linux's swap can easily go inside a primary partition (container) or a
logical DOS drive (container).

> Thats too bad, as that is simply the way it is. Sorry.

I still maintain that an extended partition can't hold another extended
partition.

An extended partition can hold one or more EBRs, which define a logical
DOS drive.

> Call a rose something else, and it will still be a rose, regardless
> of its name.

Extended partition ≠ EBR

I don't care which one is the rose. The other is not a rose.

Perhaps the extended partition is the rose and the logical DOS drives
definition(s) (EBR(s)) and defined storage area(s) are the petal(s).

> But OK, you disagree. So, what would you call what I refer to as
> an extended partition inside another extended partition ?

I don't believe there is such a thing. Not from Microsoft utilities anyway.

Please re-ask your question in light of the extended partition
containing one or more EBRs defining a logical DOS drive and it's
associated storage area.

> And, what hould you call their first PBR / EBR sectors (and why, as
> they are exactly the same as the one of a "real" extended partition) ?

I'm having trouble unpacking that question.

> I'm sorry, but as long as you can't decide what to call the two
> (possible) different(!) partitions in an extended partition I'm
> going to stop discussing extended partitions here. I have no wish
> to play a guessing game. :-(

As stated above, the EBR only defines a logical DOS drive in the first
EBR partition slot. The second EBR partition slot is not actually a
partition, it's a storage location abused to point to the next EBR if
there is one).

> Who said anything about bootstrapping that VBR ? I sure didn't.
>
> Lets keep it simple and think of a DOS environment. Imagine four
> primary partitions, with (ofcourse) only one being set as "bootable".
> Lets refer to it as the C: drive. Would you be able to create D: ,
> E: and F: drives /without/ putting a VBR into the other three primary
> partitions ?

Aside: I feel like we're going over the slippery slope of is the VBR
structure the same thing as a VBR with or without boot code.

I think it's definitely possible to populate the other three primary
partitions without bootable code in the VBR location. But I don't know
if the VBR is there or not.

I think it's going to depend if formatting a file system arbitrarily
skips the area that the VBR would use and leaves it blank or actually
writes out some VBR structure.

There is also the fact that the bytes that the VBR would use is there.
But does that constitute being a VBR?

> Disagree.
>
> The VBR has got /nothing/ to do with a partition. A floppy also
> has a VBR but has no partitions.

How about a VBR goes into a a contiguous block of storage, at the
beginning. Independent of if that storage is a floppy disk (w/o
partitions) or a partition.

Much like carpet goes inside walls. It doesn't matter if it's the
outside walls of the house (~floppy disk) or a smaller room therein
(partition).

> Besides that, a VBR can indicate a logical disk that is /smaller/
> than the partition its placed in.

I would need to go back and read things again.

I agree that the VBR can / often does have information about the the
size of the volume / file system that it's describing.

But I don't agree that a VBR would nominally define a file system that
is significantly smaller than the container it is in.

Sure, there may be some fixed amount of overhead related to where the
counters in the VBR reference. But I think they would be relatively
small and very likely fixed. E.g. take X bytes off of the actual
storage boundary, wherever it is.

The only exception that comes to mind is when someone does something
dastardly like doing a byte for byte copy of a disk and writing it to a
larger disk. But this is definitely an atypical action.

> I can't remember ever having claimed that. Quote please.

I didn't mean to imply that you did.

I was wondering if it did or not. I was sharing that I didn't find
anything that indicated that it did.

> So, /all/ partitions referred to by the partition table inside an
> MBR are now "primary partitions" ?

In my personal opinion, yes.

Specifically an /extended/ partition /is/ a /type/ /of/ primary
partition. The /type/ of partition indicates that there are logical DOS
drives inside of that particular primary partition.

I agree that I'm likely atypical in this stance.

Most people will say that a primary partition is different from an
extended partition.

> If that is so, what are you now going to call a primary partition
> which holds a logical drive - you know, the "primary partition"
> as refered to by FDISK ?

I still use "extended" because it implies that there is a possibility of
logical DOS drives being in it.

> At this moment ? Nope. Why would it ?

Sorry, word smithing.

A Volume Boot Record, which lives inside of a primary partition, /could/

contain code to boot the volume (partition).

> Again, who claimed that they wheren't ?

See above.

> No, you can't. While the MBR and PBR / EBR are the same in structure,
> a VBR is a fully different beast.

Okay.

> https://thestarman.pcministry.com/asm/mbr/DOS50FDB.htm

Thank you for the link.

I'll take a look when time permits.

> Yeah, I thought that that would be obvious (you already indicated
> you knew that), so I snipped that part of your list off.

ACK

> As I mentioned way back, I thought the same & tried to make it work
> for a few versions of DOS. Only to discover that DOS doesn't like
> not being run from anything but a (first-on-disk) primary partition.

Agreed.

But I believe that's an artificial limitation of the boot code that
MS-DOS puts in the MBR and /not/ an actual limitation of the MBR / VBR /
EBR on disk data structures.

> Odd, that DOS 6.22 FDISK example you started with doesn't do that at
> all ...

Linux and MS-DOS refer to partitions differently.

> How would you describe the following partitions?
>

> Probably just as "partitions".

Yes. They are /primary/ partitions. There is no indication if one of
the primaries is an extended partition or not, much less if there are
logical DOS drives therein.

Aside: I guess one of the reasons that I've long said logical
/partitions/ instead of logical /DOS/ /Drive/ is because the same
concept applies to other OSs beyond DOS.

> But in the context of a computer I wouldn't, as there is information
> missing. Like the /kind/ of partition - enableing me to refer to it
> as a "primary", "extended" or "other" partition.

What is an "other" partition? Is it a reference to what FDISK calls
NON-DOS?

As previously stated, I believe an /extended/ partition /is/ a /type/
/of/ a /primary/ partition.

Where as in /primary/ vs non-primary is differentiated by if the
""partition (to use the term loosely for a moment) is defined in the MBR
partition table or not. With the four partition slots in the MBR
partition table being /primary/.

Things can get really weird and potentially confusing when you look at
things based on the data structures verses what is in what's defined by
said data structures.

> Disagree. I denounce you redefinition of "primary partition" to
> mean /any/ partition that is referred to by the MBRs partition table.
> As already mentioned, your redefinition clashes with an earlier usage
> of the same phrase, causing it to become ambigue. :-(

You are free to denounce my definition and use.

> I agree with that stance. Just not with your hijacking of the phrase
> "primary partition".

In some ways I think that "primary" and "extended" are -- I don't know
what term to use, backroynim isn't correct -- terms that were defined
after the fact to differentiate the contents of the slots. Much like
PATA as a term didn't exist until after SATA came out.

> Good for you. Now, how does that work under DOS, Window and possible
> other OSes ?

MS-DOS does some thing that I think is strange. I think it enumerates
the first primary partition it sees (almost always in the first slot) on
each drive and then -- I think but am not sure -- it enumerates
remaining primary partitions / logical DOS drives on each drive before
going to the next drive.

I believe Windows follows suit. I don't know off hand about OS/2. Most
Unix / Linux OSs do something device based like Linux does.

> Nope. Which I already tried to make clear to you.

What is difficult about identifying the second slot, be it used or unused?

> The word "secondary" doesn't necessarily refer to a "slot".
> And doesn't even need to refer to a partition on the current drive.
>

> It certainly would be a nice trick to have LILO just in the VBR,

That is definitely possible to do. That's the exact thing that I was
originally questioning and started this entire sub-thread.

> as the amount of bytes for available the DOS bootcode and strings
> is rather minimal (about 450 bytes).

Yep, 446 bytes is what I'm seeing.

> And thats for both the boot managing as well as booting the OS itself
> ofcourse.

I believe you might be conflating a couple of things.

There is boot code to locate and chain load the active partition in the
446 bytes in the MBR.

And there is boot code to load the OS in the 446 bytes in the VBR.

I am quite certain that MS-DOS uses the MBR and VBR.

> I wasn't talking about where its installed, but where it *saves
> its configuration data*.

Ah. That's just a file. Nothing more than convention states the name
of the file.

> Five LILOs installed means five blobs of configuration data (possibly
> four, as the MBR has everything available).

Each LILO instance has it's own set of configuration data (file(s)).

> You mentioned that that configuration data could possibly be stored
> on the MBR track.

I did. I think that LILO may store something in the MBR. But after my
further expirimentation last night, I don't know how much, is stored in
the slack space after the MBR. I'm no longer certain that LILO stores
anything in the slack space after the MBR.

> The question was/is : don't those configurations stored there not
> overwrite each other ?

No.

In my testing last night I learned that the configuration data is not
stored in conflicting locations. There may be something akin to a
history of what was most recently chosen. But I don't even know if
that's a thing for LILO or if I'm conflating GRUB in that functionality.
Hence why I'm no longer certain that LILO stores anything in the slack
space after the MBR.

Point of order. There are two types of configuration data for LILO.
There is the file that contains the ASCII text representing the desired
configuration. And there is the [unknown type] representing the
compiled configuration that LILO uses when it actually runs. (Remember
that LILO does not read it's configuration file when it runs. Hence why
you have to re-run LILO to update it's ""compiled configuration.)

You are correct that keeping the configuration for the five different
locations is non-trivial.

It is quite possible to keep configuration details in the following
files like I did:

/etc/lilo.conf (default, I didn't use it beyond the base install)
/etc/lilo.mbr.conf
/etc/lilo.vbr1.conf
/etc/lilo.vbr2.conf
/etc/lilo.vbr3.conf
/etc/lilo.vbr4.conf

Then I would ""install (re-write) LILO to the various locations using
the following command:

lilo -v -C /etc/lilo...conf

> You've proven that it works for Linux. Do you think it would work
> for DOS too ?

No. Because, as you've stated before, MS-DOS has it's own artificial
limitations and refuses to do things like boot from the primary
partition in slot #2.

I view these as artificial limitations that Microsoft created and /not/
a limitation of the MBR / VBR / EBR.

> Suggestion: Make a snapshot of the first few sectors of such a Linux
> OS partition just before and after installing LILO. Chances are
> that LILO uses a bit more than just a single sector (and pushes the

> OS itself down a bit) ....

I don't know if LILO needs more than the 446 bytes in the MBR / VBR /
EBR. I know that GRUB does.

I don't believe that LILO will push the OS itself down a bit. As doing
that would involve shifting contents of the entire drive and likely
shrinking the file system. That's WAY too complicated for LILO or any
boot loader.

I think that LILO makes note of where the files live in the file system
by byte offset and loads them that way. 446 bytes in the MBR / VBR /
EBR which includes addresses to where other necessary file(s) are at in
the sea of bytes that are the storage container.

> Read: the DOS MBR code specifically checks for multiple partitions
> being marked "active" and errors-out if found. :-)

Yep. I found that out.

Though I think that it only look at the four primary partitions in the
MBR partition table. -- I believe that I had one of the logical DOS
drives (logical partitions? in non-DOS parlance?) marked as active in an
EBR and the Microsoft code booted just fine.

I also learned that LILO doesn't use the active flag at all.

[R.Wieser]

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