• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

OS/2 Warp 4 + Virtual PC + 12 GB hard disk image = trouble! Help!

Started by ppgrainbow, 2010.08.01, 14:41:03

Previous topic - Next topic

ppgrainbow

Hey there! I'm new to the OS/2 World.com forums and I'm running into a bit of a problem attempting to get OS/2 Warp 4 properly recognise hard disk images larger than 8.4 GB under Virtual PC 2004.

I set up a virtual machine with a 12 GB hard disk image and allocated 128 MB of memory.

I used the modified installation diskettes from this website that allowed hard disks (and other media) larger than 8.4 GB (7.88 GB binary) to be recognised without problems. I even used the updated IBM IDEDASD with Intel Serial ATA and Parallel ATA controller support (idedasd.exe) dated 3 March 2004 and the updated kernel dated 26 October 2001 (internal revision 14.085_W4).

I also used a utility called Ranish Partition Manager 2.4 to attempt to resize the hard disk image to 12 GB in hopes that OS/2 Warp would recongise the whole drive. The Fixed Disk Utility (fdiskpm) reported that the hard disk has a capacity of 12,284 MB (11.99 GB). However, the Disk Space Monitor is reporting 7,857 MB (7.67 GB) free. Here is the example screenshot:

http://a.imageshack.us/img443/3166/os284gberror.png

Also, when I ran CHKDSK at the OS/2 Command Prompt, these are the results that I'm getting:

The current hard disk drive is: C:
The type of file system for the disk is HPFS.
The HPFS file system program has been started.
CHKDSK is searching for lost data.
CHKDSK has searched 100% of the disk.
   8225248 kilobytes total disk space.
      1076 kilobytes are in 357 directories.
    165413 kilobytes are in 4102 user files.
      1363 kilobytes are in extended attributes.
      2048 kilobytes are reserved for system use.
   8055346 kilobytes are available for use.


It seems that even if I patch the kernel and the drivers, OS/2 is still not properly recongising the hard disk image beyond the 8.4 GB limit.

How do I fix this to make OS/2 recognise the full 12 GB capacity on the hard disk image? :(

IBManners

Hi,

You will need replacement boot disks (first link)
http://www.os2site.com/sw/upgrades/upgrades.html

Dani's Drivers
http://www.os2site.com/sw/drivers/ide/index.html

Also found at Hobbes http://hobbes.nmsu.edu/ and a few other places

Info on Dani's drivers
http://www.os2site.com/sw/hardware/storage/ideinfo_dani.txt

Also http://www.xs4all.nl/~hrbaan/bootAble/ Bootable will give you some more info re creating a boto OS/2 CD.

Others I'm sure will join in with more info soon, its past my bed time :-)

Cheers
IBM
I am the computer, it is me.

Radek

I have run even W3 with 13 GB hard disk. You need Daniela's drivers (search Hobbes, OS2site and similar pages). You need to patch the first diskette (I think it's the first one - it should be FAT and it should contain the drivers being replaced) and update the CONFIG.SYS .

Download some older version of Daniela's drivers, I think version 1.6.x is okay. Download all related files. You will need ibm1s506.sys and os2dasd.dmd for sure and, perhaps, ibmatapi.flt . Do not download the newest versions of the driver, they are for eCS and I am not sure whether they will work with W4.

Patch the diskette. Two problems:
(1) Daniela's driver are often named dani*.* instead of ibm*.*, for example dani1s506.sys . Either rename the files to ibm*.* or update the config.sys on the diskette.
(2) Not enough free space on the diskette. You can delete tedit.exe along with all related files. Now, you should pass. tedit.exe is on the next diskette again.

Add SET COPYFROMFLOPPY=1 to the config.sys on the diskette. The installer starts with the files on the diskettes, then it installs the whole OS/2 and rewrites the files it started with so that your patches get removed during the installation and the result will be unsatisfactory. COPYFROMFLOPPY tells the installer that it should, after finishing the installation, copy the diskette files again so that your patches will not get lost.

warpcafe

Hi,

