W4 Installation hangs at first boot-up from HD

[Wolfi]

I finally managed to get a set of W4 installation diskettes together, that run
all through to the very end and are still accepted by the installer as valid
OS version.
Unfortunately though, as soon as the system is booting up from HD for the
first time to continue with the installation, I get the following error:

04-22-2007 13:26:52 SYS3175 PID 0002 TID 0001 Slot 0007
F:\OS2\PMSHELL.EXE
c0000005
1fec7998
P1=00000001 P2=00000000 P3=XXXXXXXX P4=XXXXXXXX
EAX=00000000 EBX=17f17f90 ECX=00000000 EDX=00000000
ESI=00000000 EDI=00000101
DS=0053 DSACC=d0f3 DSLIM=1fffffff
ES=0053 ESACC=d0f3 ESLIM=1fffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:1fec7998 CSACC=d0df CSLIM=1fffffff
SS:ESP=0053:0004f9d8 SSACC=d0f3 SSLIM=1fffffff
EBP=0004f9e8 FLG=00012246

PMMERGE.DLL 0004:00137998


I googled around for quite some time now in the NGs, but unfortunately didn't
find anything matching close enough.

My installation diskettes now are at FP12 level, whereas most *.add, *.ifs,
*.dmd and some *.sys, as well as ibmidecd.flt are on a later level (2002-'06).

Anybody having any ideas about where/what the culprit might be?

[Bob Eager]

Post by Wolfi
I finally managed to get a set of W4 installation diskettes together, that run
all through to the very end and are still accepted by the installer as valid
OS version.
Unfortunately though, as soon as the system is booting up from HD for the

On the diskettes, in CONFIG.SYS, do you have:

SET COPYFROMFLOPPY=1

? Because if not, the hard drive is getting copies of files off the CD,
which will be backlevel from those on the diskettes.

[Wolfi]

Post by Bob Eager

Post by Wolfi
I finally managed to get a set of W4 installation diskettes together, that run
all through to the very end and are still accepted by the installer as valid
OS version.
Unfortunately though, as soon as the system is booting up from HD for the

SET COPYFROMFLOPPY=1
? Because if not, the hard drive is getting copies of files off the CD,
which will be backlevel from those on the diskettes.

I surely do ;-)

lxlite <filename> /W- /N+ /Vm showed:

└ Processing file PMMERGE.DLL
├ Imported Modules Table
├ Index ┬ Offs ┬ Name ────────
│ 00001 │ 00000 │ PMGPI
│ 00002 │ 00006 │ PMVIOP
│ 00003 │ 00013 │ DOSCALLS
│ 00004 │ 00022 │ SOFTDRAW
│ 00005 │ 00031 │ FFST
│ 00006 │ 00036 │ PMGRE
│ 00007 │ 00042 │ PMWIN
│ 00008 │ 00048 │ MOUCALLS
│ 00009 │ 00057 │ VIOCALLS
│ 00010 │ 00066 │ NLS
│ 00011 │ 00070 │ PMSHAPI
│ 00012 │ 00078 │ SESMGR
│ 00013 │ 00085 │ QUECALLS
│ 00014 │ 00094 │ UCONV
├ 00015 ┴ 00100 ┴ MSG

└ Processing file PMSHELL.EXE ├
├ Imported Modules Table
├ Index ┬ Offs ┬ Name ─────────
│ 00001 │ 00000 │ PMWP
│ 00002 │ 00005 │ PMMERGE
│ 00003 │ 00013 │ DOSCALLS
├ 00004 ┴ 00022 ┴ PMWIN

so I might need to backlevel the FP12 DLLs
viocalls.dll, doscall1.dll, quecalls.dll, sesmgr.dll
to the original W4 level.
Newer mouse.sys and pointdd.sys shouldn't cause a problem only that late,
should they?

[My Name]

Post by Wolfi
so I might need to backlevel the FP12 DLLs
viocalls.dll, doscall1.dll, quecalls.dll, sesmgr.dll
to the original W4 level.
Newer mouse.sys and pointdd.sys shouldn't cause a problem only that
late, should they?

The only one that might be a problem is DOSCALL1.DLL. It needs to be in
sync with the DOSCALLS.DLL file that is located with the OS/2 kernel, in
the OS2KRNL file. And therefore the PMMERGE.DLL should also be from the
same fixpack.

The other files that you mention are all "empty" files that just point a
program to the DOSCALLS located within the OS2KRNL file. Those files
remain the same, AFAIK.

Device Drivers such as MOUSE.SYS, POINTDD.SYS, APM.SYS, should be
compatible with all versions of OS/2 Warp 3.0 or later.

But, note that some of those driver files do not compress with LXLite
properly, because they have exports that LXLite does not treat properly.
Off the top of my head, such files are: CLOCK01.SYS, MOUSE.SYS, etc.
Those problem files do compress perfectly with NELite however. DOSDD.SYS
works best if only compressed with NELite, not LXLite. In fact it will
be smaller if compressed with NELite than with LXLite.

