Return to Answer

If you can manage to boot the computer from a DOS floppy or some other device, you should be able to use the classic partitioning tool, Ranish Partition Manager. (I recommend version 2.40 or 2.44; neither unfortunately comes with source code, but they are considerably more flexible than 2.37, which does.) When you start the program, you will be presented with an interactive low-level(-ish) editor of the Master Boot Record, with the disk’s logical geometry (the one used with interrupt 0x13 services) displayed at the top. Any discrepancies the program detects will be highlighted in red.

If the disk contains FAT partitions you want to be able to boot from, you will additionally need to fix the geometry found within the boot sector’s BIOS Parameter Block. With RPM, this is also easy: select the partition entry and press ↵ Return to enter the BPB editor. As before, immediately press F2, then Esc to go back to the partition list. RPM will write the new geometry information into that partition’s BPB.

NTFS partitions also store the disk geometry in a very similar structure, but RPM is not able to correct it as easily. What you may try doing is: press Insert to temporarily change partition type to FAT (e.g. 0x06), then ↵ Return to enter the BPB editor, then as before, without changing anything, immediately save the BPB with F2, exit the BPB editor with Esc and change the partition type back to NTFS (0x07). This works because the layout of NTFS’s BPB is largely the same as FAT’s; at least its initial fields, which contain the geometry information. In my quick experiment in a VM, nothing other than the geometry fields was modified in the boot sector, so I expect it to be relatively safe. But if you want to be absolutely sure, you can use a hex editor instead.

Extended partitions (type 0x05) may pose more problems. The main difficulty with them is that MS‑DOS expects Extended Boot Records to be aligned on a cylinder boundary. If the EBR is not so aligned under the new geometry, MS‑DOS will not be able to access the logical drives correctly. The simplest way to address this, if you don’t mind the fact that it will make the logical drives unreadable under an OS older than MS‑DOS 7.0 (the one bundled with Windows 9x; equivalently, a clone like FreeDOS that happens to support the same feature), is to change the EBR’s partition type from 0x05 (‘Extended’ in RPM) to 0x0f (confusingly labelled ‘VFAT Extended LBA’, despite not having anything to do with FAT). Other than that, you might not be able to access the disk without re-partitioning it entirely.

If you can manage to boot the computer from a DOS floppy or some other device, you should be able to use the classic partitioning tool, Ranish Partition Manager. (I recommend version 2.40 or 2.44; neither unfortunately comes with source code, but they are considerably more flexible than 2.37, which does.) When you start the program, you will be presented with an interactive low-level(-ish) editor of the Master Boot Record, with the disk’s logical geometry (the one used with interrupt 0x13 services) displayed at the top. Any discrepancies the program detects will be highlighted in red.

If the disk contains FAT partitions you want to be able to boot from, you will additionally need to fix the geometry found within the boot sector’s BIOS Parameter Block⁰, and possibly the “hidden sectors” value as well, which is simply the LBA partition offset. With RPM, this is also easy: press F4 to switch to LBA view, then select the partition entry and press ↵ Return to enter the BPB editor. If the “Starting” value is highlighted in red, adjust it so that it agree with the partition table. Then press F2 to write the BPB, then Esc to go back to the partition list. RPM will write the new geometry information into that partition’s BPB.

NTFS partitions also store the disk geometry in a very similar structure, but RPM is not able to correct it as easily. What you may try doing is: press Insert to temporarily change partition type to FAT (e.g. 0x06), then ↵ Return to enter the BPB editor, adjust the “Starting” value if necessary, then, without changing anything else, save the BPB with F2, exit the BPB editor with Esc and change the partition type back to NTFS (0x07). This works because the layout of NTFS’s BPB is largely the same as FAT’s⁰; at least its initial fields, which contain the geometry information. In my quick experiment in a VM, nothing other than the geometry fields was modified in the boot sector, so I expect it to be relatively safe. But if you want to be absolutely sure, you can use a hex editor instead.

