Boot.ini question

Timothy Daniels desperately bull****ted
Rod Speed wrote

No user will ever be able to keep track of that ****...

*I* find it very easy to "keep track of that ****".

Lying again. In spades when the original drive that was
booted by the bios is no longer bootable and you want
to boot the same OS install that you normally boot of
another drive, or a different drive if the OS install you
normally boot is on a drive that the bios will no longer boot.

Timothy Daniels desperately bull****ted
Rod Speed wrote
Timothy Daniels bull****ted
Gerhard Fiedler wrote

Tim didn't say "on my machine, the rdisk number seems to be equivalent
to the position in the hard disk boot order list" -- he claims this to
be the case on all machines. Which I seriously doubt, and it seems I'm
not alone with this.

On Feb 1, in the thread "Boot.ini question", I posted:

Irrelevant to your pig ignorant PREVIOUS claim that the
rdisk() param ALWAYS referred to the entry in the hard
drive boot order list, you pathetic excuse for a bull**** artist.

You only did that test AFTER I rubbed your nose in the FACT
that your claim was just plain wrong, after initially claiming
that you couldnt understand what my test involved.

If by "that test" you mean verifying that the motherboard
controller didn't determine the "rdisk()" value just as the
PCI controller didn't determine the "rdisk()" value,

The test you lied about being 'gibberish' ****wit.

I merely verified my claim that "rdisk()" was a function of the BIOS, not
the IDE controller.

With just one completely ****ed bios implementation,
AFTER you pig ignorantly claimed that the rdisk()
ordinal was ALWAYS the order in the hard drive
boot order list, even when there was no such
animal in the bios. Wota terminal ****wit.

*You* haven't yet verified a thing

*I* made no claim, I just rubbed your stupid pig ignorant
silly little nose in the FACT that all the MS documentation
says its the ordinal of the drive ON THE CONTROLLER,
and that NOTHING FROM ANYONE EVEN MENTIONS ANY
HARD DRIVE BOOT ORDER LIST with the rdisk() param.

En , Rod Speed va escriu
Well, if DOS means "Disk Operating System",
NTLDR qualifies as a reduced one:
it certainly lacks many features you can expect (such as user
programability, just as most embeeded OS), but the basic ones
such as disk/FS support and resource management are.

Just being file system aware doesnt make it an OS.

Sure, but I did not write that.
Ntldr does manage resources, and this is precisely why I consider to be a
reduced OS.
Then, it also have a pretty good notion of filesystems, which is why I
compared it to the mythical DOS.
Note it even has plugable drivers, like Ntbootdd.sys.


Apps have always been able to operate directly on
a file system without there even being any OS at all,
tho you dont see that done very much anymore.

That's an aside, but I agree with the tendance is to program the whole thing
using (generally) Linux.


Look at SysLinux, its open source equivalent, to get my idea.

Not relevant to the story with ntldr.

Can you dare to elaborate?


Antoine

Antoine Leca wrote
Rod Speed wrote
Antoine Leca wrote
Rod Speed wrote
Folkert Rienstra wrote
Gerhard Fiedler wrote

Since at this point neither Windows nor
any kind of DOS has been loaded,

NTLDR is filesystem aware.

Irrelevant to whether Windows or any kind of DOS has been loaded.

Well, if DOS means "Disk Operating System",
NTLDR qualifies as a reduced one:

it certainly lacks many features you can expect (such as user
programability, just as most embeeded OS), but the basic ones
such as disk/FS support and resource management are.

Just being file system aware doesnt make it an OS.

Sure, but I did not write that.

You did however claim that its 'a reduced' DOS.

No it isnt, its just an executable that is file system aware.

Ntldr does manage resources,

No it doesnt. ALL it does is work out what should be booted
based on what is specified in boot.ini and what the user
specifys if there is more than one entry in that and the
user doesnt let it time out to the default entry.

And not everything that manages resources is a
'reduced OS' anyway, plenty of executables do that.