PMMERGE.DLL is an important core system file, than has not yet been
perfected. Be sure that you are using the most recent version for OS/2
Warp 4.0. Your error message indicates that OS/2 is having trouble
finding something in the PMMERGE's code. You can help it (a little bit),
by expanding it larger in size and then compressing it. Most problem
files need to have this done at least twice (LXLite compresses it
differently each time, until it finally stops changing the file, with a
second or third compression. Just my experience.

[Wolfi]

Post by My Name

Post by Wolfi
so I might need to backlevel the FP12 DLLs
viocalls.dll, doscall1.dll, quecalls.dll, sesmgr.dll
to the original W4 level.
Newer mouse.sys and pointdd.sys shouldn't cause a problem only that
late, should they?

The only one that might be a problem is DOSCALL1.DLL. It needs to be in
sync with the DOSCALLS.DLL file that is located with the OS/2 kernel, in
the OS2KRNL file. And therefore the PMMERGE.DLL should also be from the
same fixpack.

Well, now you're loosing me :-\
I cannot find a DOSCALLS.DLL anywhere on my FP16+ box and I've never seen one
coming with one of Scott's kernel updates.

Among others, I had os2krnl, CMD.EXE and DOSCALL1.DLL all from FP12 on my
floppies, but apparently as soon as the WPS should be brought up, PMMERGE.DLL
from the installation CD doesn't like that latter one at all.
And from what I found out in the meantime, CMD.EXE and DOSCALL1.DLL must also
match, but unfortunately syncing those three still isn't enough.

With CMD.EXE and DOSCALL1.DLL being from the W4 CD again on my Disk2, the
installer now is already having trouble as soon as it tries to work from
within Disk3 on the CD:

04-23-2007 09:03:23 SYS3175 PID 000c TID 0001 Slot 0014
G:\OS2IMAGE\DISK_3\STRTSWAP.EXE
c0000005
0001063c
P1=00000001 P2=00000010 P3=XXXXXXXX P4=XXXXXXXX
EAX=00020208 EBX=00000000 ECX=00000000 EDX=00000000
ESI=00000000 EDI=00000000
DS=0053 DSACC=d0f3 DSLIM=1fffffff
ES=0053 ESACC=d0f3 ESLIM=1fffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:0001063c CSACC=d0df CSLIM=1fffffff
SS:ESP=0053:00028810 SSACC=d0f3 SSLIM=1fffffff
EBP=00028824 FLG=00012202

STRTSWAP.EXE 0001:0000063c
------------------------------------------------------------
04-23-2007 09:20:24 SYS3175 PID 000d TID 0001 Slot 0014
G:\OS2IMAGE\DISK_3\GETCFG.EXE
c0000005
00010778
P1=00000001 P2=00000010 P3=XXXXXXXX P4=XXXXXXXX
EAX=000202a8 EBX=00000000 ECX=00000000 EDX=00000000
ESI=00000000 EDI=00000000
DS=0053 DSACC=d0f3 DSLIM=1fffffff
ES=0053 ESACC=d0f3 ESLIM=1fffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:00010778 CSACC=d0df CSLIM=1fffffff
SS:ESP=0053:00028b60 SSACC=d0f3 SSLIM=1fffffff
EBP=00028b74 FLG=00012206

GETCFG.EXE 0001:00000778

This is really one huge mess.
So far I haven't compressed anything with LxLite other than the larger *.EXE
on DISK2. I cannot even use Dani's compact, already compressed DaniS506.add
w/o having trouble, it has to be an uncompressed one to work.

[Paul Ratcliffe]

Post by Wolfi

Post by My Name
The only one that might be a problem is DOSCALL1.DLL. It needs to be in
sync with the DOSCALLS.DLL file that is located with the OS/2 kernel, in
the OS2KRNL file. And therefore the PMMERGE.DLL should also be from the
same fixpack.

Well, now you're loosing me :-\
I cannot find a DOSCALLS.DLL anywhere on my FP16+ box and I've never seen one
coming with one of Scott's kernel updates.

There is no such file. For want of a better phrase, the entry points are
built in to the kernel.

[My Name]

Post by Wolfi
Well, now you're loosing me :-\
I cannot find a DOSCALLS.DLL anywhere on my FP16+ box and I've never
seen one coming with one of Scott's kernel updates.

Oooh, so sorry. I did not type-out my sentence correctly for you to
understand. What I should have written was:

The only one that might be a problem is DOSCALL1.DLL. It needs to be
in sync with the

DOSCALLS.DLL file that is (secretly) located *within* the OS/2 kernel,
in the OS2KRNL file.

And therefore the PMMERGE.DLL should also be from the same fixpack.

In other words, the the OS2KRNL file (the kernel file) becomes known as
DOSCALLS.DLL file in the computer's memory. But, they don't have to
been. The IBM Testcase website used to offer updated/corrected OS2KRNL
files, (along with OS2LDR, OS2LDR.MSG files), but they did not include
the DOSCALL1.DLL. So, one *can* improve the kernel file, without an
improved DOSCALL1.DLL file.

So, I would suggest that OS2KRNL, aka DOSCALLS.DLL, and the DOSCALL1.DLL
should be the same version.

But, the PMMERGE.DLL file has been redone numerous times because of its
programming problems. IBM offered an updated/corrected versions of that
file for Fixpack #13 or later, as I recall. But, for Fixpack #12 or
earlier those later versions of PMMERGE.DLL won't help you since OS2
Warp 4.0 became entirely different starting with Fixpack #13.

Post by Wolfi
Among others, I had os2krnl, CMD.EXE and DOSCALL1.DLL all from FP12 on
my floppies, but apparently as soon as the WPS should be brought up,
PMMERGE.DLL from the installation CD doesn't like that latter one at all.

Or original post indicated that the file PMSHELL.EXE was not compatible
with the PMMERGE.DLL file. So what I would do is be sure that the files
for both PMSHELL.EXE and PMMERGE.DLL are compatible, by use both from
the same release or fixpack.

Post by Wolfi
And from what I found out in the meantime, CMD.EXE and DOSCALL1.DLL must
also match, but unfortunately syncing those three still isn't enough.

This is not true in my experience. I believe that in later version, the
CMD.EXE file does not check to see what version of OS/2 it is running
under. But, if my memory serves me correctly, that was true in older
versions of OS/2. Maybe the changed with version after Fixpack #12. BTW,
AFAIK, the later version of CMD.EXE do not add any additional
improvements or features.

Post by Wolfi
With CMD.EXE and DOSCALL1.DLL being from the W4 CD again on my Disk2,
the installer now is already having trouble as soon as it tries to work

I suspect your problem is only the messed-up PMMERGE.DLL file, which you
may want to use another version. IBM even made an updated version of
PMMERGE.DLL that turned-out to be worse than the version that is was to
replaced, so the users were urge to use an older version. This poor file
has had such types of problems.

Report to your readers what version of PMMERGE.DLL that you are using,
and other users will be able to tell you if that was the good or the bad
version of PMMERGE.DLL. That is reported by typing:

BLDLEVEL.EXE PMMERGE.DLL

Post by Wolfi
This is really one huge mess.
So far I haven't compressed anything with LxLite other than the larger
*.EXE on DISK2. I cannot even use Dani's compact, already compressed
DaniS506.add w/o having trouble, it has to be an uncompressed one to work.

The author does recommend only her full-debug, 16-bit NE file, for
production use. But that compressed nicely with NELite, though one
doesn't actually save enough space to make that worth it. But, you can
later copy the most recent version of DANIS506.ADD manually to your hard
drive, before you attempt to boot-up graphical OS/2. (You can replace
any files this way, such as with different versions of PMMERGE.DLL to
see if there is one that works better.)

The latest version of DANIS506.ADD is Ver. 1.7.10, dated Feb. 2007.

[Steve Wendt]

Post by My Name
AFAIK, the later version of CMD.EXE do not add any additional
improvements or features.

The 4.5x versions added the shell support for LIBPATHSTRICT. Of course,
that also requires a 14.x kernel version.

[My Name]

Post by Steve Wendt

Post by My Name
AFAIK, the later version of CMD.EXE do not add any additional
improvements or features.

The 4.5x versions added the shell support for LIBPATHSTRICT. Of course,
that also requires a 14.x kernel version.

Oh, yes. I certainly didn't mean to refer to any versions older than the
recent (past five years) of the 14.xx series.

Thanks for clarifying for newbies, who might not have understand. I
didn't mean to imply that a version of OS/2 1.3x would work correctly. (g)

[Wolfi]

Post by My Name

Post by Wolfi
Well, now you're loosing me :-\
I cannot find a DOSCALLS.DLL anywhere on my FP16+ box and I've never
seen one coming with one of Scott's kernel updates.

Oooh, so sorry. I did not type-out my sentence correctly for you to
The only one that might be a problem is DOSCALL1.DLL. It needs to be in
sync with the
DOSCALLS.DLL file that is (secretly) located *within* the OS/2 kernel,
in the OS2KRNL file.
And therefore the PMMERGE.DLL should also be from the same fixpack.
In other words, the the OS2KRNL file (the kernel file) becomes known as
DOSCALLS.DLL file in the computer's memory. But, they don't have to
been. The IBM Testcase website used to offer updated/corrected OS2KRNL
files, (along with OS2LDR, OS2LDR.MSG files), but they did not include
the DOSCALL1.DLL. So, one *can* improve the kernel file, without an
improved DOSCALL1.DLL file.
So, I would suggest that OS2KRNL, aka DOSCALLS.DLL, and the DOSCALL1.DLL
should be the same version.
But, the PMMERGE.DLL file has been redone numerous times because of its
programming problems. IBM offered an updated/corrected versions of that
file for Fixpack #13 or later, as I recall. But, for Fixpack #12 or
earlier those later versions of PMMERGE.DLL won't help you since OS2
Warp 4.0 became entirely different starting with Fixpack #13.

Post by Wolfi
Among others, I had os2krnl, CMD.EXE and DOSCALL1.DLL all from FP12 on
my floppies, but apparently as soon as the WPS should be brought up,
PMMERGE.DLL from the installation CD doesn't like that latter one at all.

Or original post indicated that the file PMSHELL.EXE was not compatible
with the PMMERGE.DLL file. So what I would do is be sure that the files
for both PMSHELL.EXE and PMMERGE.DLL are compatible, by use both from
the same release or fixpack.

Post by Wolfi
And from what I found out in the meantime, CMD.EXE and DOSCALL1.DLL
must also match, but unfortunately syncing those three still isn't
enough.

This is not true in my experience. I believe that in later version, the
CMD.EXE file does not check to see what version of OS/2 it is running
under. But, if my memory serves me correctly, that was true in older
versions of OS/2. Maybe the changed with version after Fixpack #12. BTW,
AFAIK, the later version of CMD.EXE do not add any additional
improvements or features.

Post by Wolfi
With CMD.EXE and DOSCALL1.DLL being from the W4 CD again on my Disk2,
the installer now is already having trouble as soon as it tries to

I suspect your problem is only the messed-up PMMERGE.DLL file, which you
may want to use another version. IBM even made an updated version of
PMMERGE.DLL that turned-out to be worse than the version that is was to
replaced, so the users were urge to use an older version. This poor file
has had such types of problems.

Mmh, I can't. Bottomline from what I found so far is, in order to get Warp4.0
installed successfully, at least the OS2KRNL, CMD.EXE and DOSCALL1.DLL must
NOT be replaced with later versions and mouse.sys must remain pre-XR_DDD1 and
most other DLLs also shouldn't be touched or only updated to a very close
newer version.

Post by My Name
Report to your readers what version of PMMERGE.DLL that you are using,
and other users will be able to tell you if that was the good or the bad
BLDLEVEL.EXE PMMERGE.DLL

Since I cannot change the installer nor the files being used from the
installation CD, I cannot replace PMMERGE.DLL or any of the other files
prior/during the installation process.

Post by My Name

Post by Wolfi
This is really one huge mess.
So far I haven't compressed anything with LxLite other than the larger
*.EXE on DISK2. I cannot even use Dani's compact, already compressed
DaniS506.add w/o having trouble, it has to be an uncompressed one to work.

The author does recommend only her full-debug, 16-bit NE file, for
production use. But that compressed nicely with NELite, though one
doesn't actually save enough space to make that worth it.

Dani's provided already compressed non-debug version, which is some important
20kB smaller than the regular one simply doesn't work here on those
installation Diskettes and I just take it, ghiven her knowledge, that she
knows, what she's doing when compressing her driver.

Post by My Name
But, you can
later copy the most recent version of DANIS506.ADD manually to your hard
drive, before you attempt to boot-up graphical OS/2. (You can replace
any files this way, such as with different versions of PMMERGE.DLL to
see if there is one that works better.)

Sur, but that is only possible *after* a successful installation. Right now
I'm still fighting with the actual installation itself.

[My Name]

Post by Wolfi
Mmh, I can't. Bottomline from what I found so far is, in order to get
Warp4.0 installed successfully, at least the OS2KRNL, CMD.EXE and
DOSCALL1.DLL must NOT be replaced with later versions and mouse.sys must
remain pre-XR_DDD1 and most other DLLs also shouldn't be touched or only
updated to a very close newer version.

Oh, bull-winky.

IBM makes updated installation disks for Warp 4.0. It has been available
for years now. It is a requirement, since one can not install with
today's equipment using the original Warp 4.0 installation diskettes.
You did start with that one didn't you?

Post by Wolfi

Post by My Name
Report to your readers what version of PMMERGE.DLL that you are using,
and other users will be able to tell you if that was the good or the
BLDLEVEL.EXE PMMERGE.DLL

Since I cannot change the installer nor the files being used from the
installation CD, I cannot replace PMMERGE.DLL or any of the other files
prior/during the installation process.

After the files are copied from the CD, to a hard drive, one must then
re-boot the computer, from a floppy diskette set, and replace some
files, One of those files that you may want to replace is the
PMMERGE.DLL, since it is giving you problems. You could replace anything
lese that you needs to be updated or replaced at that time. Then
re-boot, and proceed with your setup from the hard drive.

In fact, it can be helpful to "correct' the CONFIF.SYS file, SNOOP.LST
file, verify that updated files from the diskettes are actually on the
hard drive, etc.

Post by Wolfi

Post by My Name

Post by Wolfi
This is really one huge mess.
So far I haven't compressed anything with LxLite other than the
larger *.EXE on DISK2. I cannot even use Dani's compact, already
compressed DaniS506.add w/o having trouble, it has to be an
uncompressed one to work.

The author does recommend only her full-debug, 16-bit NE file, for
production use. But that compressed nicely with NELite, though one
doesn't actually save enough space to make that worth it.

Dani's provided already compressed non-debug version, which is some
important 20kB smaller than the regular one simply doesn't work here on
those installation Diskettes and I just take it, ghiven her knowledge,
that she knows, what she's doing when compressing her driver.

I like my compressed versions better. I have only had trouble
compressing one of her files in recent years. Don't know why.
And NELite "cleans-up" nearly all 16-bit NE files, although it won't
necessarily make some files any smaller. DANIS506.ADD is compressed to
the max, by the author, as I recall. So, indeed stick with it.

Post by Wolfi

Post by My Name
But, you can later copy the most recent version of DANIS506.ADD
manually to your hard drive, before you attempt to boot-up graphical
OS/2. (You can replace any files this way, such as with different
versions of PMMERGE.DLL to see if there is one that works better.)

Sur, but that is only possible *after* a successful installation. Right
now I'm still fighting with the actual installation itself.

I'm afraid I'm not clear what you mean by an "installation" The files
are "installed", actually copied, to the hard drive. Then the OS/2
operating system boots-up from the hard drive. The installation,
*always* works. If files can not be installed on to the hard drive,
meaning, if they can not be copied from the diskettes and the CD-ROM,
then indeed, there is something wrong with some file or files on your
installation diskettes, or the CD-ROM is broken.

I hope your not confusing the installation of eCS with OS/2. eCS
actually boots-up from the CD-ROM and copies the files from there to the
hard drive, unless one purposely makes installation diskettes for some
reason. OS2/ Warp 4.0x, on the other hand, does not run from the CD-ROM.
It runs from the diskettes, and copies the files from the CD-ROM to the
hard drive. Presentation Manager does not is not until one re-boots from
the hard drive.

Sorry, did I incorrectly assume that you were using the "corrected" IBM
installation diskettes for Warp 4.0, as has been required since for
years now. Or where you just try to replace files on the installation
diskettes that same from the original Warp 4.0 CD-ROM?

After files are copied to the hard drive, and verify each and every file
that is going to be used, and replace any file that is not working, such
as the PMMERGE.DLL file. For Warp 4.0 those are DLL files from Fixpack
#12 for earlier, and AFAIK, any more recent device drivers should work.
Gee, most of them work all the way back to OS/2 2.0 (before it became
Warp.)

[Wolfi]

Post by My Name

Post by Wolfi
Mmh, I can't. Bottomline from what I found so far is, in order to get
Warp4.0 installed successfully, at least the OS2KRNL, CMD.EXE and
DOSCALL1.DLL must NOT be replaced with later versions and mouse.sys
must remain pre-XR_DDD1 and most other DLLs also shouldn't be touched
or only updated to a very close newer version.

Oh, bull-winky.
IBM makes updated installation disks for Warp 4.0. It has been available
for years now. It is a requirement, since one can not install with
today's equipment using the original Warp 4.0 installation diskettes.
You did start with that one didn't you?

They had been published for Thinkpad installation and other than some LCD
display related stuff the only major changes are updates to IBM1s506.add and
IIRC os2dasd.dmd and the IFS.

Post by My Name

Post by Wolfi

Post by My Name
Report to your readers what version of PMMERGE.DLL that you are
using, and other users will be able to tell you if that was the good
BLDLEVEL.EXE PMMERGE.DLL

Since I cannot change the installer nor the files being used from the
installation CD, I cannot replace PMMERGE.DLL or any of the other
files prior/during the installation process.

After the files are copied from the CD, to a hard drive, one must then
re-boot the computer, from a floppy diskette set, and replace some
files, One of those files that you may want to replace is the
PMMERGE.DLL, since it is giving you problems.

No I cannot. With more major updates on my floppies I don't even get to the
point where anything can be installed on HD, ergo nothing there to possibly be
replaced later on and I really don't want to have to copy files from
additional 2500 floppies to the HD manually in order to resolve all possible
dependencies ;-)