Extended partitions (type 0x05) may pose more problems. The main difficulty with them is that MS‑DOS expects Extended Boot Records to be aligned on a cylinder boundary (The Large Disk HOWTO warns about this.). If the EBR is not so aligned under the new geometry, MS‑DOS will not be able to access the logical drives correctly. The simplest way to address this, if you don’t mind the fact that it will make the logical drives unreadable under an OS older than MS‑DOS 7.0 (the one bundled with Windows 9x; equivalently, a clone like FreeDOS that happens to support the same feature), is to change the EBR’s partition type from 0x05 (‘Extended’ in RPM) to 0x0f (confusingly labelled ‘VFAT Extended LBA’, despite not having anything to do with FAT). Other than that, you might not be able to access the disk without re-partitioning it entirely.

⁰ I have rather mixed feelings about recommending this source. The description of the BPB structures found there is largely correct, although the author of that page imposes a few bizarre interpretations upon them, like insisting that decimal values 40 and 41 in the signature byte correspond to MS-DOS version 4.0 (which may or may not be true: there are no sources to confirm one way or another), lamenting that the BPB variant introduced with FAT32 uses the wrong value (up to writing a whole fanfiction standard correcting this)… and then going to say that hexadecimal value 0x80 found in NTFS BPBs somehow corresponds to a supposedly non-existent “MS-DOS version 8.0” (which does actually exist, kind of – it’s the DOS version number reported by Windows Me). Why not 12.8 instead, since hexadecimal 0x80 is decimal 128? So beware of that author’s strange pedantic fixations; they have led him astray before.

If you can manage to boot the computer from a DOS floppy or some other device, you should be able to use the classic partitioning tool, Ranish Partition Manager. (I recommend version 2.40 or 2.44; neither unfortunately comes with source code, but they are considerably more flexible than 2.37, which does.) When you start the program, you will be presented with an interactive low-level(-ish) editor of the Master Boot Record, with the disk’s logical geometry (the one used with interrupt 0x13 services) displayed at the top. Any discrepancies the program detects will be highlighted in red.

You may remember that the MBR defines partition boundaries using both CHS and LBA coordinates. As it happens, Ranish Partition Manager prefers using the LBA fields, and derives CHS coordinates from those. This means that, assuming the LBA fields are correctly filled, all you need to do to adjust the MBR for the new geometry is start RPM, immediately press F2 to write the MBR to disk, and exit. RPM will re-calculate the CHS coordinates from the LBA offsets stored in the partition table and the geometry it received from the BIOS.

If the disk contains FAT partitions you want to be able to boot from, you will additionally need to fix the geometry found within the boot sector’s BIOS Parameter Block. With RPM, this is also easy: select the partition entry and press ↵ Return to enter the BPB editor. As before, immediately press F2, then Esc to go back to the partition list. RPM will write the new geometry information into that partition’s BPB.

NTFS partitions also store the disk geometry in a very similar structure, but RPM is not able to correct it as easily. What you may try doing is: press Insert to temporarily change partition type to FAT (e.g. 0x06), then ↵ Return to enter the BPB editor, then as before, without changing anything, immediately save the BPB with F2, exit the BPB editor with Esc and change the partition type back to NTFS (0x07). This works because the layout of NTFS’s BPB is largely the same as FAT’s; at least its initial fields, which contain the geometry information. In my quick experiment in a VM, nothing other than the geometry fields was modified in the boot sector, so I expect it to be relatively safe. But if you want to be absolutely sure, you can use a hex editor instead.

Extended partitions (type 0x05) may pose more problems. The main difficulty with them is that MS‑DOS expects Extended Boot Records to be aligned on a cylinder boundary. If the EBR is not so aligned under the new geometry, MS‑DOS will not be able to access the logical drives correctly. The simplest way to address this, if you don’t mind the fact that it will make the logical drives unreadable under an OS older than MS‑DOS 7.0 (the one bundled with Windows 9x; equivalently, a clone like FreeDOS that happens to support the same feature), is to change the EBR’s partition type from 0x05 (‘Extended’ in RPM) to 0x0f (confusingly labelled ‘VFAT Extended LBA’, despite not having anything to do with FAT). Other than that, you might not be able to access the disk without re-partitioning it entirely.

