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.
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.
Actually, it's the partition boot sector (PBR) that finds and loads
OS specific boot file. i.e.
As long as boot manager isn't involved, that is.
Eh ... I don't quite agree with that. (More below.)
Why do I have to install the Linux boot loader in the MBR?
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.
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.
Also, thank you for prompting me to finally spend some time answering the mildly nagging question that I've been ignoring for decades.
I guess that it didn't want to play nice with something as old as DOS.
Grant,
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.
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.
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.
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 does when everything works and is configured correctly / as
expected.
But again, moving that "active" flag to another record ...
isn't difficult - especially not under DOS.
... (even if it /doesn't/ point to a primary partitions VBR) ...
I'm not at all sure which question that was, but you're welcome. :-)
No, I was asking why I have to install the Linux boot loader into the MBR
vs the PBR (a.k.a. VBR)
What do y ou mean by "/secondary/ partition"?
I'm used to "primary" / "extended" / "logical" partitions in the MS-DOS PC-BIOS nomenclature.
I think it only mattered that it was a /primary/ partition, not a logical partition.
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.
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
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.
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:.
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.
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."
I don't think it's possible to boot (as in load a PBR (VBR)) from an /extended/ partition.
At least it's not possible with the tools that Microsoft has provided,
Perhaps other non-Microsoft boot code -- which can be installed in the
MBR -- does support this.
I'm not at all sure which question that was, but you're welcome. :-)
I think the question was "Why doesn't LILO (or GRUB) boot a system when
it's installed to a partition (PBR / VBR) and the partition is marked active?".
I've come to learn that the answer is that neither LILO nor GRUB install anything into the MBR when they are installed into the PBR (VBR), and that the system requires boot code in the MBR to be able to boot.
Grant,
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 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).
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 ...
AFAICR it was even worse : DOS only wanted to boot from the first
partition (which of course 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.
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).
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.
I just checked where LILO could be installed. It looks like to be
small enough to be placed in the VMB. One mistery down.
:-) 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.
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 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
Another red herring : LILO was not called (the boot process broke
down before it), so it /ofcourse/ didn't attempt to do any work.
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.
:-) 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).
Says the man who just used LILO. :-)
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).
And I've come to learn that LILO can be installed in the VBR of aUm ... I'm fairly certain that LILO (and GRUB) /won't/ work as desired
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.
Please expand the "PBR" abbreviation that you were using. Because I get
the impression that "P" wasn't "Partition".
Oy vey. "logical volume" is overloaded there.
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?
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 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.
Does that mean that "tertiary" is a reference to the third partition?
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+.
What do you mean by "VMB"?
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.
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.
...:-) 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.
Remember, as far as the computer, specifically the BIOS, is concerned,
LILO and GRUB /are/ operating system code.
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/.
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.
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?
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.
Grant,
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. :-)
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).
:-) 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) :-(
Huh? /Ofcourse/ there is. And I have no idea how you, in regard
to the above quote, came up with that.
Huh ? Yes, I did. Twice. "install a partition manager" ...
... and "a bit different 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.
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.
:-) 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).
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 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.
Apologies. I ment "VBR" there (no idea why I typed VMB instead).
That was not at question.
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 ...)
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.
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 ?
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.
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.
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 ? :-)
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.
A rather logical conclusion, one I can agree with.
PBR - /Logical/ Partition's Boot Record
I believe I saw Partition Boot Record (PBR) used elsewhere in the thread
and simply followed suit.
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.
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...".
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.)
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.
BIOS -> MBR -> VBR -> OS
-or-
BIOS -> MBR -> EBR -> VBR -> OS
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.
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.
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.
Have fun with referring to the secondary, primary partition. :-)
/dev/hda2
Assuming /dev/hda.
The first partition on the drive could be the 4th primary partition.
I vote "not used anymore".
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.
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.
Grub wants / needs more space than is unused in the first track.
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. :-)
PBR -> an extended partition's boot record.
That does not compute : A partition cannot also be a partition table
(you probably ment something different there).
An extended partition can contain two types of partitions, you just
named one ...
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.
Bingo !
But, you're right. It would be better if I would have used the
description "boot manager"instead of "partition manager". Sorry.
Not quite.
The squence after the MBR and EBR should (ofcourse) be the same.
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. :-)
Yep, exactly that.
Why do you think I specifically mentioned "a *simple* conversation"
? :-p
Why do you think I said "normally" ?
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.
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 ?
And thats yet another way to make that "secondary, primary partition" reference problematic.
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.
I have /very/ little experience with GPT drives I'm afraid
True. But so are primary partitions, and we just figured out that
its not /that/ easy.
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.
Sigh. Every programs gets "features" added until it grows outof
proportions. Even under Linux ...
I'm doing another test that's going to take a while. I'll reply with
the results later.
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.
Because of who I am and the type of person that I am, I kept ... messing.
It's a Microsoft term. From fdisk (from MS-DOS 6.22)
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.
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?
What is the other type of partition that an extended partition can
contain?
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
... as well as another extended partition.
I don't agree with this part.
I think it's a nomenclature issue.
The /logical/ partitions are defined by the EBR. The EBR can point to another EBR, thus forming a chain of /logical/ partitions.
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 quite.
I disagree.
A Volume Boot Record, which lives inside of a primary partition, does contain code to boot the volume (partition).
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).
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.
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.
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.
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.
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.
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).
In Linux, partition numbers are scoped /within/ a drive.
True. But so are primary partitions, and we just figured out that its
not /that/ easy.
Identifying the /slot/ (within the drive) is trivial. ;-)
LILO can be installed /inside/ the partition as the (Partition's) Volume Boot Record.
But seeing as how there are four VBRs, and one MBR, I can technically install LILO into five independent and non-conflicting locations.
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/).
Aside: MS-DOS's boot code doesn't like multiple partitions being marked active.
Grant,
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".
*both* of them ? :-)
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. :-\
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.
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".
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.
Thats too bad, as that is simply the way it is. Sorry.
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) ?
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. :-(
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 ?
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.
I can't remember ever having claimed that. Quote please.
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 ?
At this moment ? Nope. Why would it ?
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.
https://thestarman.pcministry.com/asm/mbr/DOS50FDB.htm
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.
Odd, that DOS 6.22 FDISK example you started with doesn't do that at
all ...
How would you describe the following partitions?
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.
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. :-(
I agree with that stance. Just not with your hijacking of the phrase "primary partition".
Good for you. Now, how does that work under DOS, Window and possible
other OSes ?
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.
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.
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 ?
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) ....
Read: the DOS MBR code specifically checks for multiple partitions
being marked "active" and errors-out if found. :-)
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.
To me, the extended partition is the entry defined in one of the primary partition slots in the MBR partition table.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 910 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 208:18:48 |
| Calls: | 12,116 |
| Calls today: | 1 |
| Files: | 186,504 |
| Messages: | 2,226,570 |