Post by My Name
You could replace anything
lese that you needs to be updated or replaced at that time. Then
re-boot, and proceed with your setup from the hard drive.
In fact, it can be helpful to "correct' the CONFIF.SYS file, SNOOP.LST
file, verify that updated files from the diskettes are actually on the
hard drive, etc.

They are, assuming a boot floppy set is used according to the above outlined
requirements.

Post by My Name

Post by Wolfi

Post by My Name

Post by Wolfi
This is really one huge mess.
So far I haven't compressed anything with LxLite other than the
larger *.EXE on DISK2. I cannot even use Dani's compact, already
compressed DaniS506.add w/o having trouble, it has to be an
uncompressed one to work.

The author does recommend only her full-debug, 16-bit NE file, for
production use. But that compressed nicely with NELite, though one
doesn't actually save enough space to make that worth it.

Dani's provided already compressed non-debug version, which is some
important 20kB smaller than the regular one simply doesn't work here
on those installation Diskettes and I just take it, given her
knowledge, that she knows, what she's doing when compressing her driver.

I like my compressed versions better. I have only had trouble
compressing one of her files in recent years. Don't know why.
And NELite "cleans-up" nearly all 16-bit NE files, although it won't
necessarily make some files any smaller. DANIS506.ADD is compressed to
the max, by the author, as I recall. So, indeed stick with it.

No, as I already explained, the compressed version triggers an exception in
driver IBM1Flp$, caused by IBMINT13.I13 later on.
Don't forget we are talking about kernel version 9.23 here.

Post by My Name

Post by Wolfi

Post by My Name
But, you can later copy the most recent version of DANIS506.ADD
manually to your hard drive, before you attempt to boot-up graphical
OS/2. (You can replace any files this way, such as with different
versions of PMMERGE.DLL to see if there is one that works better.)

Sure, but that is only possible *after* a successful installation.
Right now I'm still fighting with the actual installation itself.

I'm afraid I'm not clear what you mean by an "installation" The files
are "installed", actually copied, to the hard drive. Then the OS/2

No, not yet. The installation is controlled by sysinst2.exe and cdinst.exe and
if those don't succeed due to the dependencies to OSKRNL, DOSCALL1.DLL and
CMD.EXE, MOUSE.SYS, etc, I reported about, one doesn't even get to the point,
where a reboot from HD takes place at all.

Post by My Name
operating system boots-up from the hard drive. The installation,
*always* works. If files can not be installed on to the hard drive,
meaning, if they can not be copied from the diskettes and the CD-ROM,
then indeed, there is something wrong with some file or files on your
installation diskettes, or the CD-ROM is broken.

No it isn't. Then some files on the installation floppies were updated to
versions, creating conflicts for others depending on them.

Post by My Name
I hope your not confusing the installation of eCS with OS/2. eCS
actually boots-up from the CD-ROM

... if you mobo BIOS supports that. As I said earlier, I still have 2 boxes
around, which cannot do that.

Post by My Name
and copies the files from there to the
hard drive, unless one purposely makes installation diskettes for some
reason. OS2/ Warp 4.0x, on the other hand, does not run from the CD-ROM.
It runs from the diskettes, and copies the files from the CD-ROM to the
hard drive. Presentation Manager does not is not until one re-boots from
the hard drive.
Sorry, did I incorrectly assume that you were using the "corrected" IBM
installation diskettes for Warp 4.0, as has been required since for

... which hardly contain anything else than what I already did 7 years ago
with the original ones from the Warp 4.0 CD, by using DaniS506 and keeping the
IFS and DMD up to date.

Post by My Name
years now. Or where you just try to replace files on the installation
diskettes that same from the original Warp 4.0 CD-ROM?

yes, trying to get to a level where I could use LVM rather than the 8032MB
crippled FDIsk/BM.

Post by My Name
After files are copied to the hard drive, and verify each and every file
that is going to be used, and replace any file that is not working, such
as the PMMERGE.DLL file. For Warp 4.0 those are DLL files from Fixpack
#12 for earlier, and AFAIK, any more recent device drivers should work.
Gee, most of them work all the way back to OS/2 2.0 (before it became
Warp.)

No, apparently they don't. I suggest to do some testing on your own then,
trying to get Warp 4.0 installed with newer kernel, cmd.exe and DOSCALL1.DLL
and if you want more excitement, also update a couple of those DLLs on Disk2
and use MOUSE.sys from DD01 or later, the installer will love it ;-)

[Michael Lueck]

Post by My Name
Oh, bull-winky.
IBM makes updated installation disks for Warp 4.0. It has been available
for years now. It is a requirement, since one can not install with
today's equipment using the original Warp 4.0 installation diskettes.
You did start with that one didn't you?

I would like to see someone manage to get Scott's 103a kernel to fit on a boot diskette! ;-)

If installing OS/2 (not eCS which has 103a kernel), I have to install on something old enough to boot "whatever" kernel, then swap the kernel for 103a.

I have not tried booting to eCS or a bootAble eCS maintenance partition and then launching setup from the CD. "Someday...... maybe."

[mike luther]

Shuckins!

Post by Michael Lueck

Post by My Name
Oh, bull-winky.
IBM makes updated installation disks for Warp 4.0. It has been
available for years now. It is a requirement, since one can not
install with today's equipment using the original Warp 4.0
installation diskettes. You did start with that one didn't you?

I would like to see someone manage to get Scott's 103a kernel to fit on
a boot diskette! ;-)

Ain' yo mama done toll you 'bout playin' wid dem hi density floppies?


2.88 MB size?


If yo good 'nuf you might even do it with one! But you better be sure you
playin' with the right medium when you gone down into that swamp.


GDRFC


Seriously, if anyone really wants to try with this dig up FF231.ZIP and
QCOPY51.ZIP. But you better be prepared to reboot your system after you start
playing with 2.88 MB floppy diskettes at this stuff, per my long ago work to
create single disk OS/2 boot floppy operations. And some drives would work
with the diskette and some wouldn't.


;)

[Michael Lueck]

Post by mike luther
Ain' yo mama done toll you 'bout playin' wid dem hi density floppies?
2.88 MB size?

I actually have a 2.88 FDD in my ThinkPad dock! It only works with my old TP 760XL, as IBM removed support for 2.88's in the 600E BIOS.

So, seems a work around, except for screaming fast P4's that the 2.88 is not installed in... which is where the 103a kernel is needed.

[My Name]

lxlite <filename> /W- /N+ /Vm showed>

You shoudl be able to use the Imports parameter to show what files
functions are imported from. It is already setup by LXLite, type:

LXLITE.EXE FILENAME.EXT /C:IMP

and this will show you the import files and some imported function names
if shown in the file.

If you want to see the functions that are exported to other files use:

LXLITE.EXE FILENAME.EXT /C:EXP

so I might need to backlevel the FP12 DLLs
viocalls.dll, doscall1.dll, quecalls.dll, sesmgr.dll
to the original W4 level.
Newer mouse.sys and pointdd.sys shouldn't cause a problem only that
late, should they?

I don't suggest back-leveling any these files. They need to be in sync,
so check on your hard drive that the correct files were copied there
from your floppy disks, and not backleveled files from the CD-ROM.

[Scott G]

I very strongly recommend against applying post-fp12 updates on a FP12
base. There is an enormous difference between the build base after FP12.
If anything works, it's just luck. You really need to start with an
MCP/MCP2/FP14+/whatever base.

You can play with later device drivers, but you're really playing with
fire.

-Scott