since I don't have enough experience (to be exact: no experience at all) with Virtual PC, I can only "guess" that the limitation for accessing anything beyond 8.4GB is either due to
- wrong OS/2 drivers (as you suspect) inside the VM
- wrong virtual machine setup (OS/2 can not deal with the "virtual controller" offered by VPC)
- VPC cannot handle OS/2 to see beyond 8.4 barrier at all

So question is: Did you already had this running successfully once? Or is it a first-try install?

Cheers,
Thomas
"It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that"
- G.H. Hardy

ppgrainbow

Quote from: warpcafe on 2010.08.02, 10:53:51
Hi,

since I don't have enough experience (to be exact: no experience at all) with Virtual PC, I can only "guess" that the limitation for accessing anything beyond 8.4GB is either due to
- wrong OS/2 drivers (as you suspect) inside the VM
- wrong virtual machine setup (OS/2 can not deal with the "virtual controller" offered by VPC)
- VPC cannot handle OS/2 to see beyond 8.4 barrier at all

So question is: Did you already had this running successfully once? Or is it a first-try install?

Cheers,
Thomas

I managed to solve it by creating, repartitioning and formatting a 24 GB hard disk image, then doing the XCOPY procedure by copying all of the files and directories to the larger drive. Here's a screenshot: http://a.imageshack.us/img186/8587/os224gbhdimage.png

The updated installation diskettes did fix the 8.4 GB limit. However, it might not handle hard disks larger than 64 GB.

RobertM

Quote from: ppgrainbow on 2010.08.02, 12:47:23
Quote from: warpcafe on 2010.08.02, 10:53:51
Hi,

since I don't have enough experience (to be exact: no experience at all) with Virtual PC, I can only "guess" that the limitation for accessing anything beyond 8.4GB is either due to
- wrong OS/2 drivers (as you suspect) inside the VM
- wrong virtual machine setup (OS/2 can not deal with the "virtual controller" offered by VPC)
- VPC cannot handle OS/2 to see beyond 8.4 barrier at all

So question is: Did you already had this running successfully once? Or is it a first-try install?

Cheers,
Thomas

I managed to solve it by creating, repartitioning and formatting a 24 GB hard disk image, then doing the XCOPY procedure by copying all of the files and directories to the larger drive. Here's a screenshot: http://a.imageshack.us/img186/8587/os224gbhdimage.png

The updated installation diskettes did fix the 8.4 GB limit. However, it might not handle hard disks larger than 64 GB.


