On 9/30/20 5:34 AM, R.Wieser wrote:
> 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 ...
> :-( 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 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 :
> 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
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
An extended partition can hold one or more EBRs, which define a logical
> 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?
> 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
> 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
> 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 ?
> No, you can't. While the MBR and PBR / EBR are the same in structure,
> a VBR is a fully different beast.
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.
> 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.
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
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
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 ?
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)
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
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.