[Wolfi]

Post by Scott G
I very strongly recommend against applying post-fp12 updates on a FP12
base. There is an enormous difference between the build base after FP12.
If anything works, it's just luck. You really need to start with an
MCP/MCP2/FP14+/whatever base.
You can play with later device drivers, but you're really playing with
fire.

Thanks, Scott.
You are confirming, what I partially found out the hard, experimental way so
far. So me thinks, I need to re-evaluate my approach.

[Michael Lueck]

Post by Wolfi
My installation diskettes now are at FP12 level, whereas most *.add,
*.ifs, *.dmd and some *.sys, as well as ibmidecd.flt are on a later
level (2002-'06).

I recently was backed into the corner of having to cook a Warp 4 image for one client. As for my install diskette technique...

Deleted most mass storage device drivers OTHER than:
IBM1S506
IBM2*

Added Danis replacement IBM1S506 and also her CDROM driver

I forgot to set the COPYFROMFLOPPY=1 so I had to hand copy the Danis drivers.

Otherwise it booted well.

I installed FP12, then Scott's TestCase Kernel 103a, and also his HPFS update.

etc...

The resulting image actually booted right up on our current P4 3.2GHz Intel 945 based system!

[Wolfi]

Post by Michael Lueck

Post by Wolfi
My installation diskettes now are at FP12 level, whereas most *.add,
*.ifs, *.dmd and some *.sys, as well as ibmidecd.flt are on a later
level (2002-'06).

I recently was backed into the corner of having to cook a Warp 4 image
for one client. As for my install diskette technique...
IBM1S506
IBM2*

I simply replaced those with tiny text files of the same name, to make
whatever insists on them being present, happy, at least kind of.

Post by Michael Lueck
Added Danis replacement IBM1S506 and also her CDROM driver
I forgot to set the COPYFROMFLOPPY=1 so I had to hand copy the Danis drivers.
Otherwise it booted well.

After having figured at least some of the dependencies and hence what not to
touch under any circumstances (like: OS2KRNL, CMD.EXE, DOSCALL1.DLL and most
other DLLs), I'm now finally also at this point with my W4 installation
diskettes :-)

Only annoying thing left is that most of the time at the end of Disk2, after
testcfg.sys was loaded, but before the blue "Welcome" installation screen
comes up, I'm getting an MOUSE$ error, claiming that my mouse wouldn't work
and breaking the installation.
So I simply need to pull the PS/2 mouse in time, until the installer has come
up with that screen and then reconnect it. At least that's what happens on
this nForce2 based Athlon XP system I currently use for those tests.

Post by Michael Lueck
I installed FP12, then Scott's TestCase Kernel 103a, and also his HPFS update.

By now I came to realize, that my original goal to create one universal set of
installation floppies, still suitable for a W4.0 CD-installation, but also
allowing the use of LVM rather than FDisk for maintenance purposes, simply is
not doable and hence had to change my initial approach.

[Michael Lueck]

Post by Michael Lueck
I installed FP12

That should have been "I installed FP17"...

Post by Michael Lueck
By now I came to realize, that my original goal to create one universal
set of installation floppies, still suitable for a W4.0 CD-installation,
but also allowing the use of LVM rather than FDisk for maintenance
purposes, simply is not doable and hence had to change my initial approach.

I configure OS/2 eCS 1.2MR as follows:
C: HPFS eCS
D: HPFS Maint OS ala bootAble
E: JFS AppData (Apps and Data)

So, from OS/2 Warp 4, E: is completely hidden, and I dare not tinker inside FDisk.

I shudder at the thought of LVMizing Warp 4.

Maybe you should consider two "universal" rescue boots... one ala Warp 4 for FDisk style HDD's, and one either Warp 4.5x or eCS for LVM style HDD's.

[Wolfi]

Post by Michael Lueck

Post by Michael Lueck
I installed FP12

That should have been "I installed FP17"...

Post by Michael Lueck
By now I came to realize, that my original goal to create one
universal set of installation floppies, still suitable for a W4.0
CD-installation, but also allowing the use of LVM rather than FDisk
for maintenance purposes, simply is not doable and hence had to change
my initial approach.

C: HPFS eCS
D: HPFS Maint OS ala bootAble
E: JFS AppData (Apps and Data)
So, from OS/2 Warp 4, E: is completely hidden, and I dare not tinker inside FDisk.
I shudder at the thought of LVMizing Warp 4.

But in order to be able to boot additional OS' from my HDD, I must either try
this way or switch to something like AiRBoot, since I have to get beyond that
dumb FDisk-BM 8GB boot restriction.
LVM also would make the partition naming sequence quite a bit more convenient
to maintain than right now with DaniDasd and the now rather lengthy (currently
17) partition list for 3 HDDs.

Post by Michael Lueck
Maybe you should consider two "universal" rescue boots... one ala Warp 4
for FDisk style HDD's, and one either Warp 4.5x or eCS for LVM style HDD's.

As I outlined above, that would only meet half the goal.

[Michael Lueck]

Post by Wolfi
But in order to be able to boot additional OS' from my HDD, I must
either try this way or switch to something like AiRBoot, since I have to
get beyond that dumb FDisk-BM 8GB boot restriction.

On one system, I have Lilo on the MBR, and BootManager as the first Pri partition for booting OS/2... which is the next Pri and Log partitions. I boot Linux from deeper into the drive. That way OS/2
does not freak out at the presence of non-OS/2 partitions, makes drive letters very simple (in OS/2), etc...

Rather a long explanation that the 8GB restriction did not affect me.

Are you sure about that 8GB number? On our systems preloaded with eCS, I usually create a 10GB C:, and 1GB D:. As they can both be booted to, that means either LVM was a solution for that problem,
or... ??? Some say, "Ignorance is bliss." ;-)

[Wolfi]

Post by Michael Lueck

Post by Wolfi
But in order to be able to boot additional OS' from my HDD, I must
either try this way or switch to something like AiRBoot, since I have
to get beyond that dumb FDisk-BM 8GB boot restriction.

On one system, I have Lilo on the MBR, and BootManager as the first Pri
partition for booting OS/2... which is the next Pri and Log partitions.
I boot Linux from deeper into the drive. That way OS/2 does not freak
out at the presence of non-OS/2 partitions, makes drive letters very
simple (in OS/2), etc...

How does that work? As I understand it, the MBR needs to point to the IBM BM,
residing in one of the 3 possible primaries (given that we want an extended
one as well), which then does the hide/unhide primary partition thingy if
necessary and in turn points the BIOS loader to the partition boot record of
choice of the system chosen to be booted up.

Post by Michael Lueck
Rather a long explanation that the 8GB restriction did not affect me.
Are you sure about that 8GB number?

Most definitely, unfortunately. IBM failed to also kill that stupid FDisk
restriction, when they released the extPart package (build level 14.082),
enabling those M$ invented extended partition types, like "F" for the extended
one and those other Fat32 et al flavours.

Post by Michael Lueck
On our systems preloaded with eCS, I
usually create a 10GB C:, and 1GB D:. As they can both be booted to,
that means either LVM was a solution for that problem, or... ???

Exactly! LVM doesn't have those restrictions and in addition allows to freely
(re)assign drive letters, which then makes dealing with OS' easy, using
previously unknown file systems.

Post by Michael Lueck
Some say, "Ignorance is bliss." ;-)

Sometimes it really is ;-)

[Michael Lueck]

Post by Wolfi

Post by Michael Lueck
On one system, I have Lilo on the MBR, and BootManager as the first
Pri partition for booting OS/2... which is the next Pri and Log
partitions. I boot Linux from deeper into the drive. That way OS/2
does not freak out at the presence of non-OS/2 partitions, makes drive
letters very simple (in OS/2), etc...

How does that work?

Well, since BootManager resides on a partition rather than just a boot sector / boot record, then Lilo is installed on the MBR of the disk, I have a menu choice for /dev/hda2 which is the partition
BootManager resides on in Linux's eyes. If I select that from the Lilo menu, then the next thing I see after Lilo is BootManager.

I do no hiding/unhiding of partitions on that system.

Post by Wolfi
Exactly! LVM doesn't have those restrictions

Then that explains it. (The reason I can have a 10GB C: and still boot from D:)

[Bob Eager]

On Tue, 1 May 2007 15:35:47 UTC, Michael Lueck

Post by Michael Lueck
Are you sure about that 8GB number?

Indeed. The restriction was effectovely lifted at FP13 (not with LVM)
though.

[Bob Eager]

Post by Wolfi

Post by Michael Lueck
I shudder at the thought of LVMizing Warp 4.

But in order to be able to boot additional OS' from my HDD, I must either try
this way or switch to something like AiRBoot, since I have to get beyond that
dumb FDisk-BM 8GB boot restriction.

It's not an FDISK restriction. It's a pre-FP13 restriction. Get the
diskettes updated to FP13 or later (preferably FP15) and it will go >
8GB. But I said that way back in the thread (I think).

[Wolfi]

Post by Bob Eager

Post by Wolfi

Post by Michael Lueck
I shudder at the thought of LVMizing Warp 4.

But in order to be able to boot additional OS' from my HDD, I must either try
this way or switch to something like AiRBoot, since I have to get beyond that
dumb FDisk-BM 8GB boot restriction.

It's not an FDISK restriction. It's a pre-FP13 restriction. Get the
diskettes updated to FP13 or later (preferably FP15) and it will go >
8GB. But I said that way back in the thread (I think).

Mmmh, why does FDisk/query on my W4 FP16+ system with kernel 14.104a then
still report "**BIOS:8032MB"?
And it definitely is *not* the BIOS imposing an 8GB restriction.
Here f.e., I cannot add a 10GB partition, being the first logical one after a
7MB empty slot (reserved for a potential BM) on a 2nd HDD to the BM menu or
have any other option for it than to delete it.
This is what convinced me, that the limitation for non-LVM systems still today
is even the latest FDisk 14.082/056(noFAT32).

[Wolfi]

Post by Wolfi

Post by Bob Eager

Post by Wolfi

Post by Michael Lueck
I shudder at the thought of LVMizing Warp 4.

But in order to be able to boot additional OS' from my HDD, I must
either try this way or switch to something like AiRBoot, since I have
to get beyond that dumb FDisk-BM 8GB boot restriction.