Correct. Any disk being formatted HPFS or HPFS386 MUST be 64GB or under (OS/2 will not let you format it to any size greater than that anyway - you will either receive an error during format, or when attempting to format). And... any disk being formatted HPFS or HPFS386 SHOULD be 50GB or under (per mine and others' experiences) unless it will have very few files on it.

As a related note, picking a size greater than (roughly, from memory) 40GB or 50GB will make the format utility report weird things when formatting... for instance...
- (normal) 0% formatted
---(numbers skipped assuming quick format)*
- (normal) 49% formatted
- (normal) 50% formatted
- (normal) 51% formatted
---(numbers skipped assuming quick format)*
- (seemingly normal) 99% formatted
......(but wait! It's not done yet!!!)
- (not normal) 3% formatted (or some other number)
......(still formatting...)
- (not normal) 12% formatted (or some other number)
- Finally ends and reports proper free space and other statistics...

...ending at some arbitrary % and reporting the disk correctly formatted to the correct capacity. That has never caused any errors or usage problems for me, but it looks really strange when the format gets to 99% or so, then continues in the single digits and proceeds upwards to the early double digits.  I simply believe that IBM never fixed the format % calculation/display code to handle displaying format status for drives over that approx 50GB size.

Now, FAT of course has it's own limitations: 2GB partition, in the start of the disk, and decreased a tiny bit if BootManager is installed (or to be more technical, a bootable FAT partition MUST reside in either the first 1023 cylinders of the disk or the first 1024 cylinders of the disk).

Bootable JFS has even different limitations: (higher ones than FAT or HPFS/HPFS386), but does not come with OS/2 or the earlier versions of eCS.

SCSI setups may have different limitations as well: which may require (depending on how you have to set the SCSI BIOS and what drivers you are using) that the boot partition is in the beginning of the drive, and under 8GB or under (roughly) 7.8GB (if BootManager is installed). I've had that "issue" with various Adaptec and IBM (by LSI Logic or Adaptec) cards due to the card's INT13H (and other) settings, but it doesnt really matter to me... OS/2 always gets installed on it's own partition when I install it, and it doesnt need anything close to 8GB.

Best,
Robert

* Numbers between 2% and 48% and again from 52% to 99% will be "skipped" (or displayed too quickly to notice on most systems) during a quick format, as OS/2 and HPFS just need to verify and write the start partition area (beginning of partition or "disk"), end partition area (end of partition or "disk"), and the file table area (middle of partition) - thus, that is normal.



|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


ppgrainbow

Quote from: RobertM on 2010.08.02, 22:30:01
Quote from: ppgrainbow on 2010.08.02, 12:47:23
Quote from: warpcafe on 2010.08.02, 10:53:51
Hi,

since I don't have enough experience (to be exact: no experience at all) with Virtual PC, I can only "guess" that the limitation for accessing anything beyond 8.4GB is either due to
- wrong OS/2 drivers (as you suspect) inside the VM
- wrong virtual machine setup (OS/2 can not deal with the "virtual controller" offered by VPC)
- VPC cannot handle OS/2 to see beyond 8.4 barrier at all

So question is: Did you already had this running successfully once? Or is it a first-try install?

Cheers,
Thomas

I managed to solve it by creating, repartitioning and formatting a 24 GB hard disk image, then doing the XCOPY procedure by copying all of the files and directories to the larger drive. Here's a screenshot: http://a.imageshack.us/img186/8587/os224gbhdimage.png

The updated installation diskettes did fix the 8.4 GB limit. However, it might not handle hard disks larger than 64 GB.


Correct. Any disk being formatted HPFS or HPFS386 MUST be 64GB or under (OS/2 will not let you format it to any size greater than that anyway - you will either receive an error during format, or when attempting to format). And... any disk being formatted HPFS or HPFS386 SHOULD be 50GB or under (per mine and others' experiences) unless it will have very few files on it.

As a related note, picking a size greater than (roughly, from memory) 40GB or 50GB will make the format utility report weird things when formatting... for instance...
- (normal) 0% formatted
---(numbers skipped assuming quick format)*
- (normal) 49% formatted
- (normal) 50% formatted
- (normal) 51% formatted
---(numbers skipped assuming quick format)*
- (seemingly normal) 99% formatted
......(but wait! It's not done yet!!!)
- (not normal) 3% formatted (or some other number)
......(still formatting...)
- (not normal) 12% formatted (or some other number)
- Finally ends and reports proper free space and other statistics...

...ending at some arbitrary % and reporting the disk correctly formatted to the correct capacity. That has never caused any errors or usage problems for me, but it looks really strange when the format gets to 99% or so, then continues in the single digits and proceeds upwards to the early double digits.  I simply believe that IBM never fixed the format % calculation/display code to handle displaying format status for drives over that approx 50GB size.

Now, FAT of course has it's own limitations: 2GB partition, in the start of the disk, and decreased a tiny bit if BootManager is installed (or to be more technical, a bootable FAT partition MUST reside in either the first 1023 cylinders of the disk or the first 1024 cylinders of the disk).

Bootable JFS has even different limitations: (higher ones than FAT or HPFS/HPFS386), but does not come with OS/2 or the earlier versions of eCS.

SCSI setups may have different limitations as well: which may require (depending on how you have to set the SCSI BIOS and what drivers you are using) that the boot partition is in the beginning of the drive, and under 8GB or under (roughly) 7.8GB (if BootManager is installed). I've had that "issue" with various Adaptec and IBM (by LSI Logic or Adaptec) cards due to the card's INT13H (and other) settings, but it doesnt really matter to me... OS/2 always gets installed on it's own partition when I install it, and it doesnt need anything close to 8GB.

Best,
Robert

* Numbers between 2% and 48% and again from 52% to 99% will be "skipped" (or displayed too quickly to notice on most systems) during a quick format, as OS/2 and HPFS just need to verify and write the start partition area (beginning of partition or "disk"), end partition area (end of partition or "disk"), and the file table area (middle of partition) - thus, that is normal.



Thank you so much for the help. Although, I've used the updated installation diskettes to properly create hard disk images up to 64 GB without any problems, I'm gonna have to find ways to update the CD-ROM ISO to overcome the 2 GB, 4 GB, 7.88 GB and 64 GB limits respectively to overcome this frustration.

RobertM

Quote from: ppgrainbow on 2010.08.02, 23:34:10

Thank you so much for the help. Although, I've used the updated installation diskettes to properly create hard disk images up to 64 GB without any problems, I'm gonna have to find ways to update the CD-ROM ISO to overcome the 2 GB, 4 GB, 7.88 GB and 64 GB limits respectively to overcome this frustration.

Follow IBManners' tips below (here: http://www.os2world.com/forum/index.php/topic,2483.msg16473.html#msg16473) to figure out how to do that. The key is the Bootable program stuff (with of course, the updated files).

Other notes:
- The 2GB partition size limit is NOT able to be overcome for FAT partitions. It's simply the FAT spec and hardcoded into the OS/2 kernel.

- The 2GB file size limit that applies to HPFS/HPFS386 is not changeable. Use JFS if you need to save larger files.
-- That's the reason I use HPFS for the boot partition, and then create separate data and program partition(s) for everything else (and format them JFS)

- The 4GB limit does not apply to anything I can think of.

- The 7.8GB/8.4GB limit applies to:
-- Creating boot partitions with older versions of OS/2 - you already know how to resolve that
-- Creating boot partitions on SCSI media using certain controllers and setups - good luck with that one. I wouldnt bother trying to "fix" that.

- The 64GB partition size limit that applies to HPFS and HPFS386 is NOT changeable. Though both supposedly have the technical ability to support larger partition sizes (and possibly larger file sizes), this limit is hard coded into OS/2's HPFS/HPFS386's internal structures and is NOT changeable without the source code. Inotherwords, it isnt going to happen.
-- Thus, as with needing to store files greater than 2GB, use a JFS partition when partition sizes need to be greater than 64GB

Note: when wanting to use a JFS partition, create the partitions using LVM and do not select "compatibility/bootable partition" type. Then, format the partition using JFS.


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


Radek

A few minor notes :)

(1) The 2GB limit on FAT16 is given by number of entries in the FAT and the max size of a cluster. The limit is "physical" and cannot be changed any way.

(2) The 2GB file size limit in FAT or HPFS is given by a 32-bit file size field in the file directory data. The limit could be 4 GB if the operating system interpreted "negative file sizes" correctly. No operating system does this so that the limit is physical again. It cannot be changed within FAT or HPFS.

(3) The 8 GB limit for LBA is given by the max numbers of sector/track/cylinder data storable into a 24-bit field of int 13h calls and by the standard size of a data block on HDs (512 B). Overcoming this limit = using int 15h "extended calls". The limit is physical as far as LBA is concerned but you can run the HD in a "big disk" mode and support int 15h. This is exactly what Daniela's drivers do. Other possibility is bigger data block (a neccessity for contemporary terrabyte disks).
I have no experience with SCSI disks so that the sources of problems with them can be completely different.

RobertM

Quote from: Radek on 2010.08.03, 09:16:58
A few minor notes :)

(1) The 2GB limit on FAT16 is given by number of entries in the FAT and the max size of a cluster. The limit is "physical" and cannot be changed any way.

(2) The 2GB file size limit in FAT or HPFS is given by a 32-bit file size field in the file directory data. The limit could be 4 GB if the operating system interpreted "negative file sizes" correctly. No operating system does this so that the limit is physical again. It cannot be changed within FAT or HPFS.

Yes, sorry for the lack of clarification. The B+ Tree used can support larger files by it's design (7+GB), but the 32bit pointer structures, OTOH, cannot. Much like the partition size limit that is also hardcoded, even though HPFS was designed to handle 2TB partitions or larger. I had heard of some weird other implementation used on some other piece of IBM hardware and OS, or some hacked HPFS drivers or test drivers that did not have that limitation. Cannot recall which they were. They could have been some things IBM had been playing with when they were working on DSS for OS/2 (possibly the most likely scenario, as that would have given me exposure to it, as I was on the Beta Test and evaluation teams for DSS).


Quote from: Radek on 2010.08.03, 09:16:58
(3) The 8 GB limit for LBA is given by the max numbers of sector/track/cylinder data storable into a 24-bit field of int 13h calls and by the standard size of a data block on HDs (512 B). Overcoming this limit = using int 15h "extended calls". The limit is physical as far as LBA is concerned but you can run the HD in a "big disk" mode and support int 15h. This is exactly what Daniela's drivers do. Other possibility is bigger data block (a neccessity for contemporary terrabyte disks).
I have no experience with SCSI disks so that the sources of problems with them can be completely different.

In the ("problematic")SCSI implementations, the full disk size is supported, and LBA support for their sizes is implemented. Support for booting is provided by INT13H though, thus limiting the boot area to 8GB. This doesnt apply to all implementations, just many of the ones I have used (but those "many" have been "many" installations, on a small series of the same few card types). I have 300GB and larger SCSI "drives" (via RAID expanding across multiple drives for the "and larger" part), and the full drive is seen: by the controller, the RAID tools and the OS. I have also done SCSI (but) non-RAID setups that have had 147GB drive sizes, where the same applies.

From what I have read, this is a limitation in various SCSI controllers. Some, like the HP 5i allow selecting a 4GB or 8GB limitation for the boot partition, while others allow any size up to it's supported boot partition limit of either 2GB, 4GB or 8GB. Int13H boot support, I am guessing.

I suspect that in using the Int13h support for boot, the limitation exists there, but not for any other partitions or drive access (for instance, the Adaptec 7800 Series supports either 1GB or 8GB due to it's "standard" and "extended" Int13h support, but can still use/access the rest of the drive above those sizes (actually, the OS can)). Thus, the problem. After the boot process is started (and handed off to the OS), then the partition limitations are determined by the OS and it's drivers.


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


ppgrainbow

Quote from: RobertM on 2010.08.03, 00:13:57- The 64GB partition size limit that applies to HPFS and HPFS386 is NOT changeable. Though both supposedly have the technical ability to support larger partition sizes (and possibly larger file sizes), this limit is hard coded into OS/2's HPFS/HPFS386's internal structures and is NOT changeable without the source code. Inotherwords, it isnt going to happen.
-- Thus, as with needing to store files greater than 2GB, use a JFS partition when partition sizes need to be greater than 64GB

Note: when wanting to use a JFS partition, create the partitions using LVM and do not select "compatibility/bootable partition" type. Then, format the partition using JFS.

That means if I ever wanted to create a hard disk larger than 64 GB, I would have to format the drive using the JFS partition. Does the 64 GB limit apply to the whole hard disk or is it on a per partition basis?

If I'm correct, from what I've heard is that JFS is only available on OS/2 Warp v4.51 or later, meaning that OS/2 Warp 4 users will have to deal with hard disks and other media that are no larger than 64 GB in size.

Pete

Hi ppgrainbow

I have no idea if there is any reason why you cannot use JFS with Warp4 - other than Warp4 does not contain JFS.

If you want to try JFS maybe the package here will be of use http://www.os2site.com/sw/drivers/filesystem/jfs/jfs20040825.zip

The HPFS 64Gb size limit applies to partitions so you can partition larger drives for use with HPFS - I would suggest keeping HPFS partitions to around 50Gb as HPFS seems to "run out of steam" the closer it gets to the 64Gb limit.

Regards

Pete

ivan

Hi ppgrainbow,

First thing I would suggest is that you get the last fix pak  from the os2site and apply it - you should also get the device driver fix pak and the snap graphics package.

Now on to your question about drive sizes.  I have a couple of systems here that have two 500 GB drives in each.  One of these drives has a 2 GB HPFS partition for booting with the remainder divided into two JFS partitions, the other is just two JFS partitions.

We are now considering upgrading another of our systems to house three 1 TB drives that will be partitioned in a similar pattern.

One thing I must stress is that if you go down this route you will have to forget all about FDISK as it messes up the LVM information used by JFS.  I have some information about LVM but I can't check it at the moment as the box with it on is down waiting a new power supply.

ivan