and this is precisely why I consider to be a reduced OS.

Its nothing like a reduced OS in fact, its just another
boot manager which happens to be file system aware.

Then, it also have a pretty good notion of filesystems,

It doesnt need that either, just be able to find boot.ini,
work out what partitions etc are on various physical
drives and how to boot a particular partition that the
particular boot.ini entry specifys needs to be booted.

which is why I compared it to the mythical DOS.

Its nothing like any mythical DOS.

Note it even has plugable drivers, like Ntbootdd.sys.

Doesnt make it a reduced OS, plenty
of executables have plugable drivers.

Apps have always been able to operate directly on
a file system without there even being any OS at all,
tho you dont see that done very much anymore.

That's an aside,

No, its the evidence that just being file system
aware doesnt mean that its a 'reduced' OS.

but I agree with the tendance is to program
the whole thing using (generally) Linux.

Look at SysLinux, its open source equivalent, to get my idea.

Not relevant to the story with ntldr.

Can you dare to elaborate?

syslinux has nothing to do with what ntldr does.

In ,
Rod Speed va escriu
Antoine Leca wrote
Gerhard Fiedler wrote

Admitting this lemma...

What's a lemma ?

Sorry for my bad command of English.
I should have explained that there were details in the above part I did not
completely agree with, but it was not worth detailling, so I assumed this
starting position is agreed with.


ntldr may be able to load Windows from drives the BIOS can't boot
from

What you seem to miss is that Tim's BIOS does not have such a
concept.

Irrelevant to the whole point of the rdisk() parameter.

Problably yes. Like the most part of this thread...


All that proves is that Tim's BIOS is a complete abortion
that utterly flouts the whole point of the rdisk() parameter.

I disagree.


Sure, one of my BIOS, and an awful large number of other BIOSes
out there as well, do have such drives; yet, there are other BIOSes
which allow to boot easily from any drive recognized by the BIOS
(BAID),

Not when its a logical drive in an extended dos partition.

Now *I* ask what is the relevance of this remark with the whole point of the
rdisk() parameter.

For what it is worth, I think it is possible to succesfully boot Ntldr in a
logical partition, using bootstrap code in EPBR and changing the
HiddenSectors parameters.


That was always one reason for the ntldr approach,

Sure, but again I do not see the point w.r.t. rdisk().

to allow booting of what the bios could not boot.

The very purpose of Ntldr+Boot.ini, like any boot loader, is to enhance
flexibility, yes.


It makes a hell of a lot more sense for the rdisk() param to
be the physical order of the drives on the controller instead

I disagree: I routinely boot an array (on a different controller) using
rdisk(N), with N being beyond the number of drives on the first controller
(where Boot.ini stands).

And I perfectly know that when I add or remove a disk in the first
controller (usually because it is down), I have to adjust the rdisk()
parameter accordingly.


so that the boot.ini doesnt need to be changed when the hard drive
boot order is changed, particularly when the order of the
drives below the entry at the top of the hard drive boot order
list are moved.

Sorry, I cannot make a sense of this.
Particularly, on a AMI bios I am using regularly, there is no such thing as
a "hard drive boot order list"; as I am saying since the first post after
Tim's...


