From: Mark Jarvis mark.jarvis@pvmail.maricopa.edu

HUH? FAT32 problem???

No, it's a geometry issue on legacy BIOS/DOS Disk Labels (Partition Table Format) aka "Basic Disc" in NT5+ (2000+) when both NT and Linux share the disk for booting.

Microsoft never standardized how geometry should be handled after NT4.0 Service Pack 4 (SP4) other than using legacy LBA32 -- i.e., always assuming Sectors/Heads of 63/255. In NT5+, this is what it does on a "Basic Disc" which cannot store geometry information, at least through NT5.1 (XP/2003) Service Pak 1 (SP1).

Unfortunately, assuming LBA32 is not compatible with Extended Int13h Disk Services. And for broken BIOSes, it can cause issues with 3rd party boot managers and disk utilities. This isn't an issue with using the Logical Disk Manager (LDM) Disk Label (Partition Table Format) aka "Dynamic Disc" because all NT5+ (2000+) instances on the system can read it's explicitly reserved areas and find out the exact geometry assumed by the first NT5+ install that created it.

The Linux kernel as of early 2.4.x, thanx to work done by the NTFS-LDM project, can also read this and not have to make any assumptions on geometry (which can be an issue with 2.6 and its standard support for Extended Int13h Services -- see below).

Microsoft has tried to address it with both some pre-NT5.1 Service Pack 2 (SP2) hot-fixes, some applied in SP2 and even more post-NT5.1SP2 hotfixes. Because the legacy BIOS/DOS Disk Label does not have a place where to reserve disk geometry, Microsoft choose part of Cylinder 0 where it's MBR doesn't reside. Unfortunately, many 3rd party boot managers, including GRUB, do use part of that space.

I've run into this first-hand where I had no problems dual-booting on even a 800GB disk array _until_ I upgraded to NT5.1SP2 (XPSP2). After the upgrade, GRUB was broken. After re-installing GRUB, it would no longer boot XP, because GRUB overwrote the hidden geometry info in Cylinder 0 that XP needed for boot-time support. After a few more systems, I discovered that XP only wrote it if the boot volume passed the 33.8GB (32GiB) barrier -- at least on my disks that were BIOS LBA32 geometry with Sectors/Heads of 63/255.

On newer disk arrays that break the 2.2TB (2TiB) barrier by supporting LBA48 / >255 heads, you _must_ basically use a LDM Disk Label. It appears Microsoft is not interested in any more "hacks" to support legacy BIOS/DOS Disk Labels -- especially given the fact that a lot of PC BIOS' out there are "broken" in their Extended Int13h Services and support for geometry beyond LBA32. In a nutshell, Microsoft doesn't trust anything from the PC BIOS, and expects to always rely on the geometry info in the LDM Disk Label for now on (and I don't blame them).

Linux kernel 2.6 was written to the ATA-6/LBA48 and Extended Int13h Services specifications to overcome the LBA32/2.2TB (2TiB) limit but is breaking all sorts of things in the process. Newer user-space tools like Parted and GRUB are now getting "more intelligent" in trying to apply what geometry to "assume" based on what kernel 2.6 gives them. It's no longer safe to blindly assume Sectors/Heads of 63/255, which is how 2.4 and earlier used to deal with dual-booting.

My system has two 120GB disks

I've typically found that as long as: A) I'm not dual-booting late NT5.1 hot-fixes/service packs (i.e., SP2+) B) I stay under LBA28/137GB (128GiB)

I don't have the issue, even when booting NT and Linux on the same disk.

and a 160 GB disk.

As long as it is not the booting disk, and being shared by both NT and Linux for booting, it shouldn't matter.

The 120s have a 1GB DOS, a 24+GB NTFS, and a 84+GB FAT32 partition. I keep (almost) all of my data in the FAT32 partition.

Are you dual-booting Linux on the _same_ disk?

The first 120 is (fairly) regularly cloned onto the second. Since I upgraded my BIOS, I have never had any trouble accessing anything in either of the big FAT32 partitions from either the XP installation or any one of the various Linux installations (CentOS, WBEL, SUSE, Fedora core 3, or Yoper) on the 160GB disk.

Then you're fine. As long as NT and Linux aren't sharing the same disk for boot, you'll typically have no issues. The Linux kernel, even more so 2.6, is pretty good at trying to figure out the geometry. It's only when booting that geometry can get screwed up, because you're at the mercy of the BIOS -- or a boot-loader that attempts to overcome it's limitations.

On a LDM Disk Label (Dynamic Disc), it can directly read the geometry assumed by NT.

On a legacy BIOS/DOS Disk Label (Basic Disc), it will try various geometries -- from legacy LBA32 to (in 2.6) full standard Extended Int13h Services geometry support. Unfortunately, NT5.1 doesn't support the latter (although more hot-fixes are attempting to).

At various times I have installed the NTFS code in a Linux installation, but when the NTFS crew's website says "read, but don't write" I believed them.

What I'm talking about is disk geometry issues. It doesn't matter if NTFS or FAT32 is used, you can run into it when you dual-boot on the same disc. Especially when you are dual-booting NT5.1 with late hotfixes / service packs.

In fact, I highly recommend using the LDM Disk Label (Dynamic Disc) on any NT5+ accessed disk to avoid geometry issues between NT5+ itself. Otherwise, I've seen people dual-booting 2000 and XP and seen the Disk Label (Partition Table) get trashed.

-- Bryan J. Smith mailto:b.j.smith@ieee.org