It's not an FDISK restriction. It's a pre-FP13 restriction. Get the
diskettes updated to FP13 or later (preferably FP15) and it will go >
8GB. But I said that way back in the thread (I think).

Mmmh, why does FDisk/query on my W4 FP16+ system with kernel 14.104a
then still report "**BIOS:8032MB"?
And it definitely is *not* the BIOS imposing an 8GB restriction.
Here f.e., I cannot add a 10GB partition, being the first logical one
after a 7MB empty slot (reserved for a potential BM) on a 2nd HDD to the
BM menu or have any other option for it than to delete it.
This is what convinced me, that the limitation for non-LVM systems still
today is even the latest FDisk 14.082/056(noFAT32).

I missed to add, that on a 3rd HDD, FDISK 14.056 would allow me to add the
first, a logical, 6GB partition, also directly following an empty 7MB slot, to
its BM menu, while the neighbouring next 6GB logical partition again cannot be
added anymore.

[Bob Eager]

Post by Wolfi

Post by Bob Eager

Post by Wolfi

Post by Michael Lueck
I shudder at the thought of LVMizing Warp 4.

But in order to be able to boot additional OS' from my HDD, I must either try
this way or switch to something like AiRBoot, since I have to get beyond that
dumb FDisk-BM 8GB boot restriction.

It's not an FDISK restriction. It's a pre-FP13 restriction. Get the
diskettes updated to FP13 or later (preferably FP15) and it will go >
8GB. But I said that way back in the thread (I think).

Mmmh, why does FDisk/query on my W4 FP16+ system with kernel 14.104a then
still report "**BIOS:8032MB"?
And it definitely is *not* the BIOS imposing an 8GB restriction.

How do you know? I can't remember all that you said, but it looks like
either:

a) a BIOS that can't access beyond 8GB (in which case LVM would make no
difference)
b) some component that needs to be updated and hasn't

BTW, the kernel really has no bearing on this, as long as it's post FP12
(and even then, it's really the bootstrap).

I assume all relevant components have been updated...perhaps one hasn't.

Post by Wolfi
Here f.e., I cannot add a 10GB partition, being the first logical one after a
7MB empty slot (reserved for a potential BM) on a 2nd HDD to the BM menu or
have any other option for it than to delete it.
This is what convinced me, that the limitation for non-LVM systems still today
is even the latest FDisk 14.082/056(noFAT32).

[Wolfi]

Post by Bob Eager

Post by Wolfi

Post by Bob Eager

Post by Wolfi

Post by Michael Lueck
I shudder at the thought of LVMizing Warp 4.

But in order to be able to boot additional OS' from my HDD, I must either try
this way or switch to something like AiRBoot, since I have to get beyond that
dumb FDisk-BM 8GB boot restriction.

It's not an FDISK restriction. It's a pre-FP13 restriction. Get the
diskettes updated to FP13 or later (preferably FP15) and it will go >
8GB. But I said that way back in the thread (I think).

Mmmh, why does FDisk/query on my W4 FP16+ system with kernel 14.104a then
still report "**BIOS:8032MB"?
And it definitely is *not* the BIOS imposing an 8GB restriction.

How do you know? I can't remember all that you said, but it looks like

For 2 reasons:
1st being, that back in autumn of '99, when I put this box together, I just
had received one of the earlier WSeB betas from IBM and I didn't have any
problem to successfully install and use that one and/or LVM/BM at the very
beginning or the very end of my 15GB HDD in either combination.

2nd being, that your ExtDisk utility also confirmed that the BIOS support
extINT13.

Post by Bob Eager
a) a BIOS that can't access beyond 8GB (in which case LVM would make no
difference)

Nope, this case is excluded ;-)

Post by Bob Eager
b) some component that needs to be updated and hasn't
BTW, the kernel really has no bearing on this, as long as it's post FP12
(and even then, it's really the bootstrap).
I assume all relevant components have been updated...perhaps one hasn't.

It really would be surprising if applying FP13 up to FP16 would have missed to
update something essential and then of course, the price question really would
be, how to find out which one :-\

Post by Bob Eager

Post by Wolfi
Here f.e., I cannot add a 10GB partition, being the first logical one after a
7MB empty slot (reserved for a potential BM) on a 2nd HDD to the BM menu or
have any other option for it than to delete it.
This is what convinced me, that the limitation for non-LVM systems still today
is even the latest FDisk 14.082/056(noFAT32).

Thus as a result, the only valid conclusion I could draw was, that IBM in the
end despite all expectation actually did not update FDisk to be able to handle
LBA access beyond the capabilities of the outdated CHS scheme.

[Wolfi]

While we are at LVM, I just was going through your LVM pages at
http://www.tavi.co.uk/os2pages/lvm.html#CreateVol again, but didn't find the
info I was hoping for.

In LVM's <Logical View> -> <Create a new Volume> what exactly is the
difference between '... a volume that does not need to be bootable' and one
'... that can be made bootable'?

These non-saying lines are confusing me each and every time I'm running into
them.
Is this IBM's confuscating way of communicating, that one will become a JFS
and the other one a volume with a traditional file system?
Or what exactly is the deal here?

[Bob Eager]

Post by Wolfi
While we are at LVM, I just was going through your LVM pages at
http://www.tavi.co.uk/os2pages/lvm.html#CreateVol again, but didn't find the
info I was hoping for.
In LVM's <Logical View> -> <Create a new Volume> what exactly is the
difference between '... a volume that does not need to be bootable' and one
'... that can be made bootable'?

A volume that can be made bootable is always a compatibility volume. It
also appears in the boot menu automatically.

A volume that does not need to be bootable can be either a compatibility
volume or an LVM volume - you are given the choice. Such volumes can be
made up of more than one partition.

Post by Wolfi
Is this IBM's confuscating way of communicating, that one will become a JFS
and the other one a volume with a traditional file system?

No. It is true that a compatibility volume cannot be a JFS volume. But
it is also the case that you can use FAT or HPFS on both kinds of
volume. This means that you can have FAT, HPFS, or JFS volumes spread
across multiple partitions and disks.

[Steven Levine]

In <176uZD2KcidF-pn2-***@rikki.tavi.co.uk>, on 05/01/2007
at 11:37 PM, "Bob Eager" <***@spamcop.net> said:

Hi,

Post by Bob Eager
A volume that does not need to be bootable can be either a compatibility
volume or an LVM volume - you are given the choice.

The confusion occurs because LVM volumes are often referred to as JFS
volumes. I just did it myself. Your terminology is more correct.

Post by Bob Eager
No. It is true that a compatibility volume cannot be a JFS volume.

This is true for IBM's versions of OS/2, but not for eComStation.
Bootable, JFS formatted, compatibility volumes are fully supported.

Steven

[Bob Eager]

On Wed, 2 May 2007 00:06:32 UTC, Steven Levine

Post by Steven Levine
Hi,

Post by Bob Eager
A volume that does not need to be bootable can be either a compatibility
volume or an LVM volume - you are given the choice.

The confusion occurs because LVM volumes are often referred to as JFS
volumes. I just did it myself. Your terminology is more correct.

Post by Bob Eager
No. It is true that a compatibility volume cannot be a JFS volume.

This is true for IBM's versions of OS/2, but not for eComStation.
Bootable, JFS formatted, compatibility volumes are fully supported.

Yes...I realised that, typed it, then deleted it. In an attempt to
simplify what I wrote!

[Wolfi]

Post by Bob Eager

Post by Wolfi
While we are at LVM, I just was going through your LVM pages at
http://www.tavi.co.uk/os2pages/lvm.html#CreateVol again, but didn't find the
info I was hoping for.
In LVM's <Logical View> -> <Create a new Volume> what exactly is the
difference between '... a volume that does not need to be bootable' and one
'... that can be made bootable'?

A volume that can be made bootable is always a compatibility volume. It
also appears in the boot menu automatically.

That was one of the snafus I had a problem with, because there was nothing
left for me to possibly 'make bootable'.
So 'Create a volume that can be made bootable' then actually needs to be read:
'Create a volume that will be bootable'.

Post by Bob Eager
A volume that does not need to be bootable can be either a compatibility
volume or an LVM volume - you are given the choice. Such volumes can be
made up of more than one partition.

Not having gone the multi partition LVM volume path yet, but using both of the
above listed ways, I always ended up basically with the same result, omitting
the automatically done/still missing boot menu record. Then adding the
promised, but not available any more option about '.. can be made bootable'
simply confused me, rather then helping to simplify things.

Post by Bob Eager

Post by Wolfi
Is this IBM's confuscating way of communicating, that one will become a JFS
and the other one a volume with a traditional file system?

No. It is true that a compatibility volume cannot be a JFS volume. But
it is also the case that you can use FAT or HPFS on both kinds of
volume. This means that you can have FAT, HPFS, or JFS volumes spread
across multiple partitions and disks.

Then I just need to try to memorize, that I have to stick with the 'Create a
volume that does not need to be bootable', since this one is giving me all the
possible choices w/o confusing me with pretending to offer an option, when
actually already secretly doing it for me.

[Bob Eager]

Post by Wolfi

Post by Bob Eager

Post by Wolfi
While we are at LVM, I just was going through your LVM pages at
http://www.tavi.co.uk/os2pages/lvm.html#CreateVol again, but didn't find the
info I was hoping for.
In LVM's <Logical View> -> <Create a new Volume> what exactly is the
difference between '... a volume that does not need to be bootable' and one
'... that can be made bootable'?

A volume that can be made bootable is always a compatibility volume. It
also appears in the boot menu automatically.

That was one of the snafus I had a problem with, because there was nothing
left for me to possibly 'make bootable'.
'Create a volume that will be bootable'.

No...it'll ony be bootable if you put an operating system on it. So it
reads correctly.

Post by Wolfi

Post by Bob Eager

Post by Wolfi
Is this IBM's confuscating way of communicating, that one will become a JFS
and the other one a volume with a traditional file system?

No. It is true that a compatibility volume cannot be a JFS volume. But
it is also the case that you can use FAT or HPFS on both kinds of
volume. This means that you can have FAT, HPFS, or JFS volumes spread
across multiple partitions and disks.

Then I just need to try to memorize, that I have to stick with the 'Create a
volume that does not need to be bootable', since this one is giving me all the
possible choices w/o confusing me with pretending to offer an option, when
actually already secretly doing it for me.

No, it's not. It doesn't secretly do anything except add it to a boot
menu.

[Wolfi]

Post by Bob Eager

Post by Wolfi

Post by Bob Eager

Post by Wolfi
While we are at LVM, I just was going through your LVM pages at
http://www.tavi.co.uk/os2pages/lvm.html#CreateVol again, but didn't find the
info I was hoping for.
In LVM's <Logical View> -> <Create a new Volume> what exactly is the
difference between '... a volume that does not need to be bootable' and one
'... that can be made bootable'?

A volume that can be made bootable is always a compatibility volume. It
also appears in the boot menu automatically.

That was one of the snafus I had a problem with, because there was nothing
left for me to possibly 'make bootable'.
'Create a volume that will be bootable'.

No...it'll ony be bootable if you put an operating system on it. So it
reads correctly.

Well, I considered this to be a required precondition in order to make sense
adding a volume to the boot menuin the first place ;-)