(that is, it can't load ntldr from them).

That's two different things. Being able to boot from
a harddisk is ordinarily reserved to the 80h drive;

No it isnt with modern bios.

I know this is not required. In fact, it might have worked back in 1990 or
even earlier...
However, you have to assume this unless you want to play dangerously: far
too much code out there assume blindly _or_ studbornly the booting harddisk
is 80h.


Tim claimed that the rdisk() parameter is ALWAYS the entry in the
hard drive boot list.

Did not read the word "always" in his post: it just proposed a way to think
the rdisk() parameter as a "relative" position in this list.

And before you elaborate: if you find a quote of him saying "always", I
would claim he was wrong on this one. As I said since the beginning.


That its just plain wrong, and all he has proved is that it
is with that complete abortion of a bios he is using and

Nothing for me to comment here.

there are damned good reasons for not doing it like that.

Yes, I agree, you can find good reasons to keep the order as stable, that's
a good point.


And its certainly not what MS intended because none of the
ARC path documention even mentions the boot order list at all.

Here I disagree, for two reasons.

One is that the ARC path rdisk(N) mechanism was designed around 1990 to make
a gateway between the RISC world (where NT originally was born) and the
Intel/IBM/Compaq "i386" architecture; that's long before BBS. I very much
doubt if MS had the choice, they will still use it in 2006 (NT on MIPS
anyone?) As such, it is much of a legacy of the history, like for example
the Int13 interface itself.

The second is that MS had become the "official" source for the ARC path
mechanism, failling any alternative. Whatever they publish as documentation
will instantly becomes the Standard.
So it is normal practice for themselves to keep gray areas ("undocumented",
as Andrew Schulman &alii tagged it) in order to allow paths for future
expansions, as long as doing so does not hamper interoperability.


Antoine

Rod Speed wrote:

Antoine Leca wrote

You did however claim that its 'a reduced' DOS.

No it isnt, its just an executable that is file system aware.

Ntldr does manage resources,

And not everything that manages resources is a
'reduced OS' anyway, plenty of executables do that.

and this is precisely why I consider to be a reduced OS.

From http://en.wikipedia.org/wiki/Operating_system:

"The lowest level of any operating system is its kernel, the first layer of
software loaded into computer memory when it starts up. As the first
software layer, all other software that gets loaded after it depends on
this software to provide them with various common core services. These
common core services include, but are not limited to: disk access, memory
management, task scheduling, and access to other hardware devices."

Not really a 100% clear definition, and Wikipedia is possibly not the
ultimate resource on this. But the fact that ntldr never ever gets back
control nor provides any services for the running applications is a pretty
good indication that it is /not/ an OS (or what generally is considered an
OS).

Pretty much at the core of any OS is the ability to run more than one
application (not necessarily concurrently, but at least in sequence) and to
provide these applications with some services while they are running. ntldr
does neither -- once it has done its job (running one single "application")
it completely vanishes from the picture.

Gerhard

En ,
Timothy Daniels va escriu
In the Microsoft document "How to Determine the ARC Path"
(http://support.microsoft.com/default...b;en-us;155222)
it is stated:

"A typical ARC path might be:

multi(0)disk(0)rdisk(0)partition(2)\WINNT="My Server 4.0"

"The rdisk parameter is defined as HarddiskX on the
TargetDevice line, where X is a variable that represents
the drive ordinal. Note that the rdisk parameter is not used
when SCSI replaces multi in the ARC path."


Clearly, "rdisk()" refers to the position of the physical hard,

Not that clear to me.

but it does NOT state how that position (i.e. the "drive ordinal")
is derived.

It is pretty obvious to determine how it is really, even if this very
snippet does not explain it.

However, what is not said is how one can adjust it to his own taste.


That is left open to interpretation by manufacturers
such as Dell, to BIOS producers such as Phoenix Technologies,
and to ROM chip producers such as Intel.

Und so weiter. In fact, I have a very clear example in my head, with a SCSI
card which is BIOS-enabled; and I am not sure the way it is ultimately
derived is within the realm of the providers, but rather depends on my
fingers and the use I am making of the jumpers at the end of the _three_
disks...


Seeing that hard
drives do fail now and then, Dell's BIOS allows automatice
selection of another OS if the hard drive containing the primary
OS should fail. This will happen if there is another hard drive
next in the hard drive boot order having a bootable OS on it
in an active partition that has the same partition number as the
primary OS.

Well, such a carefully studied setup is not exactly common.
Furthermore, the various cheatsheets floating around are not pointing at
this direction, but rather at the Recovery console or ASR or PE or similar
hacks...


Also, if you have such a setup, chances are your backup Windows
configuration (on HD1) is outdated, so I am not sure I like it (say, as
automatic emergency for a unattended server.)

As I pointed out in a different thread, the problem I have with this and
similar ideas is that I am not sure cloning programs are smart enough to
make it working correctly; and shuffling MountedDevices is *not* something I
expect a cloning program to do, at least not until I explicitely order it.


Call me crazy if you want, but in such a case, I'll prefer to spend a bit
more of time and come with a setup which allows the server to boot
automatically (after _any_ disk crash, and also controller crash if I can)
by carefully crafting each and every one of the Boot.ini that could be
involved.

If it is about my own machine, I do not ca I quite probably shall massage
Boot.ini's numerous times before any disk will break (at least, I hope so.
;-))