If you can manage to boot the computer from a DOS floppy or some other device, you should be able to use the classic partitioning tool, Ranish Partition Manager. (I recommend version 2.40 or 2.44; neither unfortunately comes with source code, but they are considerably more flexible than 2.37, which does.) When you start the program, you will be presented with an interactive low-level(-ish) editor of the Master Boot Record, with the disk’s logical geometry (the one used with interrupt 0x13 services) displayed at the top. Any discrepancies the program detects will be highlighted in red.

You may remember that the MBR defines partition boundaries using both CHS and LBA coordinates. As it happens, Ranish Partition Manager prefers using the LBA fields, and derives CHS coordinates from those. This means that, assuming the LBA fields are correctly filled, all you need to do to adjust the MBR for the new geometry is start RPM, immediately press F2 to write the MBR to disk, and exit. RPM will re-calculate the CHS coordinates from the LBA offsets stored in the partition table and the geometry it received from the BIOS.

If the disk contains FAT partitions you want to be able to boot from, you will additionally need to fix the geometry found within the boot sector’s BIOS Parameter Block. With RPM, this is also easy: select the partition entry and press ↵ Return to enter the BPB editor. As before, immediately press F2, then Esc to go back to the partition list. RPM will write the new geometry information into that partition’s BPB.

NTFS partitions also store the disk geometry in a very similar structure, but RPM is not able to correct it as easily. What you may try doing is: press Insert to temporarily change partition type to FAT (e.g. 0x06), then ↵ Return to enter the BPB editor, then as before, without changing anything, immediately save the BPB with F2, exit the BPB editor with Esc and change the partition type back to NTFS (0x07). This works because the layout of NTFS’s BPB is largely the same as FAT’s; at least its initial fields, which contain the geometry information. In my quick experiment in a VM, nothing other than the geometry fields was modified in the boot sector, so I expect it to be relatively safe. But if you want to be absolutely sure, you can use a hex editor instead.

Extended partitions (type 0x05) may pose more problems. The main difficulty with them is that MS‑DOS expects Extended Boot Records to be aligned on a cylinder boundary. If the EBR is not so aligned under the new geometry, MS‑DOS will not be able to access the logical drives correctly. The simplest way to address this, if you don’t mind the fact that it will make the logical drives unreadable under an OS older than MS‑DOS 7.0 (the one bundled with Windows 9x; equivalently, a clone like FreeDOS that happens to support the same feature), is to change the EBR’s partition type from 0x05 (‘Extended’ in RPM) to 0x0f (confusingly labelled ‘VFAT Extended LBA’, despite not having anything to do with FAT). Other than that, you might not be able to access the disk without re-partitioning it entirely.

If you can manage to boot the computer from a DOS floppy or some other device, you should be able to use the classic partitioning tool, Ranish Partition Manager. (I recommend version 2.40 or 2.44; neither unfortunately comes with source code, but they are considerably more flexible than 2.37, which does.) When you start the program, you will be presented with an interactive low-level(-ish) editor of the Master Boot Record, with the disk’s logical geometry (the one used with interrupt 0x13 services) displayed at the top. Any discrepancies the program detects will be highlighted in red.

You may remember that the MBR defines partition boundaries using both CHS and LBA coordinates. As it happens, Ranish Partition Manager prefers using the LBA fields, and derives CHS coordinates from those. This means that, assuming the LBA fields are correctly filled, all you need to do to adjust the MBR for the new geometry is start RPM, immediately press F2 to write the MBR to disk, and exit. RPM will re-calculate the CHS coordinates from the LBA offsets stored in the partition table and the geometry it received from the BIOS.

If the disk contains FAT partitions you want to be able to boot from, you will additionally need to fix the geometry found within the boot sector’s BIOS Parameter Block. With RPM, this is also easy: select the partition entry and press ↵ Return to enter the BPB editor. As before, immediately press F2, then Esc to go back to the partition list. RPM will write the new geometry information into that partition’s BPB.