Post by Bob Eager

Post by Wolfi

Post by Bob Eager

Post by Wolfi
Is this IBM's confuscating way of communicating, that one will become a JFS
and the other one a volume with a traditional file system?

No. It is true that a compatibility volume cannot be a JFS volume. But
it is also the case that you can use FAT or HPFS on both kinds of
volume. This means that you can have FAT, HPFS, or JFS volumes spread
across multiple partitions and disks.

Then I just need to try to memorize, that I have to stick with the 'Create a
volume that does not need to be bootable', since this one is giving me all the
possible choices w/o confusing me with pretending to offer an option, when
actually already secretly doing it for me.

No, it's not. It doesn't secretly do anything except add it to a boot
menu.

Well, again, '... can be made' usually implies, that something is up to me to
make it happen.
But I also see your point of view in arguing. It's just that my intuition has
some problems in going along what my mind reads in this case ;-)

[Steven Levine]

In <ktPZh.110786$***@newsfe21.lga>, on 05/01/2007
at 05:48 PM, Wolfi <publicalfa-***@yahoo.fr> said:

Hi,

Post by Wolfi
In LVM's <Logical View> -> <Create a new Volume> what exactly is the
difference between '... a volume that does not need to be bootable' and
one '... that can be made bootable'?

There are a couple of differences. A bootable volume must in a location
that the BIOS can read at boot time and it must be a compatibility
volume.

In case of an LBA capable BIOS, this means the volume can be anywhere.

The compatibility volume requirement means that the volume must occupy a
contiguous area of the disk. A JFS volume can be composed of multiple
discrete areas spread over multiple drives.

The compatibility volume requirement exists only because no one has yet
built a boot loader that can handle JFS volumes. Note that a JFS volume
is not the same thing as a JFS formatted volume. Booting a JFS formatted
compatibility volume is no problem at all now that eCS includes the code
to support bootable JFS.


Regards,

Steven

[Steven Levine]

In <AALZh.84026$***@newsfe16.lga>, on 05/01/2007
at 01:23 PM, Wolfi <publicalfa-***@yahoo.fr> said:

Hi,

Post by Wolfi
Mmmh, why does FDisk/query on my W4 FP16+ system with kernel 14.104a then
still report "**BIOS:8032MB"?

Because fdisk does not know how to say anything else. Recall you are
working with fdisk which is designed for systems that can not boot beyond
the 1024 cylinder limit and that knows little about LVM or LBA addressing.

Here's the output of fdisk on the LVM-ed system I have in front of me.

[c:\showctrl\shl_wrk]oldfdisk /query /disk:1

Drive Name Partition Vtype FStype Status Start Size

1 0000003f : 1 0a 2 0 7
1 --> LVM C: 1 06 1 7 196
1 --> LVM D: 2 07 1 204 1168
1 --> LVM E: 2 07 1 1372 768
1 0042ec10 F: 2 07 0 2141 800
1 005becf6 : 2 00 0 2941 478
1 006ae0f3 G: 2 07 0 3420 494
1 007a5272 : 2 35 0 3914 6408
1 --> LVM H: 2 07 1 10323 6149
1 0202c773 K: 2 06 0 16472 1027
**BIOS:8032MB
**BIOS:8032MB
**BIOS:8032MB

The drive letters are what fdisk thinks they are, not what they are in
use, but that's to be expected.

The excess **BIOS:8032MB reports are for other drives. It appears fdisk
neglected to suppress them. This is a post-FP12 fdisk, so it has some
code that recognizes LVM data sectors, but it can not process them
correctly.

Here's what lvm has to say about this

[c:\showctrl\shl_wrk]lvm /query:bootable

Logical Volume Type Status File System Size (MB)
C: Vol C Compatibility Bootable FAT16 196
Disk Partition Size (MB) Disk Name
Part_C 196 D1 17GB
D: Vol D Compatibility Bootable HPFS 6149
Disk Partition Size (MB) Disk Name
Part D 6149 D1 17GB
E: Vol_E Compatibility Bootable HPFS 1168
Disk Partition Size (MB) Disk Name
Part E 1168 D1 17GB
F: Vol F New Compatibility Bootable HPFS 768
Disk Partition Size (MB) Disk Name
Part F Warp4 768 768 D1 17GB

It's a bit messy to correlate the fdisk and lvm volume letters, so here's
how dfsee sorts things out.