And my users' machines do not usually have two disks, and when they have,
they do not expect it to work flawlessly after a crash anyway: having two
disks have much more to do with disk space than with security for them.


Antoine

En , Rod Speed va escriu
Antoine Leca wrote

Ntldr does manage resources,

Ntldr enumerates memory (and passes the memory map to the kernel),
enumerates PnP devices (that's NtDetect.com main job, because it has to be a
16-bit mode program), enumerates disks, loads the System registry, provides
console emulation including kanji, provides serial support etc. for
debugging. Etc.


ALL it does is work out what should be booted [...]

Well, loading NT Executive + its drivers is a somewhat complex task.
Furthermore, Ntldr's mission is to make the ball rolling, so it includes
providing numerous informations at determined places.

One could relatively easily write a loader for DOS; with documentation, it
is yet not very easy to write one for Linux, which is why Lilo was kept that
much time despite requiring an absolutely awkward making process.
I believe nobody except MS and the wizards could write something like Ntldr
(I mean the loading part); as far as I know, ReactOS' FreeLoader is not able
to launch MS Windows, it defers on Ntldr to do that.



Look at SysLinux, its open source equivalent, to get my idea.

syslinux has nothing to do with what ntldr does.

I disagree.
Syslinux/Isolinux loads itself from a FAT/ISO9660 volume, then reads it
configuration file, then (usually, depending of circumstances) loads the
kernel into memory, then unpacks the ramdisk, and finally starts the kernel.
Ntldr loads itself from a FAT16/ISO9660 volume (the boot record does for
FAT32/NTFS), then reads its configuration files, then inspects the
configuration, then (usually, depending of circumstances) loads the kernel
and the boot-time drivers into memory, and finally starts the kernel.

Major differences a
- NTFS support
- the registry
- Ntdetect
- the hability to use independant sidemodules (also with BootMgr)
- the HAL
- the ramdisk vs the preloaded device drivers
I stand on my point these differences are relatively unimportant compared to
the commonalities.


Antoine

En , Rod Speed va escriu
Thats a lousy way to test the claim that the rdisk()
parameter refers to the entry in the boot order list.

Remark: As I said long ago, I do not agree with that claim in general, just
in particular, not common, cases.


The only sensible way to test THAT claim is with the simplest
config of 3 hard drives, with the only boot.ini on the drive at the
top of the boot order list and swapping the order of the two
other drives which are below that in the boot order list

Well, results are quite funny.

Computer A, MSI-7032 (2004), AMI BIOS, K8M800 chipset (from memory, I do not
have the computer handy.) The IDE disks "below the first" do not show up in
any list. End of this test.

Computer(s) B, several Dell (2001-2005, Latitude 8100/4300/4600, Optiflex
115/150/260/270), so derivatives of Phoenix. The only list where the disks
"below the first" show up is the "Boot menu" (obtained with F10), which
allows to select a different disk to be the first one for that boot only (by
renumbering the disks, giving it the 80h ribbon). No way I can find to
change the order of the disks "below the first."
I have also a PowerEdge830, but it only has one IDE channel, and lacks the
F10 feature (or I missed it); at any rate I did not spot any list where the
IDE disks can be reordered.

