Re: Wrong HDD Size
- Sorry for not answering it earlier, I did not pay attention to this list last week.
I kept the layout (since I am using a mail agent, not the web interface); if you cannot read the tables, try to cut and paste away from the web interface.
> > part -p > -r >part.logFine
> Ranish Partition Manager Version 2.40.00 February 08, 2001
> HD 1 (128) 8,063M [ 16,383 cyls x 16 heads x 63 sects = 16,514,064 sects ]AAAAH! So it is not "16MB" as you said at the beginning, but rather 16Ms, 16 millions of [512-byte] sectors! MUCH BETTER isn't it? :-)
First thing first, as you said elsewhere, the BIOS only handles up to 8GB. Either it is because it does not handle LBA addressing (a.k.a. MS/IBM INT13 extensions) at all, or because LBA addressing is (incorrectly) disabled (i.e. something like LARGE or Translated is enabled in BIOS setup.) You should search the web for more information, probably BIOS updates if at all possible, I am unable to help you further on this one.
Anyway this should not stop us (after all, Windows is booting, isn't it?)
This problem is quite well known BTW. It affects only BIOS i.e. booting or pre-boot tools like RPM or real-mode DOS, any decent OS like Windows98 is able to deal directly with the disk controller and access the full disk (even from a "DOS window".) The only restriction is that any file used for booting should be loadable by the BIOS.
The "safe" way to enable this is to have a boot or system partition reduced in size that is entirely below the 8GB barrier, and use the rest of the disk for another partition used only for data or similar.
The "unsafe" way is to have all the files below the mark (which happens automatically since the OS allocates the disk from the beginning), and hoping ("beting" is a better term; you might use "praying" as well) you never have any update or any reorganization of the disk ("defragmenting" etc.) which puts a required-for-booting file beyond the mark.
Of course, the nasty thing is that the "unsafe" way works like a charm, at least until it breaks (in an unrecoverable way)! So then the usual fix is to reduce the bigger partition to be smaller than 8GB, then creating another volume for data or whatever else.
Also with the "unsafe" setup you should refrain to use some fairly basic troubleshooting tools; for example, you cannot use scandisk from real mode MSDOS, since real mode DOS cannot access anything beyond the 8GB mark. The bad thing here is that Windows 98 boot process really LOVES to do just that when there is something wrong, "you did not stop the system as required and some of your datas might be corrupted" in the blue screen [so I will try to FIUBR :-(]...
Since you are going to use Linux, the evident thing to do is to reduce the FAT volume to be smaller than 8GB, to put the Linux filesystems beyond the mark, and set up Linux to boot up from the FAT filesystem (using LOADLINUX or SYSLINUX or whatever). The only requirement for Linux is to load the kernel (vmlinux) and the startup root filesystem (initrd or similar) from a BIOS-accessible volume; after that, Linux runs without BIOS help, so can access the High Lands.
You should research the web too, I am sure this setup is detailled (since it was quite common a few years ago.)
> Problems File Starting Ending PartitionHere you should check the disk datas, mainly that the "geometry" of the disk is 38,760×16×63. You said it was a 16GB (BTW, I did not know such a thing existed), yet it seems to be formatted as if it were a 20GB disk.
> v # Type Row System Type Cyl Head Sect Cyl Head Sect Size [KB]
> 0 MBR Master Boot Record 0 0 1 0 0 1 0
> 1 Pri Unused 0 0 2 0 0 63 31
> ! 2 >Pri 1 Windows FAT-32 LBA 0 1 1 38,759 15 63 19,535,008
When you will have shrink the volume to be smaller than 8GB, you should change it fstype to be 0B, "Windows FAT32" without LBA. I guess it would not harm (since Windows boot process test whether LBA is really available before using, and since here it is not it would behave as if the fstype is 0B anyway), but it is safer to not lie if it is not necessary; and as soon as the volume does not expand beyond the 8GB mark, it is unnecessary to use LBA to access it.
BTW there is no performance hit to put it one way or other, as long as the volume is below the 8GB mark.
> Partition table details:OK, this is the same as above.
> Problems Starting Ending Starting Number of Ending
> v # Type R FS Cyl Head Sct Cyl Head Sct sector sectors sector
> 0 MBR FF 0 0 1 0 0 1 0 1 0
> 1 Pri 00 0 0 2 0 0 63 1 62 62
> ! 2 >Pri 1 0C 0 1 1 38,759 15 63 63 39,070,017 39,070,079
> Problems with partition 2:RPM just says here it cannot check if the datas are in range, since the BIOS did not allow access to the beyond-8GB area (not even telling how large is the disk really.)
> Partition addresses are out of range
> Partition records exactly as they appear in MBR (EMBR):Fairly standard.
> Starting Ending Starting Number of
> # HD FS Cyl Head Sect Cyl Head Sect sector sectors
> 1 80 0C 0 1 1 1,023 254 63 63 39,070,017
> 2 00 00 0 0 0 0 0 0 0 0
> 3 00 00 0 0 0 0 0 0 0 0
> 4 00 00 0 0 0 0 0 0 0 0
> Detailed information about each partition:OK. Nothing wrong, apart from the fact this is an "unsafe" setup.
> --- Partition 2 ---
> Type: Windows FAT-32 LBA CHS=(0,1,1) 19,535,008 k 39,070,017
> Volume Label: NO NAME
> System id: MSWIN4.1
> File system: FAT32
> Cluster size: 16k (32s)
> FAT size: 4,768k
> Drive number: 128 Exp: 128
> Starting sector: 63
> Expected value: 63
> Number of sectors: 39,070,017
> Expected value: 39,070,017
So we have 16K clusters; right now there are 39,070,017 -32 -2×2×4768 = 39,050,913 data sectors, that is (÷32) 1,220,341 clusters of 16K each, that is (×4÷512) 9,534 sectors for each FAT (each entry is 4 bytes, and there 512 bytes/sector), rounded up to 9,536 by Windows (conservative) setup, which gives us (×2) the 4,768 above, so this is good.
The minimum size of the filesystem is 65,536 clusters (lower than that, it would be FAT-16), which is 1GB with 16K clusters (exactly 65,536×32 +32 +2×2×4768 = 2,116,256 sectors).
Since you said elsewhere you have about 1GB on the disk right now, and since you need some spare (to put Linux bootfiles and more importantly some spare space for Windows to run), you may try to resize down to 1.5GB or something like that (that is up to cylinder 3,000 in RPM).
So the target setup would be something like
: Starting Ending Starting Number of Ending
: # Type R FS Cyl Head Sct Cyl Head Sct sector sectors sector
: 2 >Pri 1 0B 0 1 1 2,999 15 63 63 3,023,937 3,023,999
: 3 Pri 2 xx 3,000 0 1 38,759 15 63 3,024,000 36,046,080 39,070,079
The 'xx filesystem' I have put above can be really anything, including a 0F extended partition for many logical partitions, or several (up to 3) primary partitions; in fact with Linux you probably will need at least two; the only point to keep in sight is that the partitions you create beyond the 8GB mark (cylinder #16,383) requires protected mode OS to be access without problem (and I refer to the END of the partition if you want to be safe and avoid the nasty problems I showed above.)
Also keep in mind that RPM would be unable to create logical partitions that begins beyond the 8GB mark, for the very same reason.
Back to our FAT volume, beyond modifying the MBR we should resize it in the file system "superblock" or "boot record" as well; this means adjusting the "number of sectors" size down to 3,023,937. Doing so will make any cluster beyond (3,023,937 -32 -2×2×4,768) ÷32 = 93,901 to became inaccessible, so you better check before that no file extends up to that point! This is where you are touching the limits of RPM: it would allow you to update the size in the boot record, but will not do any check anything about the actual FAT datas... On the other side, tools like fips or GNUparted or [a long list here, insert your favorite in your mind, but don't post advertising to the list please] DO check it, and some even allow you to "prepare" the volume by a specially crafted 'defragmentation', moving the clusters in the lower (safe) part of the volume.
At this point, I guess you have enough technical informations to decide for yourself. PLEASE do not use my maths blindly, they are here only for you to understand, I did not check anything so I can easily be wrong (and of course I do not assume any responsability in the case etc.)
I guess the best path to try is to have a look with the tools provided with the Linux distro you are going to install (since as I said this setup was common enough some years ago to warrant dedicated stuff in the installation process, and perhaps you could find helpful souls out there to help you.) If you are sure enough there are no data (of value) beyond cluster #93,900 you can use RPM to do the resize, then scandisk to check and fix the resized volume, but this is essentially a one-way path, there is not much security in case there is a problem; I very much prefer to use fips to do it (it does the same thing as RPM but does check there will be no lost files; OTOH fips is more limited than the other tools in that it is not able to move data; this makes it more safe to use, also ;-))
Hope it helps,