Id D A Dr Type Form Label info LVM vol,part B-cyl E-cyl Size MiB
-- - - -- ---- ---- ----------- ------------- ----- ----- --------
01 1 > P 0a BMGR I13X-aware ,[ BOOT MANAG 0 0 7.8
02 1 * C: P 06 FAT1 VOL_C Vol C,Part_C 1 25 196.1
03 1 * E: L 07 HPFS VOL_E Vol_E,Part E 26 174 1168.7
04 1 * F: L 07 HPFS VOL_F Vol F Ne,Part 175 272 768.7
05 1 K: L 07 HPFS VOL F 1_2MR Vol F 1.,Part 273 374 800.0
06 1 Free 375 435 478.4
06 1 L 07 HPFS VOL_F_OLD Vol F Ol,Part 436 498 494.1
07 1 H: L 35 JFS Vol_H Vol H,Part H 499 1315 6408.7
08 1 * D: L 07 HPFS VOL_D Vol D,Part D 1316 2099 6149.8
09 1 G: L 06 FAT SADUMP SADUMP,SADUMP 2100 2230 1027.5

Volume D: is well beyond the 8MB limit and boots just fine, regardless of
what fdisk says.

eCS/OS2 is a componet-based OS. You can mix and match things an usually
get away with it if you understand how the parts fit together.

As others have already said, to boot beyond you the 1024 cylinder limit,
you basically need the following

- a BIOS that supports the int13 extensions
- a master boot record that can detect the int13 extensions
- a boot manager that supports the int13 extensions
- a boot sector that that can detect the int13 extensions
- a boot loader that that can use the int13 extensions
- an .add driver that supports the int13 extensions

To boot a volume with lvm volume letters, you basicaaly need the following

- a bootmanager that understands lvm volume letters
- an os2ldr that understands lvm volume letters
- an os2dasd.dmd that os2lvm.dmd can attach to
- an os2dump that understands lvm or you may be unhappy
- an os2kernl that supports the KEE extensions

Steven

[Wolfi]

Post by Steven Levine
Hi,

Post by Wolfi
Mmmh, why does FDisk/query on my W4 FP16+ system with kernel 14.104a then
still report "**BIOS:8032MB"?

Because fdisk does not know how to say anything else. Recall you are
working with fdisk which is designed for systems that can not boot beyond
the 1024 cylinder limit and that knows little about LVM or LBA addressing.

But that's exactly what I expected from the update in IBM's ExtPart package!
That this FDisk is capable of probing the BIOS for extINT13 ability and if
available, removing the 1024cyl boot limitation....

Post by Steven Levine
Here's the output of fdisk on the LVM-ed system I have in front of me.

Is it a W4 system that you LVM-ed or FDisk run on a LVM system?

Post by Steven Levine
[c:\showctrl\shl_wrk]oldfdisk /query /disk:1
Drive Name Partition Vtype FStype Status Start Size
1 0000003f : 1 0a 2 0 7
1 --> LVM C: 1 06 1 7 196
1 --> LVM D: 2 07 1 204 1168
1 --> LVM E: 2 07 1 1372 768
1 0042ec10 F: 2 07 0 2141 800
1 005becf6 : 2 00 0 2941 478
1 006ae0f3 G: 2 07 0 3420 494
1 007a5272 : 2 35 0 3914 6408
1 --> LVM H: 2 07 1 10323 6149
1 0202c773 K: 2 06 0 16472 1027
**BIOS:8032MB
**BIOS:8032MB
**BIOS:8032MB

... and hence of course then also supressing that '**BIOS:8032MB' line.
What actually decode those numbers in the 'Status' column to? So far I
couldn't find any explanation for them yet.

Post by Steven Levine
The drive letters are what fdisk thinks they are, not what they are in
use, but that's to be expected.
The excess **BIOS:8032MB reports are for other drives. It appears fdisk
neglected to suppress them. This is a post-FP12 fdisk, so it has some
code that recognizes LVM data sectors, but it can not process them
correctly.

That's what I'm seeing here as well. Can you add on your system partitions to
the boot menu, which are beyond the 8032MB border?

Post by Steven Levine
Here's what lvm has to say about this
[c:\showctrl\shl_wrk]lvm /query:bootable
Logical Volume Type Status File System Size (MB)
C: Vol C Compatibility Bootable FAT16 196
Disk Partition Size (MB) Disk Name
Part_C 196 D1 17GB
D: Vol D Compatibility Bootable HPFS 6149
Disk Partition Size (MB) Disk Name
Part D 6149 D1 17GB
E: Vol_E Compatibility Bootable HPFS 1168
Disk Partition Size (MB) Disk Name
Part E 1168 D1 17GB
F: Vol F New Compatibility Bootable HPFS 768
Disk Partition Size (MB) Disk Name
Part F Warp4 768 768 D1 17GB
It's a bit messy to correlate the fdisk and lvm volume letters, so here's
how dfsee sorts things out.
Id D A Dr Type Form Label info LVM vol,part B-cyl E-cyl Size MiB
-- - - -- ---- ---- ----------- ------------- ----- ----- --------
01 1 > P 0a BMGR I13X-aware ,[ BOOT MANAG 0 0 7.8
02 1 * C: P 06 FAT1 VOL_C Vol C,Part_C 1 25 196.1
03 1 * E: L 07 HPFS VOL_E Vol_E,Part E 26 174 1168.7
04 1 * F: L 07 HPFS VOL_F Vol F Ne,Part 175 272 768.7
05 1 K: L 07 HPFS VOL F 1_2MR Vol F 1.,Part 273 374 800.0
06 1 Free 375 435 478.4
06 1 L 07 HPFS VOL_F_OLD Vol F Ol,Part 436 498 494.1
07 1 H: L 35 JFS Vol_H Vol H,Part H 499 1315 6408.7
08 1 * D: L 07 HPFS VOL_D Vol D,Part D 1316 2099 6149.8
09 1 G: L 06 FAT SADUMP SADUMP,SADUMP 2100 2230 1027.5
Volume D: is well beyond the 8MB limit and boots just fine, regardless of
what fdisk says.
eCS/OS2 is a componet-based OS. You can mix and match things an usually
get away with it if you understand how the parts fit together.
As others have already said, to boot beyond you the 1024 cylinder limit,
you basically need the following
- a BIOS that supports the int13 extensions
- a master boot record that can detect the int13 extensions
- a boot manager that supports the int13 extensions
- a boot sector that that can detect the int13 extensions
- a boot loader that that can use the int13 extensions
- an .add driver that supports the int13 extensions
To boot a volume with lvm volume letters, you basicaaly need the following
- a bootmanager that understands lvm volume letters
- an os2ldr that understands lvm volume letters
- an os2dasd.dmd that os2lvm.dmd can attach to
- an os2dump that understands lvm or you may be unhappy
- an os2kernl that supports the KEE extensions
Steven

[Wolfi]

Post by Bob Eager

Post by Wolfi

Post by Michael Lueck
I shudder at the thought of LVMizing Warp 4.

But in order to be able to boot additional OS' from my HDD, I must either try
this way or switch to something like AiRBoot, since I have to get beyond that
dumb FDisk-BM 8GB boot restriction.

It's not an FDISK restriction. It's a pre-FP13 restriction. Get the
diskettes updated to FP13 or later (preferably FP15) and it will go >
8GB. But I said that way back in the thread (I think).

Does FDisk 14.082/14.056 allow for anybody else with a W4 FP14(+) system, to
add a partition beyond the 1024cyl/8032MB limit to the boot manager menu?

Here it simply is not possible.

[Hendrik Schmieder]

Post by Wolfi

Post by Bob Eager

Post by Wolfi

Post by Michael Lueck
I shudder at the thought of LVMizing Warp 4.

But in order to be able to boot additional OS' from my HDD, I must either try
this way or switch to something like AiRBoot, since I have to get beyond that
dumb FDisk-BM 8GB boot restriction.

It's not an FDISK restriction. It's a pre-FP13 restriction. Get the
diskettes updated to FP13 or later (preferably FP15) and it will go >
8GB. But I said that way back in the thread (I think).

Does FDisk 14.082/14.056 allow for anybody else with a W4 FP14(+) system, to
add a partition beyond the 1024cyl/8032MB limit to the boot manager menu?
Here it simply is not possible.

AFAIK there doesn't exist any OS/2 fdisk version, which could install
a bootmanager version, which is capable of booting beyond 1024 cylinder.

For this you need a later LVM system.

Hendrik

[Wolfi]

Post by Hendrik Schmieder

Post by Wolfi

Post by Bob Eager

Post by Wolfi

Post by Michael Lueck
I shudder at the thought of LVMizing Warp 4.

But in order to be able to boot additional OS' from my HDD, I must either try
this way or switch to something like AiRBoot, since I have to get beyond that
dumb FDisk-BM 8GB boot restriction.

It's not an FDISK restriction. It's a pre-FP13 restriction. Get the
diskettes updated to FP13 or later (preferably FP15) and it will go >
8GB. But I said that way back in the thread (I think).

Does FDisk 14.082/14.056 allow for anybody else with a W4 FP14(+) system, to
add a partition beyond the 1024cyl/8032MB limit to the boot manager menu?
Here it simply is not possible.

AFAIK there doesn't exist any OS/2 fdisk version, which could install
a bootmanager version, which is capable of booting beyond 1024 cylinder.
For this you need a later LVM system.

That would be consistent with my recent findings and what I concluded so far.

It also would confirm, that some statements made by others about the late(st)
FDisk/BM in respect to its supposedly enhanced boot abilities apparently are
not true.

Wolfi

[Doug Bissett]

Post by Wolfi

Post by Hendrik Schmieder

Post by Wolfi

Post by Bob Eager

Post by Wolfi

Post by Michael Lueck
I shudder at the thought of LVMizing Warp 4.

But in order to be able to boot additional OS' from my HDD, I must either try
this way or switch to something like AiRBoot, since I have to get beyond that
dumb FDisk-BM 8GB boot restriction.

It's not an FDISK restriction. It's a pre-FP13 restriction. Get the
diskettes updated to FP13 or later (preferably FP15) and it will go >
8GB. But I said that way back in the thread (I think).

Does FDisk 14.082/14.056 allow for anybody else with a W4 FP14(+) system, to
add a partition beyond the 1024cyl/8032MB limit to the boot manager menu?
Here it simply is not possible.

AFAIK there doesn't exist any OS/2 fdisk version, which could install
a bootmanager version, which is capable of booting beyond 1024 cylinder.
For this you need a later LVM system.

That would be consistent with my recent findings and what I concluded so far.
It also would confirm, that some statements made by others about the late(st)
FDisk/BM in respect to its supposedly enhanced boot abilities apparently are
not true.
Wolfi

FDISK, as installed by FP14, or 15, will boot past the 1024 cylinder
limit, but you need to remove the old BM, and replace it, using the
new FDISK, to get it installed. You should also replace the old Master
Boot Record, by using the command FDISK /MBR (or is it /NEWMBR -
something like that anyway).

Hope this helps...

[Wolfi]

Post by Doug Bissett

Post by Wolfi

Post by Hendrik Schmieder

Post by Wolfi

Post by Bob Eager

Post by Wolfi

Post by Michael Lueck
I shudder at the thought of LVMizing Warp 4.

But in order to be able to boot additional OS' from my HDD, I must either try
this way or switch to something like AiRBoot, since I have to get beyond that
dumb FDisk-BM 8GB boot restriction.

It's not an FDISK restriction. It's a pre-FP13 restriction. Get the
diskettes updated to FP13 or later (preferably FP15) and it will go >
8GB. But I said that way back in the thread (I think).

Does FDisk 14.082/14.056 allow for anybody else with a W4 FP14(+) system, to
add a partition beyond the 1024cyl/8032MB limit to the boot manager menu?
Here it simply is not possible.

AFAIK there doesn't exist any OS/2 fdisk version, which could install
a bootmanager version, which is capable of booting beyond 1024 cylinder.
For this you need a later LVM system.

That would be consistent with my recent findings and what I concluded so far.
It also would confirm, that some statements made by others about the late(st)
FDisk/BM in respect to its supposedly enhanced boot abilities apparently are
not true.
Wolfi

FDISK, as installed by FP14, or 15, will boot past the 1024 cylinder
limit, but you need to remove the old BM, and replace it, using the
new FDISK, to get it installed. You should also replace the old Master
Boot Record, by using the command FDISK /MBR (or is it /NEWMBR -
something like that anyway).

Well, as already reported in the beginning, on my W4 box @FP level 16+ I
cannot use the FDISK_14.082de_FAT32_FP16.com, since it is messing up my boot
sequence due to its Fat32 awareness.
And if I didn't completely misunderstand Daryl Sperbers very detailed report
from 2002.08.05, about IBM's updates in EXPARTW4, even DaniDASD's drive-letter
reassignment abilities wouldn't let one get around the newly created drive
letter mess in existing set-ups.

So I still depend on the non-Fat32 aware version, which IBM offered a while
later on testcase, if memory serves right, which claimed to be at the same
level, but w/o the FAT32 awareness thingy for existing systems. And this one
definitely cannot go beyond 1024cyl, since this is the one, I still have to use.

Also, my experiments with FDISK_14.082de_FAT32_FP16.com on a test system,
didn't allow me to set-up anything outside that infamous 1024cyl boundary in
respect of boot manager accessibility, hence my conclusion, also that one
still has the limitation.

[Will Honea]

Post by Wolfi
cannot use the FDISK_14.082de_FAT32_FP16.com, since it is messing up my
boot sequence due to its Fat32 awareness.
And if I didn't completely misunderstand Daryl Sperbers very detailed
report from 2002.08.05, about IBM's updates in EXPARTW4, even DaniDASD's
drive-letter reassignment abilities wouldn't let one get around the newly
created drive letter mess in existing set-ups.
So I still depend on the non-Fat32 aware version, which IBM offered a
while later on testcase, if memory serves right, which claimed to be at
the same level, but w/o the FAT32 awareness thingy for existing systems.
And this one definitely cannot go beyond 1024cyl, since this is the one, I
still have to use.
Also, my experiments with FDISK_14.082de_FAT32_FP16.com on a test system,
didn't allow me to set-up anything outside that infamous 1024cyl boundary
in respect of boot manager accessibility, hence my conclusion, also that
one still has the limitation.

I know you've been fighting it, but this is a situation where LVM shines.
Set the drive letter with LVM and then forget about such madness as
physical order. FWIW, the machine I'm using at the moment has DOS, W2K (or
XP - depends on what I needed last), OS/2 MCP 4.52, eCS 1.2, eCS 2b4, and 2
different flavors of Linux. None has any problem with the LVM info in the
boot partitions and all boot from BootManager. There is always at least
one FAT16 partition on drive 0 and there may or may not be a FAT32
partition around - makes no difference so long as I don't mess up the
physical mapping Linux expects (Win and OS/2 happily stick with the logical
mapping I assign - Linux counts partitions as it knows nothing about drive
letters).

[Steve Wendt]

Post by Will Honea
physical mapping Linux expects (Win and OS/2 happily stick with the logical
mapping I assign - Linux counts partitions as it knows nothing about drive
letters).

However, you can use partition labels in Linux.

[Dave Yeo]

Post by Steve Wendt

Post by Will Honea
physical mapping Linux expects (Win and OS/2 happily stick with the logical
mapping I assign - Linux counts partitions as it knows nothing about drive
letters).

However, you can use partition labels in Linux.

Do you mean that under Linux if I have a partition labeled eg OS2 I can
access it with a pathname like //OS2/os2/dll/nameof.dll ? This is one
shortcoming of DOS (and OS/2 and Windows) that stuck out at me when I
migrated from the Apple // (ProDos) to IBM compatibles running DOS.
Under Prodos (forget the exact syntax now) you could enter a pathname
with slot and disk drive or start the pathname with the Volume label.
Most software used the Volume Label so you could move a program to a
different disk (800 KB or Ram drive) and as long as the volume name was
correct the software found itself and its data files fine.
IBM compatible DOS seemed quite limited being tied to the drive letter
instead of/and the Partition label.
Dave

[Steve Wendt]

Post by Dave Yeo

Post by Steve Wendt
However, you can use partition labels in Linux.

Do you mean that under Linux if I have a partition labeled eg OS2 I can
access it with a pathname like //OS2/os2/dll/nameof.dll ?

Not exactly; the partition has to be mounted, and that is not a valid
mount point. However, it can be mounted by referencing the partition
label in place of the partition number (i.e. /dev/sda5).

You can also arbitrarily define the mount point. So, you can have your
partition labeled OS2 mounted at /OS2, and access it with a path like
/OS2/os2/dll/nameof.dll

There's more info here:
http://wiki.linuxquestions.org/wiki/Fstab

[Hendrik Schmieder]

Post by Wolfi

Post by Michael Lueck
I shudder at the thought of LVMizing Warp 4.

But in order to be able to boot additional OS' from my HDD, I must either try
this way or switch to something like AiRBoot, since I have to get beyond that
dumb FDisk-BM 8GB boot restriction.

Two Points:

1) It is not really a 8GB boot restriction, but a 1024 cylinder
restriction, which is 8GB on your system.