Computer T, Dell XPS [Tim]. There _seems_ to be a "Hard Disk Boot order"
list, which is fully editable, and the positions there determine the BIOS
ordinal numbers.


I do not have currently a (recent) Award computer with several disks handy,
sorry; nor did I test the case where the 80h disk does not have the valid
(active) MBR yet forces a Int18 to boot the 81h disk (this one could be
interesting.)


In fact, I would be interested by what you folks understand as "the boot
order list", _including_ all bootable IDE disks ;-).
OK, I already got Tim's :-) no need to reiterate.
Also, I notice some BIOSes list HDD-1 to HDD-3 along with the traditionnal
A:, C:, CD-ROM, PXE etc. in the "IPL table"; (I should resurrect some
oldtimers since I seem to remember seeing this once); but this is NOT
universal behaviour as we can see from the above...
Perhaps reserved to the high-end boards? (I said that because I understand I
conducted all my tests with value-for-money computers.)


By the way, on computer A, the SATA disks are enumerated as several BCV
(clearly, main BIOS dated 2004 does not know about SATA), so I can reorder
them; as you select any of them, _all_ the SATA disks get the lowest
numbers; something similar occurs with USB, although it is quite of brocken
(there is only one BCV, even when it detects several devices).
That is, not only the relative position for the IDE disks is not editable,
but the various lists for the varying controllers behave as monolithic
entities.


Again :-), the best position is, it varies.


Antoine

Gerhard Fiedler wrote
Rod Speed wrote
Antoine Leca wrote
Rod Speed wrote
Antoine Leca wrote
Rod Speed wrote
Folkert Rienstra wrote
Gerhard Fiedler wrote

Since at this point neither Windows nor
any kind of DOS has been loaded,

NTLDR is filesystem aware.

Irrelevant to whether Windows or any kind of DOS has been loaded.

Well, if DOS means "Disk Operating System",
NTLDR qualifies as a reduced one:

it certainly lacks many features you can expect (such as user
programability, just as most embeeded OS), but the basic ones
such as disk/FS support and resource management are.

Just being file system aware doesnt make it an OS.

Sure, but I did not write that.

You did however claim that its 'a reduced' DOS.

No it isnt, its just an executable that is file system aware.

Ntldr does manage resources,

And not everything that manages resources is a
'reduced OS' anyway, plenty of executables do that.

and this is precisely why I consider to be a reduced OS.

From http://en.wikipedia.org/wiki/Operating_system:

"The lowest level of any operating system is its kernel, the first
layer of software loaded into computer memory when it starts up.

ntldr doesnt qualify, its just a boot manager. And that definition
of an OS glosses over how the OS is loaded. The NT/2K/XP
boot is quite complex and happens before the kernel is loaded.

As the first software layer, all other software that gets loaded
after it depends on this software to provide them with various
common core services. These common core services include,
but are not limited to: disk access, memory management,
task scheduling, and access to other hardware devices."

Thats all nothing to do with what ntldr does.

Not really a 100% clear definition,

Yeah, doesnt even mention the detail of how an OS is booted,
particularly a relatively complex boot like the NT/2K/XP boot.

and Wikipedia is possibly not the ultimate resource on this.

It certainly isnt.

But the fact that ntldr never ever gets back control nor provides
any services for the running applications is a pretty good indication
that it is /not/ an OS (or what generally is considered an OS).

Precisely.

Even the MSDOS boot is file system aware now.

Pretty much at the core of any OS is the ability to run more than one
application (not necessarily concurrently, but at least in sequence)
and to provide these applications with some services while they are
running. ntldr does neither -- once it has done its job (running one
single "application") it completely vanishes from the picture.

Yep. And the original, the fact that its file system aware is
completely irrelevant to whether its even a 'reduced' OS or
not. Plenty of executables are file system aware, everything
from some imagers to low level disk utes to drivers, etc etc etc.