NTFS partitions also store the disk geometry in a very similar structure, but RPM is not able to correct it as easily. What you may try doing is: press Insert to temporarily change partition type to FAT (e.g. 0x06), then ↵ Return to enter the BPB editor, then as before, without changing anything, immediately save the BPB with F2, exit the BPB editor with Esc and change the partition type back to NTFS (0x07). This works because the layout of NTFS’s BPB is largely the same as FAT’s; at least its initial fields, which contain the geometry information. In my quick experiment in a VM, nothing other than the geometry fields was modified in the boot sector, so I expect it to be relatively safe.

Extended partitions (type 0x05) may pose more problems. The main difficulty with them is that MS‑DOS expects Extended Boot Records to be aligned on a cylinder boundary. If the EBR is not so aligned under the new geometry, MS‑DOS will not be able to access the logical drives correctly. The simplest way to address this, if you don’t mind the fact that it will make the logical drives unreadable under an OS older than MS‑DOS 7.0 (the one bundled with Windows 9x; equivalently, a clone like FreeDOS that happens to support the same feature), is to change the EBR’s partition type from 0x05 (‘Extended’ in RPM) to 0x0f (confusingly labelled ‘VFAT Extended LBA’, despite not having anything to do with FAT). Other than that, you might not be able to access the disk without re-partitioning it entirely.

If you can manage to boot the computer from a DOS floppy or some other device, you should be able to use the classic partitioning tool, Ranish Partition Manager. (I recommend version 2.40 or 2.44; neither unfortunately comes with source code, but they are considerably more flexible than 2.37, which does.) When you start the program, you will be presented with an interactive low-level(-ish) editor of the Master Boot Record, with the disk’s logical geometry (the one used with interrupt 0x13 services) displayed at the top. Any discrepancies the program detects will be highlighted in red.

You may remember that the MBR defines partition boundaries using both CHS and LBA coordinates. As it happens, Ranish Partition Manager prefers using the LBA fields, and derives CHS coordinates from those. This means that, assuming the LBA fields are correctly filled, all you need to do to adjust the MBR for the new geometry is start RPM, immediately press F2 to write the MBR to disk, and exit. RPM will re-calculate the CHS coordinates from the LBA offsets stored in the partition table and the geometry it received from the BIOS.

If the disk contains FAT partitions you want to be able to boot from, you will additionally need to fix the geometry found within the boot sector’s BIOS Parameter Block. With RPM, this is also easy: select the partition entry and press ↵ Return to enter the BPB editor. As before, immediately press F2, then Esc to go back to the partition list. RPM will write the new geometry information into that partition’s BPB.

NTFS partitions also store the disk geometry in a very similar structure, but RPM is not able to correct it as easily. What you may try doing is: press Insert to temporarily change partition type to FAT (e.g. 0x06), then ↵ Return to enter the BPB editor, then as before, without changing anything, immediately save the BPB with F2, exit the BPB editor with Esc and change the partition type back to NTFS (0x07). This works because the layout of NTFS’s BPB is largely the same as FAT’s; at least its initial fields, which contain the geometry information. In my quick experiment in a VM, nothing other than the geometry fields was modified in the boot sector, so I expect it to be relatively safe. But if you want to be absolutely sure, you can use a hex editor instead.

Extended partitions (type 0x05) may pose more problems. The main difficulty with them is that MS‑DOS expects Extended Boot Records to be aligned on a cylinder boundary. If the EBR is not so aligned under the new geometry, MS‑DOS will not be able to access the logical drives correctly. The simplest way to address this, if you don’t mind the fact that it will make the logical drives unreadable under an OS older than MS‑DOS 7.0 (the one bundled with Windows 9x; equivalently, a clone like FreeDOS that happens to support the same feature), is to change the EBR’s partition type from 0x05 (‘Extended’ in RPM) to 0x0f (confusingly labelled ‘VFAT Extended LBA’, despite not having anything to do with FAT). Other than that, you might not be able to access the disk without re-partitioning it entirely.