2) Don't LVMizing Warp 4.
Instead install a MCP(2) based system and do all your partitioning
with the MCP(2) based system.

Hendrik

[Wolfi]

Post by Hendrik Schmieder

Post by Wolfi

Post by Michael Lueck
I shudder at the thought of LVMizing Warp 4.

But in order to be able to boot additional OS' from my HDD, I must either try
this way or switch to something like AiRBoot, since I have to get beyond that
dumb FDisk-BM 8GB boot restriction.

1) It is not really a 8GB boot restriction, but a 1024 cylinder
restriction, which is 8GB on your system.

You certainly are right here, but according to that kind of unofficial
industry agreement for newer HDDs, how they translate and present their true
capacity to the outside in terms of CHS values, those 1024cyl usually
correspond to 8032MB or roughly 8GB.

Wolfi

[Hendrik Schmieder]

Post by Wolfi

Post by Hendrik Schmieder

Post by Wolfi

Post by Michael Lueck
I shudder at the thought of LVMizing Warp 4.

But in order to be able to boot additional OS' from my HDD, I must either try
this way or switch to something like AiRBoot, since I have to get beyond that
dumb FDisk-BM 8GB boot restriction.

1) It is not really a 8GB boot restriction, but a 1024 cylinder
restriction, which is 8GB on your system.

You certainly are right here, but according to that kind of unofficial
industry agreement for newer HDDs, how they translate and present their true
capacity to the outside in terms of CHS values, those 1024cyl usually
correspond to 8032MB or roughly 8GB.
Wolfi

OK, let's calculate:

Cylinder : 1024
Heads : 63
sectors : 255
Bytes/Sectors : 512

If you multiply this you get 7,8 GB.
Remember 1 GB = 1024 MB = (1024)^2 KB = (1024)^3 bytes.

To your Fat32 problem :

Do you want to boot from a fat32 partition via boot manager or
is this the 05/0f partition type problem ?

Hendrik

[Jan van Wijk]

Post by Hendrik Schmieder
Cylinder : 1024
Heads : 63
sectors : 255
Bytes/Sectors : 512
If you multiply this you get 7,8 GB.
Remember 1 GB = 1024 MB = (1024)^2 KB = (1024)^3 bytes.

<pedantic hat on> :-)

No, 1Gb = 1000 MB = (1000)^2 KB = (1000)^3 bytes
And with this, the int13 limit is a little over 8GB ...

The binary based (1024 multiples) unit would be the GiB.

<pedantic hat off>



More and more companies and individuals dealing with disk-tools
are adopting this 'new' standard, and it helps ...


Excerpt from DFSTERMS.TXT:

+++++++++++
IEC units This describes a fairly new standard (IEC 60027-2, 1999) that
attempts to create an unambiguous naming system for quantities
used in (computer) systems that use the binary number system.

In the International Standard Units (SI) the prefixes K, M
and G are defined as powers of 10. Because the binary value
2^10 = 1024 is roughly the same as 10^3 = 1000, these same
prefixes were hijacked by the computer community for their
binary multiples as well.

Now that more people are starting to use computers, this causes
more and more confusion. In the disk-storage field this is most
visible with the capacity of harddisks. Disk manufacturers love
to use the decimal kind of Megabyte, because that gives them
the largest number to show for capacity ...

However, most software tends to use the 'binary' form of these
units and calculates a slighly lower number.

Example: If you buy a "30 GB" harddisk, and format that as one
big partition, your software will probably tell you that you
got a 27.9 GB partition. So where did those 2 GB go ?

Answer: Nowhere, 30GB is 30 000 000 000 bytes which is the
equivalent of 27.9 times 1 073 741 824 (2^30).

Now this will get easier once all software starts using the new
prefixes. In the above example the "GiB" prefix should be used.

An overview of the proposed prefixes and their values:

Analogous Short prefix
Factor Name Symbol Value SI prefix Relationship
====== ==== ====== ============== ============ ===============
2^10 kibi Ki 1 024 kilo (10^3) KiB = 1024 byte
2^20 mebi Mi 1 048 576 mega (10^6) MiB = 1024 KiB
2^30 gibi Gi 1 073 741 824 giga (10^9) GiB = 1024 MiB
2^40 tebi Ti 1 099 511 627 776 tera (10^12) TiB = 1024 GiB

b = bit B = BYTE

DFSee, starting with version 5.21 will uses the new prefixes in
all possible places and add a full-decimal value in bytes in
some selected places. KB, MB and GB values will be avoided.

For more info see:

http://www.pcguide.com/intro/fun/bindec.htm
or
http://physics.nist.gov/cuu/Units/binary.html

+++++++++++

Regards, JvW

[Wolfi]

Post by Hendrik Schmieder

Post by Wolfi

Post by Hendrik Schmieder

Post by Wolfi

Post by Michael Lueck
I shudder at the thought of LVMizing Warp 4.

But in order to be able to boot additional OS' from my HDD, I must either try
this way or switch to something like AiRBoot, since I have to get beyond that
dumb FDisk-BM 8GB boot restriction.

1) It is not really a 8GB boot restriction, but a 1024 cylinder
restriction, which is 8GB on your system.

You certainly are right here, but according to that kind of unofficial
industry agreement for newer HDDs, how they translate and present their true
capacity to the outside in terms of CHS values, those 1024cyl usually
correspond to 8032MB or roughly 8GB.
Wolfi

Cylinder : 1024
Heads : 63
sectors : 255
Bytes/Sectors : 512
If you multiply this you get 7,8 GB.
Remember 1 GB = 1024 MB = (1024)^2 KB = (1024)^3 bytes.

Yep, 8,225,280 byte, ÷1024 = 8023MB, ÷1024 = 7.844GB <== roughly 8GB ;-)

Post by Hendrik Schmieder
Do you want to boot from a fat32 partition via boot manager or
is this the 05/0f partition type problem ?

Neither the first nor the ext. partition 05/0F, but the FAT32 0B/0C type
issue, having suddenly pop up previously invisible logical FAT32 0B
partition(s) in front of the OS/2 boot drive.

[Michael Lueck]

Post by Hendrik Schmieder
2) Don't LVMizing Warp 4.
Instead install a MCP(2) based system and do all your partitioning
with the MCP(2) based system.

I successfully installed Warp 4 on a LVM partitioned disk. It was installed to the second Pri partition, following only Boot Manager.

I formatted the partition during the Warp 4 install, but did not let FDisk touch the disk.

So to that extent Warp 4 is happy on an LVM'ized disk.

[Hendrik Schmieder]

Post by Michael Lueck

Post by Hendrik Schmieder
2) Don't LVMizing Warp 4.
Instead install a MCP(2) based system and do all your partitioning
with the MCP(2) based system.

I successfully installed Warp 4 on a LVM partitioned disk. It was installed to the second Pri partition, following only Boot Manager.
I formatted the partition during the Warp 4 install, but did not let FDisk touch the disk.
So to that extent Warp 4 is happy on an LVM'ized disk.

I never meant to say that you shouldn't install Warp 4 on a LVM System.

What I meant was, that you shouldn't add LVM to an installed Warp4
system, by replacing the os2dasd.dmd, adding os2lvm.add etc.

Hendrik

[Paul Ratcliffe]

Post by Hendrik Schmieder
What I meant was, that you shouldn't add LVM to an installed Warp4
system, by replacing the os2dasd.dmd, adding os2lvm.add etc.

Why not? It's worked fine for me for years.

[Steven Levine]

Post by Paul Ratcliffe

Post by Hendrik Schmieder
What I meant was, that you shouldn't add LVM to an installed Warp4
system, by replacing the os2dasd.dmd, adding os2lvm.add etc.

Why not? It's worked fine for me for years.

Same here. :-)


Steven

[Hendrik Schmieder]

Post by Paul Ratcliffe

Post by Hendrik Schmieder
What I meant was, that you shouldn't add LVM to an installed Warp4
system, by replacing the os2dasd.dmd, adding os2lvm.add etc.

Why not? It's worked fine for me for years.

Because this configuration was never supported.
Use it at your own risk.

Hendrik

[Steven Levine]

Post by Hendrik Schmieder

Post by Paul Ratcliffe
Why not? It's worked fine for me for years.

Because this configuration was never supported.

Can you explain to us why this matters at this point in Warp4's life, or
end of life to be more specific.

Post by Hendrik Schmieder
Use it at your own risk.

That applies to using Warp4 on probably better than 50% of the boxes that
are currently running Warp4.

Steven