How to boot OS/2 from logical partition?
Ilya Zakharevich
boot from a logical partition by itself - the (boot)loader won't not know
which partition is meant to boot.
So when a OS/2 is started from a boot manager, the latter should
communicate to the former the "partition number". IIRC, this number
is just ('F' - 'C' + certain_offset) (in C parlance, for booting from
f:), and it is put in a certain register when bootsector is executed.
Anyone remembering the details? (I mean the offset, and the
register. Or maybe one already has grub examples?)
Thanks,
Ilya
James J. Weinkam
years. On most of my systems all partitions (except boot manager) are logical
JFS partitions (technically volumes).
Even if OS/2 or eCS was installed to a primary partition, you can zip it up
and restore it to a bootable logical partition of the same file system and it
will boot without a problem.
You can even restore to a bootable partition of a different file system, then
run sysinstx.com against that partition and os/2 will boot.
Ilya Zakharevich
> Ilya Zakharevich wrote:
>> IIRC, it was posted on Usenet, but I can't find it now. OS/2 won't
>> boot from a logical partition by itself - the (boot)loader won't not know
>> which partition is meant to boot.
> OS/2 and eCS boot from a logical partition just fine and have done so for
> years.
Apparently, you did not read what I wrote. They cannot.
But I suppose you do not know the answers to my question anyway, so
never mind...
Yours,
Ilya
P.S. My OS/2 partitions are all logicals. But without a suitable
boot manager, they are not bootable...
Joe Negron
>On 2009-07-26, James J. Weinkam <j...@cs.sfu.ca> wrote:
>>Ilya Zakharevich wrote:
>>>IIRC, it was posted on Usenet, but I can't find it now. OS/2 won't
>>>boot from a logical partition by itself - the (boot)loader won't not know
>>>which partition is meant to boot.
>
>>OS/2 and eCS boot from a logical partition just fine and have done so for
>>years.
>
>Apparently, you did not read what I wrote. They cannot.
>
>
>P.S. My OS/2 partitions are all logicals. But without a suitable
> boot manager, they are not bootable...
Ilya,
While my current OS/2 boot partition is primary, I distinctly remember
being about to boot OS/2 from a logical partition. I don't know what
problem you're having, but it should be possible to do as you wish.
--
------------------------------------------------------------------------
Give to us clear vision that we may know where to stand and what to
stand for--because unless we stand for something, we shall fall for
anything.
--Peter Marshall
War is good for business - invest your son.
--antiwar bumper sticker from the 1960s
------------------------------------------------------------------------
Joe Negron from Bensonhurst, Brooklyn, NY, USA
Dave Yeo
You might want to look at the vpart sources if you can find your way
around them. Also IIRC Knut wrote a BootManager, kbm, so you might ask
on the libc users list.
I'd also like to know the magic and it would be nice if grub could
directly boot OS/2 on a logical partition.
Also be nice to know if LVM has changed any of this
Dave
Ilya Zakharevich
>>P.S. My OS/2 partitions are all logicals. But without a suitable
>> boot manager, they are not bootable...
> While my current OS/2 boot partition is primary, I distinctly remember
> being about to boot OS/2 from a logical partition. I don't know what
> problem you're having, but it should be possible to do as you wish.
What made you think I'm having problems (except a lack of knowledge ;-)?
I do not have any problem with boot.
Yours,
Ilya
Ilya Zakharevich
> OS/2 won't boot from a logical partition by itself - the (boot)loader
> won't not know which partition is meant to boot.
> So when a OS/2 is started from a boot manager, the latter should
> communicate to the former the "partition number". IIRC, this number
> is just ('F' - 'C' + certain_offset) (in C parlance, for booting from
> f:), and it is put in a certain register when bootsector is executed.
> Anyone remembering the details? (I mean the offset, and the
> register. Or maybe one already has grub examples?)
Today I ran over http://www.mgreene.org/wikka/BootableJFS.
According to the disassembly [*], only two registers matter:
edx: 0x00000080 -- Drive number
fs=0x3000 -- location of INT 13 Ext result
* If INT13 Ext functions are supported then 3000:0000, segment
contained in fs, has 58333149h, stored as 49 31 33 58. Otherwise
3000:0000 has 0.
= "I13X"; dissembly: http://www.mgreene.org/wikka/BootableJFSLVM
[*] There is one discrepancy: it says that cs=0 at start of Phase 2,
and cs=8800 at start of Phase 3; but cs is not touched in
http://www.mgreene.org/wikka/BootableJFSPartition
=========
In more details: phase 2 http://www.mgreene.org/wikka/BootableJFSPartition
Overwrites: sp ss ax bx es ds edi ebx si
Preserves: dx (Push/Pop)
Does not touch: cx fs cs
phase 3: http://www.mgreene.org/wikka/BootableJFSLoad
Overwrites: ecx
Preserves: dx
Apparently, [*], cs is reset somewhere before...
==========
Do not know how to translate the FS stuff into grub commands; and do
not know how to treat the discrepancy...
Any additional hints appreciated,
Ilya
P.S. Can't find even how to email the author of the web pages...
Ilya Zakharevich
>> So when a OS/2 is started from a boot manager, the latter should
>> communicate to the former the "partition number". IIRC, this number
>> is just ('F' - 'C' + certain_offset) (in C parlance, for booting from
>> f:), and it is put in a certain register when bootsector is executed.
> Today I ran over http://www.mgreene.org/wikka/BootableJFS.
>
> According to the disassembly [*], only two registers matter:
>
> edx: 0x00000080 -- Drive number
> fs=0x3000 -- location of INT 13 Ext result
Oups, just realized that this STILL does not answer my question: 0x80
is a DRIVE NUMBER, not partition number... There is dh "available",
of course; any one with a debuggin boot record which prints out
registers? ;-)
Puzzled,
Ilya
Dave Yeo
This code seems just to parse the MBR(s) looking for the BootManager as
well as checking integrity etc. You need to know how the BootManager
passes on the drive letter.
I'm curious too, plus it would be nice if grub could directly boot an
OS/2 logical partition.
Dave
Ilya Zakharevich
> This code seems just to parse the MBR(s) looking for the BootManager as
> well as checking integrity etc. You need to know how the BootManager
> passes on the drive letter.
Not necessarily. BM would start "some code", right? You can either
analyse BM code, or the code it starts (the whole OS, obviously ;-).
So my analysis shows that only ecx edx cs fs are not overwritten by
JFS boot record. If one BELIEVES some more assumptions (hard to be
sure due to contradictions in the text in question), then ecx and
cs are overwritten on the next step. So only fs and edx may carry
this info - and we know exactly what fs means...
Yours,
Ilya
Dave Yeo
> On 2010-03-28, Dave Yeo<dave....@gmail.com> wrote:
>> This code seems just to parse the MBR(s) looking for the BootManager as
>> well as checking integrity etc. You need to know how the BootManager
>> passes on the drive letter.
>
> Not necessarily. BM would start "some code", right? You can either
> analyse BM code, or the code it starts (the whole OS, obviously ;-).
>
Actually the BM just loads the EPBR which for OS/2 using an IFS loads
the microfs which just has the brains to load the minifs which can read
\, \os2, \os2\boot. Setup the memory somehow so the kernel once loaded
can use the minifs to load the basedev drivers, the IFS etc. Then loads
the kernel and passes control to it. Once the kernel loads the IFS then
it can start using the IFS to load everything else.
So there is a couple of steps before the whole OS starts and those steps
don't need to know the drive letter.
There is some info on this in the ext2 driver package. I note that to
run OS/2 on ext2 the authour used LILO to load the microfs and pass the
drive letter, bios device, etc to it.
Dave
Ilya Zakharevich
>>> This code seems just to parse the MBR(s) looking for the BootManager as
>>> well as checking integrity etc. You need to know how the BootManager
>>> passes on the drive letter.
>> Not necessarily. BM would start "some code", right? You can either
>> analyse BM code, or the code it starts (the whole OS, obviously ;-).
> Actually the BM just loads the EPBR which for OS/2 using an IFS loads
> the microfs which just has the brains to load the minifs which can read
> \, \os2, \os2\boot. Setup the memory somehow so the kernel once loaded
> can use the minifs to load the basedev drivers, the IFS etc. Then loads
> the kernel and passes control to it. Once the kernel loads the IFS then
> it can start using the IFS to load everything else.
> So there is a couple of steps before the whole OS starts and those steps
> don't need to know the drive letter.
All true, but I have no idea what is the point you wanted to get
through here...
> There is some info on this in the ext2 driver package. I note that to
> run OS/2 on ext2 the authour used LILO to load the microfs and pass the
> drive letter, bios device, etc to it.
Interesting. Do you mean ext2_240.zip on Hobbes?
Thanks,
Ilya
Dave Yeo
> On 2010-03-28, Dave Yeo<dave....@gmail.com> wrote:
>
>>>> This code seems just to parse the MBR(s) looking for the BootManager as
>>>> well as checking integrity etc. You need to know how the BootManager
>>>> passes on the drive letter.
>
>>> Not necessarily. BM would start "some code", right? You can either
>>> analyse BM code, or the code it starts (the whole OS, obviously ;-).
>
>> Actually the BM just loads the EPBR which for OS/2 using an IFS loads
>> the microfs which just has the brains to load the minifs which can read
>> \, \os2, \os2\boot. Setup the memory somehow so the kernel once loaded
>> can use the minifs to load the basedev drivers, the IFS etc. Then loads
>> the kernel and passes control to it. Once the kernel loads the IFS then
>> it can start using the IFS to load everything else.
>> So there is a couple of steps before the whole OS starts and those steps
>> don't need to know the drive letter.
>
> All true, but I have no idea what is the point you wanted to get
> through here...
Just that the drive letter might not be in a register. but passed in
memory and is not needed till after the kernel is loaded.
>
>> There is some info on this in the ext2 driver package. I note that to
>> run OS/2 on ext2 the authour used LILO to load the microfs and pass the
>> drive letter, bios device, etc to it.
>
> Interesting. Do you mean ext2_240.zip on Hobbes?
Yes
Dave
Ilya Zakharevich
>>> Actually the BM just loads the EPBR which for OS/2 using an IFS loads
>>> the microfs which just has the brains to load the minifs which can read
>>> \, \os2, \os2\boot. Setup the memory somehow so the kernel once loaded
>>> can use the minifs to load the basedev drivers, the IFS etc. Then loads
>>> the kernel and passes control to it. Once the kernel loads the IFS then
>>> it can start using the IFS to load everything else.
>>> So there is a couple of steps before the whole OS starts and those steps
>>> don't need to know the drive letter.
> Just that the drive letter might not be in a register. but passed in
> memory and is not needed till after the kernel is loaded.
Saved as some interrupt address, or what? There is a lot of
"executables" which may be run between BM and os2ldr; how would they
know which memory regions to save? And saving registers is cheap...
So I still think it is somewhere in edx...
[Just some logical arguments; they do not work when back-guessing
software development; on the other hand, OS/2 was kind of "logically
designed"...]
Thanks,
Ilya
Allan
Not sure, if you are looking for code to boot Logical partitions in
general, or JFS........ but osFree can do both.
osFree can boot any Primary/Logical partition from is own MBR,
or it can use its own bootmanager (FreeLDR) to do it (in more
advanced ways).
FreeLDR can even boot JFS on SCSI , where eCS gives up.
No binaries are available yet ( but they will be RSN :-) ) -
but it is Open Source, and I guess that is really what you are
looking for.
Poke around on
.and you may find, what you need...
--
Allan.
It is better to close your mouth, and look like a fool,
than to open it, and remove all doubt.
Ilya Zakharevich
> On Mon, 29 Mar 2010 08:30:58 UTC, Ilya Zakharevich <nospam...@ilyaz.org> wrote:
> Poke around on
> http://www.osfree.org
> .and you may find, what you need...
Thanks. Here is my summary of how to boot OS/2 from logical partition:
Apparently, Dave Yeo is write: the partition number byte is written
at address (0x7c00 + 0x200 - 0x44). The address 0x30000 contains a
4bytes "I13X" if int13 extensions are available, or 0 otherwise. fs
is set to the sector number 0x3000 of this address.
=========== Details:
osfree: loader/os2.cfg uses chain.mdl with options --bootdev=$(dsk)
(and possibly --i13x)
$dsk is parsed by bootseq/loader/setdev.c:set_device()
if (*device >= 'a' && *device <= 'h')
current_partition = (((*(device++) - 'a') << 8)
| (current_partition & 0xFF00FF));
See http://osfree.svn.sourceforge.net/viewvc/osfree/trunk/bootseq/loader/setdev.c?view=markup
the result partition number byte is written by kernels/chainc.c to address (yes!)
(the commend is WRONG; the shift is by 8!)
// BootPart address. Here we copy
// ((current_partion & 0xff0000) >> 12)
#define BOOTPART_ADDR (0x7c00 + 0x200 - 0x44)
Yours,
Ilya
P.S. I still do not remember whether grub/grub4dos can write to
arbitrary addresses (and set fs) before chain-loading...
Especially hard might be to test i13x first... But anyway, if
chain.mdl is made available as grub loader, I think the things
would be a breeze...
Jonathan de Boyne Pollard
>
> the result partition number byte is written by kernels/chainc.c to
> address (yes!)
>
notice. I think that this is a red herring.
Jonathan de Boyne Pollard
>
> Not sure, if you are looking for code to boot Logical partitions in
> general, or JFS........
>
handshake code that IBM Boot Manager uses to convey the partition number
to the OS/2 kernel. The kernel uses this value to determine what the
boot drive letter is. Without it, one encounters the odd situation of
booting from a volume that OS/2 thinks to be (say) drive H:, but with
the kernel thinking that the boot drive letter is 'C'. It's not so
noticeable when OS/2 is in a primary partition, but when it is in a
secondary volume in an extended partition, and one has multiple discs,
and one isn't booting via IBM Boot Manager, this situation is prone to
occur. It happens on one of my machines.
Ilya Zakharevich
Hmm, BOOTPART_ADDR (0x7c00 + 0x200 - 0x44) is indeed within 512 bytes
of BOOTSEC_LOCATION (0x7C00)...
If so, then the only position where boot partition survives in
current_partition, which has a good chance to be copied to EDX, which
would leave boot_partion - 'a' in DH... Hmm, can't find code for this
in chain.asm (only if --edx is given...).
Thanks for noticing this,
Ilya
Jonathan de Boyne Pollard
>
> any one with a debuggin boot record which prints out registers? ;-)
>
(-: I suspect that it won't help, though, for two reasons. First, I
think that this information isn't passed to the VBR, but is stashed away
by IBM Boot Manager somewhere else, that OS2LDR/OS2KRNL (whichever of
them it is) goes and picks up. Second, I have a suspicion that this
location is on disc rather than in memory, given that every time IBM
Boot Manager boots something on my system it triggers the firmware's
"Something is writing to a boot sector!" anti-virus warning.
Pretty certainly, the EDX value passed to the VBR is a red herring. Go
and look at Hale Landis' disassembly of the OS/2 FAT filesystem VBR. It
throws DX away, and uses the drive number from its embedded BPB. (My
boot manager fixes up the embedded BPBs of such VBRs when loading them,
for this very reason.) It seems unlikely that IBM Boot Manager is
expecting the high 16 bits of EDX to be preserved across the VBR code
(and the firmware I/O routines that it invokes).
It might be more helpful to look at this from the other direction.
Where, in the kernel, is MFSH_SETBOOTDRIVE() being called, and where is
the information passed to that call being obtained from?
James J. Weinkam
I built a new desktop computer some time ago. The motherboard is ASUS A8N5X
and I was running eCS1.2MR at the time. I am now running eCS2.0RC7-Silver
release and the behavior under this release is the same.
The motherboard has 4 SATA connectors arranged as a 2x2 array:
A B
C D
The BIOS and CMOS setup program number the connectors as follows: A=4, B=3,
C=2, D=1. This is clearly shown on the board itself and on the diagram in the
manual. The CMOS Setup also has 2 independent options, one enables sockets 1
and 2, the other enables sockets 3 and 4. I originally installed 2 250GB
Seagate Barracudas on SATA1 and SATA2 and disabled 3 and 4.
With this configuration, both DFSee and LVM agree that the drive with boot
manager and the main eCS boot volume is drive 1 which is the drive connected
to SATA1 and the maintenance partition is on drive 2. The BIOS also agrees as
I verified by powering up with only one drive connected at a time and seeing
how the drive is displayed in CMOS Setup and on the boot manager menu.
Subsequently, I bought two 500GB Barracudas and connected them to SATA3 and 4.
CMOS Setup shows the 250's on 1 and 2 and the 500's on 3 and 4. However
upon booting OS/2, DFSee gives the warning that there is no active partition
on drive 1 and both DFSee and LVM show the 500's as physical drives 1 and 2
and the 250's as drives 3 and 4. The mapping eCS is using is A=2, B=1, C=4, D=3
Although the system boots cabled that way, I reconnected the drives so that
boot manager and the eCS boot volume are on what eCS sees as drive 1 and the
500's are on what eCS sees as drives 3 and 4. This seemed to work, but once I
had created volumes on the new drives the system would not boot. I
circumvented this problem by booting from the eCS install disk with only the
500's connected and installing a copy of boot manager on the drive connected
to what the BIOS sees as SATA1.
The system works flawlessly, but there are definitely two schools of thought
on the numbering of the drives when both SATA controllers are enabled.
Ilya Zakharevich
> and look at Hale Landis' disassembly of the OS/2 FAT filesystem VBR. It
> throws DX away, and uses the drive number from its embedded BPB. (My
> boot manager fixes up the embedded BPBs of such VBRs when loading them,
> for this very reason.)
Could you describe it more precise: "fixes" at which offset, and how?
> It seems unlikely that IBM Boot Manager is
> expecting the high 16 bits of EDX to be preserved across the VBR code
> (and the firmware I/O routines that it invokes).
Saving/restoring DX around these calls is cheap (and, as you can see,
is exactly what JFS boot code is doing...).
> It might be more helpful to look at this from the other direction.
> Where, in the kernel, is MFSH_SETBOOTDRIVE() being called, and where is
> the information passed to that call being obtained from?
Unfortunately, the only disassembpy of OS/2 kernel I know of (one used
to compile OS/4 kernel) is not public...
Thanks,
Ilya
PS. BTW, I compared boot sectors of my 2 bootable HPFS logicals (D
and F; differ by 2), and do not see any bits which differ by 2 in
the expected direction (so if things are written on disk, then
not in boot sectors):
--- disk-D-bs-ox Wed Mar 31 13:45:44 2010
+++ disk-F-bs-ox Wed Mar 31 13:45:48 2010
@@ -1,7 +1,7 @@
-000000 eb 4e 90 49 42 4d 20 34 2e 35 30 00 02 40 01 00
+000000 eb 4e 90 49 42 4d 20 34 2e 35 30 00 02 20 01 00
^^
-000010 00 00 02 00 00 f8 00 01 3f 00 ff 00 3f 00 00 00
+000010 00 00 02 00 00 f8 82 00 3f 00 ff 00 3f 00 00 00
^^^^^
-000020 86 fa 3f 00 80 8a 28 15 f4 e1 a9 4e 4f 52 4d 41
+000020 83 2d 10 00 80 00 28 15 28 a1 a9 4d 49 52 52 4f
^^^^^^^^ ^^ ^^^^^ ^^^^^ ^^^^^
-000030 4c 20 42 4f 4f 00 48 50 46 53 20 20 20 20 00 00
+000030 52 2d 46 00 00 00 48 50 46 53 20 20 20 20 00 00
^^^^^^^^^^^^^^
Steven Levine
<J.deBoynePoll...@NTLWorld.COM> wrote:
Hi,
>Second, I have a suspicion that this
> location is on disc rather than in memory, given that every time IBM
> Boot Manager boots something on my system it triggers the firmware's
> "Something is writing to a boot sector!" anti-virus warning.
Yep. The Boot Manager as a stand-in for the BIOS. The partition boot
sector code can not tell if it was called by the BIOS or a Boot
Manager.
> Pretty certainly, the EDX value passed to the VBR is a red herring.
It's not. This is a phyical drive number, not a drive letter. It's
valid, but most of the boot sectors I have seen do not use it. As you
found, they tend to use the drive number in the BPB.
> It might be more helpful to look at this from the other direction.
> Where, in the kernel, is MFSH_SETBOOTDRIVE() being called, and where is
> the information passed to that call being obtained from?
The boot volume drive letter typically gets set twice. The first
occurs when OS2LDR passes control to the kernel. The kernel sets the
drive letter based on the content of the BPB passed to OS2LDR from the
boot loader. This letter is typically wrong, but it does not matter
because effectively there no drive letters until miniIFS for the boot
volume initializes.
The second set occurs with the miniFSD MFS_INIT routine calls
MFSH_SETBOOTDRIVE. This drive letter must be valid or you will get
the unable to operate failure.
As to where the miniFSD gets the drive letter from, it varies for each
IFS. The sys routine that writes the boot sector, bootloader and
OS2BOOT to disk is responsible knows what is required.
Steven
--
---------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
Jonathan de Boyne Pollard
>>
>> Pretty certainly, the EDX value passed to the VBR is a red herring.
>> Go and look at Hale Landis' disassembly of the OS/2 FAT filesystem
>> VBR. It throws DX away, and uses the drive number from its embedded
>> BPB. (My boot manager fixes up the embedded BPBs of such VBRs when
>> loading them, for this very reason.)
>>
> Could you describe it more precise: "fixes" at which offset, and how?
>
*>(boot_record + 0x000B) ;
CBPB.DriveNumber = Partitions[selection].drive ;
Without this, a VBR loaded from (say) drive 0x81 attempts to read the
operating system from drive 0x80, because 0x80 is the value in that
field of the BPB in the VBR as it exists on disc. For clarity: The
CommonBPB structure type describes the common subset of the version 4.0
and version 8.0 BIOS Parameter Blocks, and this fixup is only applied to
VBRs that have such BPBs.
>> It seems unlikely that IBM Boot Manager is expecting the high 16 bits
>> of EDX to be preserved across the VBR code (and the firmware I/O
>> routines that it invokes).
>>
> Saving/restoring DX around these calls is cheap (and, as you can see,
> is exactly what JFS boot code is doing...).
>
Saving the lower 16 bits of EDX does not save the upper 16 bits.
> PS. BTW, I compared boot sectors of my 2 bootable HPFS logicals (D and
> F; differ by 2), and do not see any bits which differ by 2 in the
> expected direction (so if things are written on disk, then not in boot
> sectors):
>
No, they won't be. Now go and look at block #1 of your IBM Boot Manager
volume.
Jonathan de Boyne Pollard
>>
>> Pretty certainly, the EDX value passed to the VBR is a red herring.
>>
> It's not. This is a phyical drive number, not a drive letter.
>
is looking for drive letters not INT 0x13 drive numbers. (-:
>> It might be more helpful to look at this from the other direction.
>> Where, in the kernel, is MFSH_SETBOOTDRIVE() being called, and where
>> is the information passed to that call being obtained from?
>>
> The boot volume drive letter typically gets set twice. The first
> occurs when OS2LDR passes control to the kernel. The kernel sets the
> drive letter based on the content of the BPB passed to OS2LDR from the
> boot loader. This letter is typically wrong, but it does not matter
> because effectively there no drive letters until miniIFS for the
> boot volume initializes.
>
The only way that I can think of of working out a drive letter from a
BPB alone is after one has read the partition table, i.e. after the DMDs
have initialized. And I can think of several ways where, indeed, this
can go hopelessly wrong. Is this where the kernel is doing this?
> The second set occurs with the miniFSD MFS_INIT routine calls
> MFSH_SETBOOTDRIVE. This drive letter must be valid or you will get the
> unable to operate failure.
>
> As to where the miniFSD gets the drive letter from, it varies for each
> IFS.
>
So where do, say, the FAT and HPFS mini-FSDs obtain this information
from? Because there's a definite interaction with IBM Boot Manager in
there, somewhere. I have a system installation here that is assigned
three different boot drive letters at boot time, none of which are
right, depending solely from whether I boot it (a) via IBM's Boot
Manager on disc number 0x80, (b) through another boot manager on disc
number 0x00, or (c) through another boot manager on disc number 0x81.
The only difference between the (a) and (b) processes is whatever secret
internal magic IBM's Boot Manager is doing. (There's a difference
between the two of those and (c) that I've determined to be the firmware
interchanging 0x80 and 0x81 at the INT 0x13 API.)
Jonathan de Boyne Pollard
>> Second, I have a suspicion that this location is on disc rather than
>> in memory, given that every time IBM Boot Manager boots something on
>> my system it triggers the firmware's "Something is writing to a boot
>> sector!" anti-virus warning.
>>
> Yep. The Boot Manager as a stand-in for the BIOS. The partition boot
> sector code can not tell if it was called by the BIOS or a Boot Manager.
>
One doesn't have to write to the disc in order to read and load a VBR. (-:
Steven Levine
<J.deBoynePoll...@NTLWorld.COM> wrote:
> That makes it a red herring, if, as both M. Zakharevich and I are, one
> is looking for drive letters not INT 0x13 drive numbers. (-:
That does not make the passed value invalid. It just not the one you
want to find.
> The only way that I can think of of working out a drive letter from a
> BPB alone is after one has read the partition table, i.e. after the DMDs
> have initialized.
That not how it's done for bootable JFS, which is what I am most
familar with. The drive letter is stored in the extended BPB at
offset 0x2d. Turns out this was not a perfect solution, but that's
been taken care of.
>And I can think of several ways where, indeed, this
>can go hopelessly wrong. Is this where the kernel is doing this?
When it comes to boot drive letters, the kernel trusts the IFS. Other
drive letters are handled by OS2DASD.DMD and OS2DASD/OS2LVM.DMD
depending on what you are running.
> So where do, say, the FAT and HPFS mini-FSDs obtain this information
> from?
I never needed to figure this out, so I can only speculate. I suspect
the the drive letters are embedded somewhere in the boot loader. If I
get sufficiently curious I will disassemble an HPFS boot loader and
find out if this is true.
>Because there's a definite interaction with IBM Boot Manager in
> there, somewhere. I have a system installation here that is assigned
> three different boot drive letters at boot time, none of which are
> right, depending solely from whether I boot it (a) via IBM's Boot
> Manager on disc number 0x80, (b) through another boot manager on disc
> number 0x00, or (c) through another boot manager on disc number 0x81.
> The only difference between the (a) and (b) processes is whatever secret
> internal magic IBM's Boot Manager is doing. (There's a difference
> between the two of those and (c) that I've determined to be the firmware
> interchanging 0x80 and 0x81 at the INT 0x13 API.)
I'm sure you are correct. There's a lot of variables. There are
multiple versions of BM - LVM and non-LVM. Othere boot managers play
by the rules they define.
Jonathan de Boyne Pollard
>>
>> That makes it a red herring, if, as both M. Zakharevich and I are,
>> one is looking for drive letters not INT 0x13 drive numbers. (-:
>>
> That does not make the passed value invalid. It just not the one you
> want to find.
>
>> The only way that I can think of of working out a drive letter from a
>> BPB alone is after one has read the partition table, i.e. after the
>> DMDs have initialized. And I can think of several ways where, indeed,
>> this can go hopelessly wrong. Is this where the kernel is doing this?
>>
> When it comes to boot drive letters, the kernel trusts the IFS. Other
> drive letters are [...]
>
That doesn't really answer the question. You just wrote that the kernel
"sets the drive letter based on the content of the BPB passed to OS2LDR
from the boot loader". I asked you if it is doing this after the DMDs
have initialized.
> That not how it's done for bootable JFS, which is what I am most
> familar with. The drive letter is stored in the extended BPB at offset
> 0x2d. Turns out this was not a perfect solution, but that's been taken
> care of.
>
How the mini-FSD picks up the drive letter to pass to the kernel is a
different question. You said that the kernel first works out a drive
letter by itself, without reference to the mini-FSD, based upon the BPB.
I can see why zapping the filesystem type field isn't particularly
perfect, by the way. (-:
>> So where do, say, the FAT and HPFS mini-FSDs obtain this information
>> from?
>>
> I never needed to figure this out, so I can only speculate. I suspect
> the the drive letters are embedded somewhere in the boot loader. If I
> get sufficiently curious I will disassemble an HPFS boot loader and
> find out if this is true.
>
Hale Landis disassembled the FAT VBR years ago. There's nothing in
there to do with drive letters. If IBM's Boot Manager is writing the
drive letter somewhere into the FAT or HPFS VBR after loading it into
memory, it's being picked up from there either by OS2LDR/OS2KRNL or by
the mini-FSD. Disassembling the VBRs won't tell you where that is.
Disassembling IBM's Boot Manager might, of course. (-:
I vaguely recall that someone disassembled the HPFS VBR, too. But I
cannot find any trace of that.
> There are multiple versions of BM - LVM and non-LVM. Othere boot
> managers play by the rules they define.
>
Actually, the rules are largely prescribed for boot managers, not
defined by them. Where one loads the VBRs and what registers are
defined upon entry when invoking them are defined, or at least very well
known. The problem here is that IBM's Boot Manager is doing something
additional, secret, and undocumented, that affects the OS/2 kernel's
choice of boot drive letter.
Ilya Zakharevich
>>> Pretty certainly, the EDX value passed to the VBR is a red herring.
>>> Go and look at Hale Landis' disassembly of the OS/2 FAT filesystem
>>> VBR. It throws DX away, and uses the drive number from its embedded
>>> BPB. (My boot manager fixes up the embedded BPBs of such VBRs when
>>> loading them, for this very reason.)
>> Could you describe it more precise: "fixes" at which offset, and how?
>>
> CommonBPB & CBPB = *reinterpret_cast<CommonBPB
> *>(boot_record + 0x000B) ;
> CBPB.DriveNumber = Partitions[selection].drive ;
I see. Somehow I got a misplaced impression that you discuss the
partition number (when you clearly said DRIVE number :-[).
>>> It seems unlikely that IBM Boot Manager is expecting the high 16 bits
>>> of EDX to be preserved across the VBR code (and the firmware I/O
>>> routines that it invokes).
>>>
>> Saving/restoring DX around these calls is cheap (and, as you can see,
>> is exactly what JFS boot code is doing...).
>>
> Saving the lower 16 bits of EDX does not save the upper 16 bits.
dh is enough... - it is where all the code I saw puts the partition
"letter"...
>> PS. BTW, I compared boot sectors of my 2 bootable HPFS logicals (D and
>> F; differ by 2), and do not see any bits which differ by 2 in the
>> expected direction (so if things are written on disk, then not in boot
>> sectors):
> No, they won't be. Now go and look at block #1 of your IBM Boot Manager
> volume.
"Block"? (I think I know where BM stores its config, but just to be sure...)
Thanks,
Ilya
Steven Levine
<J.deBoynePoll...@NTLWorld.COM> wrote:
Hi,
> You know that being a red herring is nothing to do with validity, right?
If you say so. I've seen the term used both ways.
> That doesn't really answer the question. You just wrote that the kernel
> "sets the drive letter based on the content of the BPB passed to OS2LDR
> from the boot loader". I asked you if it is doing this after the DMDs
> have initialized.
And I said no. I said it was done shortly after os2ldr passes control
to to the kernel. It's actually done before the kernel debugger will
give you control.
> How the mini-FSD picks up the drive letter to pass to the kernel is a
> different question. You said that the kernel first works out a drive
> letter by itself, without reference to the mini-FSD, based upon the BPB.
Not quite. I said it used the value passed to in BPB which may or may
not be correct. If you care to haul out pmdf or the kernel debugger,
the code is in SYIInitOS2.
> I can see why zapping the filesystem type field isn't particularly
> perfect, by the way. (-:
0x2d? Sorry. Where did that come from? It's either offset 0x25 or
0x1a, depending whether you are counting from the start of the boot
sector or the start of the BPB. The JFS implementers called this byte
CurrentHead.
> Hale Landis disassembled the FAT VBR years ago.
BTW, by VBR, do you mean the boot sector or the entire boot loader?
> I vaguely recall that someone disassembled the HPFS VBR, too. But I
> cannot find any trace of that.
I got sufficiently curious to disassemble an HPFS
bootsector/bootloader and the 14.93 OS2BOOT last night, during TV
time. I did not find the code that sets the boot drive letter to pass
to os2ldr in the BPB, but I suspect it must rewrite the drive# field
before passing control to os2ldr. I say this because OS2BOOT contains
no calls to MFSH_SETBOOTDRIVE.
I don't have a bootable OS/2 FAT volume, so I can't say anything
specific about how it determines the boot drive letter.
BTW, my understanding of why OS/2 can't boot from an extended
partition without a boot manager is that the typical BIOS will only
load boot sectors from a primary.
Also, partition numbers and drive letters are not used by the boot
sector, the microFSD or the miniFSD. The drive number and the hidden
sectors BPB field are used to locate the start of the partition.
Finally, boot sectors vary. For example, the JFS bootsector assumes
that extended INT13 is available. It will work just fine with boot
managers that don't stuff I13X at 3000:0. I suspect an OS/2 FAT
bootsector may not even contain code to check for extended INT13
support.
Jonathan de Boyne Pollard
>>
>> CommonBPB & CBPB = *reinterpret_cast<CommonBPB *>(boot_record + 0x000B) ;
>> CBPB.DriveNumber = Partitions[selection].drive ;
>> CBPB.flags = 0x80 + ConfigInfo.os2_boot_drive ;
>>
> I see. Somehow I got a misplaced impression that you discuss the
> partition number (when you clearly said DRIVE number :-[).
>
deals in partition numbers is the code that the kernel uses to calculate
a drive letter based upon the BPB. The way to do that is to scan the
partition table for the given drive number, and compare each partition
with the supplied BPB. Of course, this can go wrong in several ways,
not least if one has multiple drives, but it or something like it is
what I suspect happens, because some of the behaviour that I've seen
matches it.
As far as I can tell, this is the fallback algorithm, that
OS2LDR/OS2KRNL uses in the absence of a specific drive letter passed to
it by IBM's Boot Manager, through the secret handshake that we have been
looking for (and in the presence of the NOVOLIO flag, of course).
>>>> It seems unlikely that IBM Boot Manager is expecting the high 16
>>>> bits of EDX to be preserved across the VBR code (and the firmware
>>>> I/O routines that it invokes).
>>>>
>>> Saving/restoring DX around these calls is cheap (and, as you can
>>> see, is exactly what JFS boot code is doing...).
>>>
>> Saving the lower 16 bits of EDX does not save the upper 16 bits.
>>
> dh is enough... - it is where all the code I saw puts the partition
> "letter"...
>
If it's the code that we looked at for FreeLDR, then it isn't encoding
the drive letter in the right format. The "right" encoding only allows
drives from 'C' upwards.
Notice, also, that upon entry to OS2LDR, whilst DL still contains the
INT 0x13 drive number that was originally passed to the VBR, DH contains
a set of flag bits and doesn't encode a drive letter. So DH is already
used for another purpose by the time that OS2LDR is reached, and isn't
the secret place where IBM's Boot Manager stashes the drive letter.
>>> PS. BTW, I compared boot sectors of my 2 bootable HPFS logicals (D
>>> and F; differ by 2), and do not see any bits which differ by 2 in
>>> the expected direction (so if things are written on disk, then not
>>> in boot sectors):
>>>
>> No, they won't be. Now go and look at block #1 of your IBM Boot
>> Manager volume.
>>
> "Block"? (I think I know where BM stores its config, but just to be
> sure...)
>
Yes, there. IBM Boot Manager rewrites it every time it that it boots.
Dave Yeo
> BTW, my understanding of why OS/2 can't boot from an extended
> partition without a boot manager is that the typical BIOS will only
> load boot sectors from a primary.
>
> Also, partition numbers and drive letters are not used by the boot
> sector, the microFSD or the miniFSD. The drive number and the hidden
> sectors BPB field are used to locate the start of the partition.
I looked at Knut's kbootloader (kbm36005a.zip on Hobbes) hoping he
included source. No source but I did see this in history.txt.
ver 0.30.Alphas
---------------
new: Booting OS/2 from extended partition.
-Solution was to update "Special Hidden
Sectors" before staring it in memory.
-bootQueryLetter - the miniFSD in the LDR (?)
needs to know which drive letter it is booting from.
This letter is provieded thru the drive number
WORD. The high part of the word contains the letter number. C=80h,
D=81h,... ; 00h=C
Booting extended partitions as primary.
Booting extended partitions without primary parititon(s).
Booting extended partitions without primary
parititon(s) on boot
drive.
Dave
Jonathan de Boyne Pollard
>
> BTW, my understanding of why OS/2 can't boot from an extended
> partition without a boot manager is that the typical BIOS will only
> load boot sectors from a primary.
>
(apart from the VBRs on non-partitioned discs). Non-EFI firmwares only
ever boot block #0 of the disc. It's the MBR code in that block, not
the firmwares, that has to know about finding and bootstrapping the VBRs
from secondary partitions. Most MBR code only knows about the four
partition table entries in block #0, and even the MBRs that know about
more than that (such as the IBM-provided one that IBM's FDISK will
write) don't know about secondary partitions. (The IBM-provided MBR
knows to go looking at the block #0 partition table entries on the
"other" INT 0x13 disc for a type 0x0A entry, so that IBM's Boot Manager
can be found even if it ends up on disc 0x81 instead of 0x80.)
This isn't an OS/2-specific limitation. It's a limitation of pretty
much everyone's MBR code (IBM's, Microsoft's, mine, and others') that
stops any operating system, not just OS/2, from being booted from a
secondary partition, without the MBR booting a boot manager from a
primary partition (or loading a computer-virus-style boot manager) that
knows how to process the rest of the partition table.
> Also, partition numbers and drive letters are not used by the boot
> sector, the microFSD or the miniFSD. The drive number and the hidden
> sectors BPB field are used to locate the start of the partition.
>
... which is why boot managers, such as mine, need to fix them up on the
fly, as they are loaded into memory, for drive numbers other than 0x80
and for non-primary partitions, since the on-disc values aren't correct
as they stand. I showed some of the fixup code for that from my boot
manager in a previous message. My Frequently Given Answer on BIOS
Parameter Blocks contains more details.
> Finally, boot sectors vary. For example, the JFS bootsector assumes
> that extended INT13 is available. It will work just fine with boot
> managers that don't stuff I13X at 3000:0.
>
I've never understood the point of this "I13X" flag scheme. I've never
bothered with it. It's fairly easy to write a VBR that tries the the
INT 0x13 extensions and falls back to the original API if they fail. I
know. I've written such VBRs, and had them fall back on systems where
the extensions aren't present (which includes an OS/2 VMB,
incidentally). Indeed, one such VBR bootstraps my boot manager. (I
even considered, a while back, just taking the fallback code out and
assuming that the extended API would always be present. It makes more
space for the VBR error message strings. (-:)
Jonathan de Boyne Pollard
>>>
>>> The drive letter is stored in the extended BPB at offset 0x2d. Turns
>>> out this was not a perfect solution, but that's been taken care of.
>>>
>> particularly perfect, by the way. (-:
>>
> 0x2d? Sorry. Where did that come from?
>
> It's either offset 0x25 or 0x1a, depending whether you are counting
> from the start of the boot sector or the start of the BPB. The JFS
> implementers called this byte CurrentHead.
>
They were wrong on two counts. (-: It's the total number of heads, and
it's a 16-bit word, not a byte.
> If you care to haul out pmdf or the kernel debugger, the code is in
> SYIInitOS2.
>
I think that it's wise for me not to do that.
>> Hale Landis disassembled the FAT VBR years ago.
>>
> BTW, by VBR, do you mean the boot sector or the entire boot loader?
>
The Volume Boot Record. "boot loader" is ambiguous here, since at least
three different things here are loaders. VBR has a specific meaning.
Hale Landis' disassembly of the FAT VBR is still on xyr "How It Works"
WWW site. It's annotated. Xe left producing a similar annotated
disassembly of the HPFS VBR to the reader. As I said, I vaguely recall
that someone did it, but I cannot find any trace either of who or of a
published disassembly.
> I don't have a bootable OS/2 FAT volume, so I can't say anything
> specific about how it determines the boot drive letter.
>
The FAT VBR doesn't do anything with drive letters. It knows nothing of
them whatsoever. And there is, as I said, nothing documented anywhere
to indicate where IBM Boot Manager's secret drive letter handshake is.
It's certainly entirely independent of the VBR code, and it's probably
independent of the FAT and HPFS OS2BOOTs, too, given what the documented
interface to OS2LDR is. It's a location, either on disc or in memory,
that IBM Boot Manager sets up, that is ignored by subsequent stages of
the boot process until either OS2LDR or OS2KRNL is reached, one or both
of which know to go and fish a drive letter out of the location. This
is what had me stumped all of these years, and why I expressed an
interest in this thread back in January. I eliminated registers passing
through the VBRs, and the only things left were some arbitrary location
in RAM (which seemed unlikely, given that the interfaces to both OS2LDR
and OS2KRNL appear to allow for pretty much arbitrary use of memory by
the filesystem-dependent loader stages) and the IBM Boot Manager
configuration data, which IBM Boot Manager is known to overwrite every
time that it loads and runs a VBR.
But also of interest is what the OS/2 kernel does without IBM Boot
Manager setting up a drive letter, because that's what happens on my
system (since I stopped using IBM Boot Manager years ago). There's
definitely an algorithm in there that tries to work out a drive letter
based upon no more than what OS2LDR receives, which is little more than
a NOVOLIO flag, an INT 0x13 drive number, and an in-core BPB structure.
I worked out such an algorithm years ago, and also worked out how
fragile it was, and how often it would produce completely wrong drive
letters. However, such an algorithm requires enumerating the partition
table, which happens in the DMDs. You say that the OS/2 kernel employs
its algorithm before the DMDs initialize. So either the kernel itself
also knows how to read and process partition tables, independently of
OS2DASD.DMD, which is redundant and wasteful, or it's doing something else.
Jonathan de Boyne Pollard
>
> On a NON-LVM system, I don't think any driveletters are stored anyway
> (besides JFS's weird way) - it is always calculated from all existing
> partitions.
>
That's the whole point of this thread. They are. IBM's Boot Manager
works out drive letters. (You can see them on its menu.) It then passes the
drive letter of the boot volume that is selected through a secret,
heretofore undocumented, back-channel to OS2LDR/OS2KRNL.
It has long-since been known that if one boots OS/2 (from a secondary
partition when there are multiple discs, or from a second disc, or when
there are partitions above the 1KiCylinder line that IBM's Boot Manager
isn't seeing) without IBM Boot
Manager, the drive letter for the boot volume is calculated incorrectly,
and OS/2 fails at the point where it has to load the (non-base) device
drivers (because they are specified with drive letters in CONFIG.SYS).
There are discussion forum threads all over the place about this.
There's one, dated September 2003, for the XOSL boot manager, for
example, where a person with this problem came up with the local fix of
having XOSL invoke IBM's Boot Manager, with Boot Manager configured to
immediately boot OS/2.
> This is afaik the way it is done in FreeLDR.
>
From what we've seen of the FreeLDR code, FreeLDR gets the secret
handshake wrong. It sets up the wrong value, in the wrong place, and
then imediately overwrites it anyway. See earlier in this very thread.
I can only surmise that FreeLDR isn't used in earnest by many people,
because my boot manager didn't implement the secret handshake either,
and I encountered this problem almost as soon as I started to use it on
a real system — mine, which has OS/2 installed on a secondary partition
on drive number 0x81. I had to work around it with a combination of
using the /BD switch to DANIDASD.DMD, editing most of the explicit drive
letters out of CONFIG.SYS, and explicitly setting the _BOOT environment
variable to override the implicit value. Even then, anything that
queries the kernel for its idea of the system volume drive letter gets
the wrong answer (one of three wrong answers, in fact, depending from
how exactly I've booted the system) making this local fix
unsatisfactory. People using FreeLDR would have been talking about this
as much as the people using XOSL were (It made the XOSL How-To and
FAQ.), were FreeLDR actually in use.
There's a lot written about how Microsoft's corporate culture is to "eat
its own dog-food", to have the developers of the the softwares that it
makes use those softwares in earnest. I do that, too. I use my own
32-bit Command Interpreter as the default command interpreter, and my
own Command-Line Utilities. My Internet Utilities have been connecting
me to SMTP electronic mail and to the WWW, and providing my
SMTP/DNS/NICNAME/other services, for a number of years. (They've
recently connected me to Usenet. You wouldn't be seeing this post
without them.) I switched my system over to my own boot manager, too.
These wrong drive letter assignments when booting OS/2 from a secondary
partition with my boot manager have annoyed me for a long time. I
suspect that the FreeLDR folks don't eat their own dog food so much. (-:
The even more annoying thing to come out of this discussion is that
obviously some people have some while ago discovered what the secret
handshake is (probably from disassembling IBM's Boot Manager, which I've
never done, thinking it wise not to) but they never actually bothered to
document it themselves. I've documented it, updating my Frequently Given
Answers on the subject, now that I know what it is. (I documented the
other things that boot managers have to do when invoking VBRs, and why,
back in 2006.)
Jonathan de Boyne Pollard
>
> new: Booting OS/2 from extended partition.
>
> -Solution was to update "Special Hidden Sectors" before staring it
> in memory.
>
> -bootQueryLetter - the miniFSD in the LDR (?) needs to know which
> drive letter it is booting from.
>
> This letter is provieded thru the drive number WORD. The high part
> of the word contains the letter number. C=80h, D=81h,... ; 00h=C
>
found out the answer, that I was just talking about. What's written
conveys no information. There is no "drive number WORD". The drive
number has always been a byte value as far as VBRs are concerned, in the
initial DL register value and in the drive number fields of both version
4.0 and 7.0 BPBs. And the list of values isn't right, either.
Ilya Zakharevich
> It has long-since been known that if one boots OS/2 (from a secondary
> partition when there are multiple discs, or from a second disc, or when
> there are partitions above the 1KiCylinder line that IBM's Boot Manager
> isn't seeing) without IBM Boot
> Manager, the drive letter for the boot volume is calculated incorrectly,
> and OS/2 fails at the point where it has to load the (non-base) device
> drivers (because they are specified with drive letters in CONFIG.SYS).
I think the last sentence is BS. The drive letters ARE given, so
there is no point in knowing which one is the bood drive.
IIUC, the failure happens when the "state of FS" structure is passed
from mini-IFS to full-IFS. (But I have absolutely no idea WHY would
one want to pass this information around; all the files are closed at
this moment, and all the CWDs are at root...)
> From what we've seen of the FreeLDR code, FreeLDR gets the secret
> handshake wrong.
Not from what I saw.
> It sets up the wrong value, in the wrong place, and
> then imediately overwrites it anyway. See earlier in this very thread.
It sets byte 2 (counting from LSB) of "current drive" (double)word to
boot_partition - 'a'. If this is assigned to EDX, then DH becomes
initiated to the expected value...
Hope this helps,
Ilya
Valery V. Sedletski
I am the author of FreeLDR. Allan has drawn my attention to this thread
and I have seen that I know answers to some asked questions. First, I
can say that I know "the secret handshake" between bootmanager and OS/2.
I just took Bochs from Dmitry Froloff site (http://froloff.homeip.net)
with compiled-in debugger support, made a hard disk image with IBM
bootmanager and OS/2 partition (primary or logical, no matter). Then it
were easy to compare boot partition's BPB image in memory, loaded by
bootmanager, and on disk. And it appeared that they differ only in three
fields: 1) hiddensectors (a dword @ offset 0x1c) 2) Physical disk number
(a byte @ offset 0x24) 3) logical disk drive letter (a byte @ offset
0x25). So, the BM modifies hiddensectors (when the partition is a
primary one, it is the offset of partition from the beginning of a hard
disk; when partition is logical one, it is equal to sectors per track),
so it is after that is equal to partition offset from the beginning of a
hard disk. Then, bootsector can add this value to a logical sector
number, and it gets absolute (from HDD beginning) LBA of this sector.
This way OS/2 can boot from any partition, and it really doesn't know if
it is primary, logical or not partitioned at all.
The Physical disk number is its BIOS int 13h number. It is 0x80 for 1st
HDD, 0x81 for second. The Logical disk number is 0x80 + (drive_letter -
'C'). So, 0x80 means C: drive.
The boot drive letter is taken from BPB by a miniFSD and then it issues
a MFSH_SETBOOTDRIVE() call. If this drive letter is wrong, then os2dasd
will return an error and OS/2 kernel writes an IPE "OS/2 is unable to
operate....".
Then according the FreeLDR code being analyzed. It really contains some
errors. Jonathan and Ilya meant this piece of code:
[=======================================================]
// Copy BootPart value
ch = (unsigned char)((current_partition >> 8) & 0xff);
if (ch == 0xff) ch = 0;
p = (unsigned char *)BOOTPART_ADDR;
*p = ch;
ldr_drive = current_partition | (ldr_drive << 24);
if (load_segment != -1 && load_offset != -1)
load_addr = (load_segment << 4) + load_offset;
if (!load_addr) load_addr = BOOTSEC_LOCATION;
// Copy kernel
grub_memmove((char *)load_addr, kernel, kernel_len);
[=======================================================]
This code deals with chainloading the MBR. If chainloaded program
(called 'kernel' here) is the HDD MBR, then the BootPart is calculated.
The BootPart is the special field of MBR written by me, which defines
which partition is to be loaded. BootPart value of 0 means that the MBR
must just select a primary partition marked as active in PT. Values 1..4
mean a primary partitions with corresponding number. Values 5... mean
logical partitions. So, this code calculates which partition is needed
to be loaded by MBR. So, it is a special support for my MBR. It is
really erased by subsequent memmove, as Jonathan noted. This is just
because this piece of code is unfinished and it is my fault. Really
these pieces must be swapped.
But this error does not affect successful loading of OS/2 bootsector.
There is a boot script which chainloads OS/2 bootsector:
[=======================================================]
title Load a bootsector of OS/2 partition (I13X)
kernel ()\boot\loader\chain.mdl --bootdev=$(dsk) --i13x
bsmodule $(dsk)0+1
[=======================================================]
The parentheses in front of a path means a macro meaning the bootloader
drive/partition, (hd0,0) for example. This is determined automatically.
The --bootdev= parameter sets current drive and current partition
variables and current drive is copied to dl register. The --i13x flag
means that the chainloader must set I13X flag at 0x3000:0x0. This is
usually set by OS/2 bootmanager and then the MBR, bootsector, os2ldr
etc. rely on this to not each time check int 13h extensions presence.
The bsmodule command is a special kind of module command from GRUB which
not only loads a special kind of module -- the bootsector, but also
modifies the three magic BPB values. So, Ilya just has find "the secret
handshake" in wrong place. You should look into
osfree\trunk\bootseq\loader\loader\commands.c, function bsmodule_func()
which calls create_bs_module() from boot.c in the same directory.
PS: I did not tested chain.mdl with GRUB and to successfully load OS/2
the main thing is bsmodule command which is missing in GRUB. So,
unfortunately, this won't work.
But to load OS/2 from GRUB, I have a better solution, bootos2.mdl. Like
chain.mdl, it is a multiboot kernel too and could be loaded from FreeLDR
as well as GRUB (it was successfully tested with GRUB and GRUB4DOS) by
'kernel' command. So, bootos2.mdl with parameters is specified as a
multiboot kerenl, and other OS/2 files (config.sys, os2ldr, os2krnl,
BASEDEV's, etc) which are loaded by microfsd and minifsd.
Bootos2 is called the OS/2 booter. It contains a pair of special
microfsd and minifsd for multiboot info. I.e., the bootloader (GRUB or
FreeLDR or any multiboot loader) loads OS/2 files in memory as modules
and passes the mbi (multiboot info) structure to bootos2. Each file has
its starting and ending addresses, and a string associated with it ('a
command line'). From its command line we could know its path. So, when
os2ldr or os2krnl ask to open a file, it is searched in multiboot info
and then read() function is implemented as a simple memmove(). So,
special kinds of microfsd and minifsd designed for mbi 'filesystem',
retrieve all files from mbi and give it to os2ldr and os2krnl.
As a result, I can use FreeLDR FS support to load files from FS to
memory (all FS-es taken from GRUB are supported, and I wrote hpfs
support myself and fixed an error in GRUB's JFS support). So, FreeLDR
can boot OS/2 from isofs, hpfs, jfs, fat12/16/32 and some more exotic
FS-es. Then it gets loaded into mbi structure, and bootos2 starts.
bootos2 serves os2ldr and os2krnl requests for loading files, until the
boot IFS starts. Then bootos2 passes control to the boot IFS and OS/2
boots as usual.
So far, I tested bootos2 with the following IFS'es: hpfs, jfs, fat32,
vfat-os2, ext2-os2; cdfs.ifs is partly working (need to fix
os2dasd/os2cdrom, without that I get an "OS/2 is unable to operate..."
error when trying to set CDROM drive letter as a boot drive :().
And I successfully boot OS/2 from flash disk. Unfortunately, only
danidasd can assign a drive letter through /BD command in config.sys;
dasd32/os2lvm cannot do that. Also I made a special support for danidasd
in bootos2 to automatically assign a correct drive letted and to not
each time change /BD:N parameter in config.sys on different machines.
Also, I even made a memdisk-like technology using ramfs.ifs: bootos2
serves all boot files as usual and creates the ramdisk, copies all files
to it from mbi structure, and then passes control to ramfs.ifs. It is
just a roundabout way to boot OS/2 from a CDROM and not to get a famous
"OS/2 is unable to operate.." error.
So, it is very promising technology for booting OS/2, especially from
flash and CD. You can try it to boot OS/2 via GRUB. But unfortunately,
docs are not ready yet. Some are available at http://www.osfree.org in
our wiki. Anyway, you can contact me and I will help you to setup all
the steps.
WBR,
Valery.
Steven Levine
<_vale...@mail.ru> wrote:
Hi Valery,
Your explanation matches my understanding of how this all works.
> The boot drive letter is taken from BPB by a miniFSD and then it issues
> a MFSH_SETBOOTDRIVE() call. If this drive letter is wrong, then os2dasd
> will return an error and OS/2 kernel writes an IPE "OS/2 is unable to
> operate....".
What filesystem did you test? The reason I asked is that I have not
yet found a MFSH_SETBOOTDRIVE() call in the HPFS OS2BOOT. Did you
actually see the call occur?
Thanks,
Valery V. Sedletski
> On Sat, 3 Apr 2010 13:00:01 UTC, "Valery V. Sedletski"
> <_vale...@mail.ru> wrote:
>
> Hi Valery,
>
> Your explanation matches my understanding of how this all works.
>
>
>>The boot drive letter is taken from BPB by a miniFSD and then it issues
>>a MFSH_SETBOOTDRIVE() call. If this drive letter is wrong, then os2dasd
>>will return an error and OS/2 kernel writes an IPE "OS/2 is unable to
>>operate....".
>
>
> What filesystem did you test? The reason I asked is that I have not
> yet found a MFSH_SETBOOTDRIVE() call in the HPFS OS2BOOT. Did you
> actually see the call occur?
>
> Thanks,
>
> Steven
>
Yes, I saw MFSH_SETBOOTDRIVE usage in bootJFS and ext2_os2 sources -- it
is called at the end of MFS_INIT rountine of a minifsd. In HPFS
minifsd really there is no MFSH_SETBOOTDRIVE occurence. Maybe, it is set
directly via Global Info Seg bootdrive variable access...
WBR,
Valery
Jonathan de Boyne Pollard
>>
>> It has long-since been known that if one boots OS/2 (from a secondary
>> partition when there are multiple discs, or from a second disc, or
>> when there are partitions above the 1KiCylinder line that IBM's Boot
>> Manager isn't seeing) without IBM Boot Manager, the drive letter for
>> the boot volume is calculated incorrectly, and OS/2 fails at the
>> point where it has to load the (non-base) device drivers (because
>> they are specified with drive letters in CONFIG.SYS).
>>
> I think the last sentence is BS.
>
modes that I've had over the years because of this secret handshake. It
doesn't fail when it comes to load the basedevs. That happens when one
changes the drive letters in CONFIG.SYS to match the OS/2 boot drive
letter. (-: Without that change, the problems come later than the
device drivers. They come when the bootstrap process reaches the first
utility program, daemon, or other application that explicitly asks OS/2
for the boot drive letter, so that it can find its configuration or data
files. Depending from whether the drive letter that OS/2 has
incorrectly worked out even exists, or is formatted with a filesystem
format that OS/2 comprehends, this can result in a hardware error
pop-up. Bad luck in that case if one has a daemon that is automatically
re-started whenever it fails. (-:
>> From what we've seen of the FreeLDR code, FreeLDR gets the secret
>> handshake wrong.
>>
> Not from what I saw.
>
Read the response to this very post of yours. (-:
>> It sets up the wrong value, in the wrong place, and then imediately
>> overwrites it anyway. See earlier in this very thread.
>>
> It sets byte 2 (counting from LSB) of "current drive" (double)word to
> boot_partition - 'a'. If this is assigned to EDX, then DH becomes
> initiated to the expected value...
>
That's the wrong value, in the wrong place. I sent to you a pointer to
what the right values are and the right place to put them, 24 hours
ago. I know that it's the right value in the right place, because as
soon as I found out, I implemented it in my boot manager and tested it
with various drive letter values. At one point I had OS/2 thinking that
'Q' was my system volume's drive letter. OS/2 is now reporting the
correct drive letter for the system volume for the first time in years.
Jonathan de Boyne Pollard
>
> What filesystem did you test? The reason I asked is that I have not
> yet found a MFSH_SETBOOTDRIVE() call in the HPFS OS2BOOT.
>
thought to be necessary. Think about it from the designer's
perspective. Either IBM's Boot Manager looks at the partition table and
works out a drive letter, or the OS/2 kernel looks at the partition
table and works out a drive letter. The only reason that one would want
to do it onesself would be for a filesystem that neither IBM's Boot
Manager nor the OS/2 kernel would take into account, like NTFS, EXT2, or
JFS, or for something that isn't a local voume at all. If you look at
the documentation for the function, you'll see it described as something
that is called when one is IPLing from a remote filesystem. That was
the expected use.
Ilya Zakharevich
Thanks for a patient explanation of what you found out, and for your
efforts in developing freeLDR.
> But to load OS/2 from GRUB, I have a better solution, bootos2.mdl. Like
> chain.mdl, it is a multiboot kernel too and could be loaded from FreeLDR
> as well as GRUB (it was successfully tested with GRUB and GRUB4DOS) by
> 'kernel' command. So, bootos2.mdl with parameters is specified as a
> multiboot kerenl, and other OS/2 files (config.sys, os2ldr, os2krnl,
> BASEDEV's, etc) which are loaded by microfsd and minifsd.
It is a wonderful beast, but it is also a major maintainance nightmare...
One needs to meticulously match the contents of one file (config.sys)
with contents of another file (os2.cfg). This asks for trouble. And
there is also another matter: some files "are just flags" (like
altf2on.$$$); so I do not see how bootos2.mdl can manage to provide
the user with meaningful error reports... So one must live with error
reports from os2ldr...
Moreover, some files to load are not mentioned in config.sys at all;
so I do not think it is feasible to auto-parse config.sys; e.g., can
basedev's load other dependent file?
Yours,
Ilya
Valery V. Sedletski
> On 2010-04-03, Valery V. Sedletski <_vale...@mail.ru> wrote:
>
> Thanks for a patient explanation of what you found out, and for your
> efforts in developing freeLDR.
>
>
>>But to load OS/2 from GRUB, I have a better solution, bootos2.mdl. Like
>>chain.mdl, it is a multiboot kernel too and could be loaded from FreeLDR
>>as well as GRUB (it was successfully tested with GRUB and GRUB4DOS) by
>>'kernel' command. So, bootos2.mdl with parameters is specified as a
>>multiboot kerenl, and other OS/2 files (config.sys, os2ldr, os2krnl,
>>BASEDEV's, etc) which are loaded by microfsd and minifsd.
>
>
> It is a wonderful beast, but it is also a major maintainance nightmare...
>
> One needs to meticulously match the contents of one file (config.sys)
> with contents of another file (os2.cfg). This asks for trouble.
Yes, you should manually edit os2.cfg and the same file is often doubled
in two places: config.sys and os2.cfg. It is not very good but probably
there is no better solution here. Though, I made '--auto-preload' mode,
when bootos2 parses config.sys and uses some heuristics to determine
which files it must preload, and does it automatically. The disadvantage
is that it cannot guess dependencies and files not specified in config.sys
> And
> there is also another matter: some files "are just flags" (like
> altf2on.$$$);
flag files must be also specified as boot modules, so they are taken
into account
> so I do not see how bootos2.mdl can manage to provide
> the user with meaningful error reports... So one must live with error
> reports from os2ldr...
>
> Moreover, some files to load are not mentioned in config.sys at all;
> so I do not think it is feasible to auto-parse config.sys; e.g., can
> basedev's load other dependent file?
>
yes, it is a weak place. But instead, you get more flexibility and the
universal mini- and microfsd which can be used with almost any IFS. The
only needed thing is existing support for that filesystem in FreeLDR
microfsd's. Also, it is possible to create a bootable CD's without the
need in floppy images or memdisk -- in no emulation mode, and all files
are loaded directly from CD. The possiblility to make bootable CDROM's
and flash disks makes it unique. The files which cannot be determined
from config.sys or dependencies are very rare cases. And yes, it is
intended for advanced users which know and understand OS/2 booting
principles. For novice users a system administrator or distribution
preparer can prepare all needed configs. Of course, I am trying to make
it more easy to use, but it is difficult.
Ilya Zakharevich
Hmm, what about just loading ALL files in x:/os2/boot?
Ilya
Steven Levine
<_vale...@mail.ru> wrote:
Hi Valery,
>it is called at the end of MFS_INIT rountine of a minifsd.
I know the jfs code. FWIW, I just fixed the minifsd to protect itself
against non-bootable versions ujfs.dll. Chkdsk wipes out the boot
driver letter.
>In HPFS
> minifsd really there is no MFSH_SETBOOTDRIVE occurence. Maybe, it is set
> directly via Global Info Seg bootdrive variable access...
Perhaps, although I've found not code that looks like it is doing
this. I may have to install bochs here and watch the code run.
Marty
>> On a NON-LVM system, I don't think any driveletters are stored anyway
>> (besides JFS's weird way) - it is always calculated from all existing
>> partitions.
>>
> That's the whole point of this thread. They are. IBM's Boot Manager
> works out drive letters. (You can see them on its menu.) It then passes
> the drive letter of the boot volume that is selected through a secret,
> heretofore undocumented, back-channel to OS2LDR/OS2KRNL.
Are you sure it's just not calculated from scratch in both? In fact, I
had a situation in the pre-LVM days where it was calculated differently.
Boot manager claimed it was one drive letter, but when OS/2 booted, it
was different. The system didn't live very long in that state, needless
to say.
> It has long-since been known that if one boots OS/2 (from a secondary
> partition when there are multiple discs, or from a second disc, or when
> there are partitions above the 1KiCylinder line that IBM's Boot Manager
> isn't seeing) without IBM Boot Manager, the drive letter for the boot
> volume is calculated incorrectly, and OS/2 fails at the point where it
> has to load the (non-base) device drivers (because they are specified
> with drive letters in CONFIG.SYS).
"The system cannot operate the drive" or some such thing results
downstream. Sounds like what I saw.
--
[Reverse the parts of the e-mail address to reply.]
Valery V. Sedletski
It is possible. But 1) not all files are loaded from \os2\boot 2) they
weight too much. FreeLDR loads all files at addresses above 4 Mb and
below 16 Mb. So, not much place is available for these files. I tried to
load them above 16 Mb, but it seems the OS/2 kernel is zeroing-out all
memory except first 16 Mb. (I could move all files to safe place and cut
it off from memory map, like memdisk does, but I made so for the first
time). So, load ALL files from \os2\boot 1) would be costly 2) it is not
a complete solution because some files are needed which are not in \os2\boot
Jonathan de Boyne Pollard
>>
>> IBM's Boot Manager works out drive letters. (You can see them on its
>> menu.) It then passes the drive letter of the boot volume that is
>> selected through a secret, heretofore undocumented, back-channel to
>> OS2LDR/OS2KRNL.
>>
> Are you sure it's just not calculated from scratch in both?
>
been revealed. (-:
> In fact, I had a situation in the pre-LVM days where it was calculated
> differently. Boot manager claimed it was one drive letter, but when
> OS/2 booted, it was different. The system didn't live very long in
> that state, needless to say.
>
You're probably thinking of something different yet again. This isn't
the drive letter as assigned by OS/2 to the system volume, when it
mounts volumes, that we're talking about. This is the system volume
drive letter reported by the OS/2 kernel to applications that ask. It's
what you'll see if you crank up the 32-bit Command Interpreter and run
the command
ECHO %_BOOT%
The symptoms that you're describing result from the OS/2 kernel and
IBM's Boot Manager seeing a different view of the partition table,
usually the result of the 1024 cylinder problem, drives available in
OS/2 proper that are not available at the INT 0x13 interface, or
firmware playing tricks at the INT 0x13 interface. The symptoms that
I'm talking about, and have finally stopped experiencing after years,
result from the system volume drive letter being calculated incorrectly.
The system volume drive letter is
(a) whatever the drive letter of the selected partition is, in the view
of IBM's Boot Manager, as passed down via the secret handshake;
(b) whatever the OS/2 kernel works out by the process alluded to by M.
Levine, that apparently occurs before DMDs and IFSes are initialized; or
(c) whatever a mini-FSD specifies to the OS/2 kernel by calling the
MSFH_SETBOOTDRIVE() function.
And here's how it can go wrong:
I have OS/2 installed on a secondary partition on drive 0x81, and
partitions on both drives 0x80 and 0x81 that are above the 1KiCylinder
boundary. IBM Boot Manager is installed, but it isn't the flavour that
knows about the INT 0x13 extensions. When OS/2 is booted, the drive
letter that is assigned to the system volume, as mounted, is 'H', and
has been all along. However, until a couple of days ago the following
behaviour occurred with respect to the system drive letter reported by
OS/2 to applications:
* When booted via IBM Boot Manager, which is in the active primary
partition on drive 0x80, the system drive letter reported by OS/2 was
'G'. This was because IBM Boot Manager only saw the partitions that
were below the 1KiCylinder line, and calculated 'G' as the drive letter
of the OS/2 system volume. It's what it displays on its menu. It
passed this value via the secret handshake to the OS/2 kernel when
bootstrapping the volume that it thought to be 'G'. That overrode
everything else.
* When booted via my boot manager, from a floppy disc on drive 0x00, the
system drive letter reported by OS/2 was 'D'. This was because the
secret handshake wasn't being used. The OS/2 kernel was falling back to
calculating the system volume drive letter itself. Whatever algorithm
it was using comes up with 'D' as the answer.
* When booted via my boot manager, which is in the active primary
partion on drive 0x81, the system drive letter reported by OS/2 was
'C'. This was again because the secret handshake wasn't being used.
The OS/2 kernel was again using its own algorithm to work out the drive
letter. But the machine firmware plays tricks at the INT 0x13 interface
when you tell it to boot from drive 0x81. Drives 0x80 and 0x81 are
magically swapped around. So the OS/2 kernel was seeing the drives as
if they had been swapped, and the result of its algorithm was thus a
different drive letter.
Hence the reason that I was quite sure that IBM Boot Manager had a
secret handshake with the OS/2 kernel, even though it wasn't documented
anywhere. Booting via IBM's Boot Manager, keeping all other variables
the same, yielded different behavior for the system volume drive letter.
Notice that at no point was anything actually getting the system volume
drive letter right. No method of booting was actually ending up with
'H' as the system volume drive letter reported by the OS/2 kernel to
applications, even though that was actually the drive letter of the
system volume.
The algorithm employed by the OS/2 kernel is a mystery, because there's
no logical way of enumerating the partitions on the system, that I can
see, that comes up with 'D' as the letter for this particular partition
in the unswapped case, and 'C' in the swapped case. It's actually the
fourth partition on drive 0x81 (unswapped) or 0x80 (swapped). The only
hypothesis that makes any sense is that the OS/2 kernel, in the absence
of any secret handshake or a MFSH_SETBOOTDRIVE() call, does the utterly
mad thing of thinking that there's only one volume per drive, and that
therefore its algorithm is the far too simplistic "0x80 is 'C', 0x81 is
'D', 0x82 is 'E' ...".
The problems experienced as a result of this behaviour are varied.
There are various programs that internally query the system volume drive
letter in order to construct pathnames for data and configuration files
on the system volume, for example; and I have various command scripts
and run files that are parameterized in terms of %_BOOT%. They were all
variously looking on 'C', 'D', or 'G', instead of 'H'.
These problems have mostly gone away, now. But even now, ERLOGGER is
still insisting upon using C:\OS2\SYSTEM\RAS\LOG001.DAT ...
Ilya Zakharevich
>> Hmm, what about just loading ALL files in x:/os2/boot?
> It is possible. But 1) not all files are loaded from \os2\boot
Ambiguous. If you mean there are files not from \os2\boot - just move
them there. If you mean that some files from \os2\boot are not
loaded, just move them to a subdirectory. ;-) Oh, below I see you
meant the first case...
[Somehow maintaining "a sane directory structure" looks MUCH less
intimidating to me than maintaining "a sane list of files in
os2.cfg"... Do not know why...]
> 2) they weight too much.
Irrelevant if you MUST load all of them.
> time). So, load ALL files from \os2\boot 1) would be costly 2) it is not
> a complete solution because some files are needed which are not in \os2\boot
Yours,
Ilya
Valery V. Sedletski
> On 2010-04-04, Valery V. Sedletski <_vale...@mail.ru> wrote:
>
>>>Hmm, what about just loading ALL files in x:/os2/boot?
>
>
>>It is possible. But 1) not all files are loaded from \os2\boot
>
>
> Ambiguous. If you mean there are files not from \os2\boot - just move
> them there. If you mean that some files from \os2\boot are not
> loaded, just move them to a subdirectory. ;-) Oh, below I see you
> meant the first case...
>
> [Somehow maintaining "a sane directory structure" looks MUCH less
> intimidating to me than maintaining "a sane list of files in
> os2.cfg"... Do not know why...]
>
>
No, I already thought of it -- to keep all files in archives, like in
memdisk -- I don't like it. Changing a directory structure is a bad idea
-- better leave it as is. And move files to an archive/subdirectory
isn't easier then just change paths in os2.cfg.
Ilya Zakharevich
>> [Somehow maintaining "a sane directory structure" looks MUCH less
>> intimidating to me than maintaining "a sane list of files in
>> os2.cfg"... Do not know why...]
> No, I already thought of it -- to keep all files in archives, like in
> memdisk -- I don't like it. Changing a directory structure is a bad idea
> -- better leave it as is. And move files to an archive/subdirectory
> isn't easier then just change paths in os2.cfg.
??? Of course it is tons easier... Just think what happens if you
make a misprint... (E.g., typed a Cyrillic `er' instead of Latin `p'
--- 1/2 ;-).
Yours,
Ilya
Valery V. Sedletski
Yes, it is an advantage that it is harder to make a mistype when
changing directory structure. But the idea of changing it is bad, I
think. Because there are standard ways of placing files in directories
and it is better to use these standards.
Also, not only os2\boot\ is to be loaded, there is a number of dlls in
os2\dll\ too, and placing dll's in os2\boot\ is not a good idea. Or, if
not to os2\boot\, but if place them to separate directory, like
os2\preload\ then we must make copies of all needed files there, so we
will also need to keep the same versions in original location and in
preload dir. As OS/2 has not symlinks, this will always cause problems.
And the same if not to make a directory structure, but to pack all files
in archive.
Allan
> On Sat, 3 Apr 2010 15:20:20 UTC, "Valery V. Sedletski"
> <_vale...@mail.ru> wrote:
>
> Hi Valery,
>
> >it is called at the end of MFS_INIT rountine of a minifsd.
>
> I know the jfs code. FWIW, I just fixed the minifsd to protect itself
> against non-bootable versions ujfs.dll. Chkdsk wipes out the boot
> driver letter.
Nice - did you make it read driveletter from DLAT instead ?
Did you fix the nasty rewrite of bootblock of too ?
I know that will only work for eCS2.0 - and not the old versions,
but it is still very important to FreeLDR, that we get that fixed.
--
Allan.
It is better to close your mouth, and look like a fool,
than to open it, and remove all doubt.
Steven Levine
wrote:
Hi Allen,
> Nice - did you make it read driveletter from DLAT instead ?
Not yet. Possibly after 2.0. I have not yet been convinced it it
required. Note that using the DLAT drive letter is not a perfect
solution. If the DLAT recommended drive letter is in use, LVM will
assign a different drive letter.
> Did you fix the nasty rewrite of bootblock of too ?
I've not really decided how to handle this generically. For
historical reasons, the boot sector and the boot loader are tied at
the hip. Fixing ticket #2626 requires that this not change.
However, rather than blindly rewriting the boot sector and boot
loader, I do plan to implement read/verify/write logic. This will
allow SSD devices to live a bit longer.
FWIW, it appears that the JFS boot code was modeled after the HPFS
boot code and the HPFS boot code seems to behave similarly.
> I know that will only work for eCS2.0 - and not the old versions,
> but it is still very important to FreeLDR, that we get that fixed.
I will talk with the FreeLDR developer when the time comes. I am open
to adding command line options to suppress the boot sector updates.
Allan
> On Wed, 7 Apr 2010 00:16:08 UTC, "Allan" <all...@warpspeed.dyndns.dk>
> wrote:
>
> Hi Allen,
>
> > Nice - did you make it read driveletter from DLAT instead ?
>
> Not yet. Possibly after 2.0. I have not yet been convinced it it
> required. Note that using the DLAT drive letter is not a perfect
> solution. If the DLAT recommended drive letter is in use, LVM will
> assign a different drive letter.
Hmm, how can it possible be in use ? At boot time, this will be the
first driveletter ever known in use for the system.
Anyway - where do FAT or HPFS boots get their driveletter from,
if not from DLAT ?
> > Did you fix the nasty rewrite of bootblock of too ?
>
> I've not really decided how to handle this generically. For
> historical reasons, the boot sector and the boot loader are tied at
> the hip. Fixing ticket #2626 requires that this not change.
Reading driveletter from DLAT instead of bootsector will fix
#2626 too,
> However, rather than blindly rewriting the boot sector and boot
> loader, I do plan to implement read/verify/write logic. This will
> allow SSD devices to live a bit longer.
>
> FWIW, it appears that the JFS boot code was modeled after the HPFS
> boot code and the HPFS boot code seems to behave similarly.
No, it doesn't. I have had FreeLDR installed on FAT, FAT32, HPFS and
JFS - and it boots fine from all with its own miniIFS in bootblock - but
JFS is the only IFS which immidiately destroys it again on first boot,
because the chkdsk done during boot overwrites the bootsector/block.
None of the other IFS do _ever_ write into bootsector or bootblock
during a chkdsk - they only do this when using SYSINSTX .
> > I know that will only work for eCS2.0 - and not the old versions,
> > but it is still very important to FreeLDR, that we get that fixed.
>
> I will talk with the FreeLDR developer when the time comes. I am open
> to adding command line options to suppress the boot sector updates.
As far as I can see, there is no good reason to do these updates
during every chkdsk - since no other IFS does it.
btw - if I want to boot on JFS on my SCSI servers, I have to use FreeLDR,
since the eCS version doesn't work, so it is a rather annoying problem.
Jonathan de Boyne Pollard
>
> As far as I can see, there is no good reason to do these updates
>
That's not entirely true. Although for most filesystem formats the data
and code in the VBR are essentially static with respect to CHKDSK, there
is at least one BPB field where this isn't so: the CHKDSK flags field.
This field isn't recognized by OS/2 FSDs and filesystem utilities, but
on Windows NT you'd certainly see CHKDSK and FSDs rewriting the VBR, to
set and unset these flags.
But I agree with you that there's no need for CHKDSK to be rewriting VBR
code; and that that's properly the domain of SYS, not CHKDSK. The OS/2
CHKDSK IFS utility DLLS for FAT and HPFS don't rewrite VBR code. Doing
so would be daft. What business has CHKDSK in dictating what operating
system is installed on any given bootable volume?
Felix Miata
> my boot manager
Are you keeping the meaning of this a secret? I think I've read this whole
thread. I've asked Google 'jonathan pollard boot manager', and scanned
http://homepage.ntlworld.com/jonathan.deboynepollard/. I still don't know
what "my boot manager' refers too. :-(
BTW, your "TAU" link is 404.
--
"Suppos [sic] a nation in some distant region, should
take the Bible for their only law book, and every member
should regulate his conduct by the precepts there
exhibited. . . . What a Eutopa, What a paradise would
this region be!" John Adams, 2nd US President
Team OS/2 ** Reg. Linux User #211409
Felix Miata *** http://fm.no-ip.com/
Jonathan de Boyne Pollard
>>
>> my boot manager
>>
> Are you keeping the meaning of this a secret? I think I've read this
> whole thread. I've asked Google 'jonathan pollard boot manager', and
> scanned http://homepage.ntlworld.com/jonathan.deboynepollard/. I still
> don't know what "my boot manager' refers too. :-(
>
I wrote one. It's mine. It's my boot manager. I do tend to write
about it under my own name, as in the From: header of this very message,
which might be part of the problem that you are having with Google. (-:
It is, however, not released. The blurb and documentation are on a
temporary WWW site, whose URL I'm not going to spread around on Usenet;
for the very simple reason that doing so would curse whoever gets the IP
address lease in years to come with having to suffer bogus HTTP request
traffic from the world at large, as a broken hyperlink is archived all
over the WWW forevermore. I've just sent the URL to you through the
mail. (Don't post it!) Read your mail.
(Mike Luther, if you are reading this, read your mail, too. I sent
something to you last month. It's probably still languishing in some
unread inbox somewhere.)
> BTW, your "TAU" link is 404.
>
I know.