I have several old Dell Dimension 4100 workstations having 256MB RAM and 20GB disk drives all with operational Windows 2000 systems installed on FAT32 file systems allocated the entire disk. Most modern Linux distributions require at least 512MB of RAM and about 8GB of disk to install and run them successfully. I was delighted to hear of a modern Linux distribution that could install in less than 3GB and run in less than 256MB of RAM because a number of the machines were about half full of files that were advantageous to keep. If antiX could be installed on them they could all be made useful again without finding additional memory.

I have now successfully installed antiX-16 on two of them and am pleased with the system. However, after performing a manual dual boot repartitioning of the disk, neither would boot the original Windows 2000 systems that had been operational before the install.

The installation was performed in two steps. The first step was to clean up the FAT32 file system to free as much space as possible and then defrag them twice after running chkdsk. Once the FAT32 system had been prepared as described above, the antiX-16 ISO was run from a thumbdrive that was booted using the diskette image of plpbt R5.0.15 (this really does work well BTW). With antiX-16 booted live, gparted was used to"shrink" the FAT32 partition to about 10GB and configure swap and Linux partiitions before installing. No errors or failures of any kind were encountered during any of the above procedures. After antiX-16 was successfully installed, the system was rebooted immediately and the antiX recommended update procedures were successfully applied followed by another system reboot. After installing a few"missing" packages, the system was rebooted again this time selecting the Windows 2000 Professional option in Grub2 that had been automatically configured in the antiX-16 install. The Windows 2000 boot just sat there with a blank screen. Everything about the Grub configuration was in proper order but Win2k would not boot as it had before antiX-16 was installed.

The reason Win2k would not boot after the antiX-16 install is that the gparted utility in antiX-16 corrupts the microcode section of the boot sector and fills it with extraneous garbage from some unknown FAT32 directory (the jump instruction at the beginning of the boot sector is also corrupt) but both the BPB and the extended BPB have correct data from the partition reconfiguration in them. Both the primary and back-up FAT32 boot sectors were identically corrupt.

Getting Win2k to boot after the faulty antiX-16"shrinking" of the FAT32 file system required the use of 'dd' and 'xxd' in conjunction with 'vi' to paste correct microcode obtained from another machine into the boot sector. I am surprised, at this late stage in antiX development, that this kind of problem is being encountered installing a Linux distribution intended to be run on old hardware running existing software and would recommend, for the future of antiX, that someone discover the reason FAT32 boot sector corruption is occuring and fix the problem before more unsuspecting users lose access to their original Windows systems.

I was going to reply. Then thought better not. But what the heck.
Being familiar myself with Windows 2000 Pro SP4 enterprise edition < I have the cd >

My workaround on old kits is to use on floppy or cd

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://partitionlogic.org.uk/"
linktext was:"http://partitionlogic.org.uk/"
====================================


A good iso to keep on external hard drive as it takes up no space .

Resize Windows drives, fat32 even, then make sure everything boots before booting my AntiX cd.

Back then in those days. I was running AntiX 7. Using a even older version of gparted and a AntiX installer.

I don't hold much hope for accommodating fat32 Windows installations as the world has moved a long ways since then.
But I guess it don't hurt to ask.

Howdy and Welcome from the scooter tramp on this forum.

openmind wrote:The reason Win2k would not boot after the antiX-16 install is that the gparted utility in antiX-16 corrupts the microcode section of the boot sector and fills it with extraneous garbage from some unknown FAT32 directory (the jump instruction at the beginning of the boot sector is also corrupt) but both the BPB and the extended BPB have correct data from the partition reconfiguration in them. Both the primary and back-up FAT32 boot sectors were identically corrupt.

If the problem is due to the resizing then it is an upstream problem because we use a standard unmodified version of gparted. I did a quick Google and found these instructions:
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.howtogeek.com/howto/windows-vista/using-gparted-to-resize-your-windows-vista-partition/"
linktext was:"Using GParted to Resize Your Windows 7 or Vista Partition"
====================================
. It appears that when gparted resizes the partition it can move the physical location on the disk of the file \Windows\system32\winload.exe. The Windows boot loader relies on the physical location which is why you will need to repair Windows after resizing.

If this is what happened then I don't think there is much we can do to avoid putting users through this convenience.

Thanks for your reply. I like your R.P. Feynman quote. Although I've not tried the antiX install on a Win7 or Vista machine, they typically have NTFS file systems rather than FAT32. I've shrunk Win7 volumes and installed other Linux distributions on those machines without post install boot problems. I have had problems shrinking NTFS with a WinXP system not booting but that was because gparted didn't move the"hidden part-info sector" that WinXP writes on the last sector of the volume (I found a utility that fixes that--search"ntfsfixboot"). The problem described in this post applies to FAT32 file systems with Windows 2000 having the system installed in C:\winnt (there is no \Windows\system32\winload.exe file in Win2K and moving it in a Win7 or Vista volume wouldn't be a problem anyway as long as it can be located by the boot sector microcode). This problem much worse than moving the location of an existing file. It is about gparted corrupting the boot sector itself when shrinking FAT32 file systems. This really is a serious problem. Most ordinary users would have no idea how to determine what went wrong or how to recover even though the utilities to do so are right there in their antiX-16 system. Do distribution maintainers report these kinds of failures upstream or do ordinary users have to do it?

It would be much more efficient for you to report it directly because there is nothing useful we would add to the conversation. We would just waste our time and slow down the communication. It would be like a comedy sketch where two people aren't talking to each other so a third person has to repeat everything that gets said.

gparted corrupting the boot sector itself when shrinking FAT32 file systems

FWIW, there's no way it's an across-the-board"gparted resizing FAT32 smaller" problem.
I've done that (used gparted to resize FAT32 smaller) countless times without incident.

backstory:
At some point, unetbootinForWindows quit working (due to its outdated extlinux version) so I changed to using rufus (under winXP)...
...but rufus insists on formatting the entire target drive, so I'm resigned to firing up (g)parted to shrink the rufus-created FAT32 partition and to create additional (swap, et al) partitions.

FWIW, I haven't otherwise had a problem with gparted corrupting boot sectors installing other Linux distributions either. I did have a problem with it crashing during a Linux Lite repartitioning procedure but it didn't corrupt the FAT32 boot sector. The FAT32 boot sector corruption using gparted has only occurred with using the version in antiX-16 twice in a row. This makes me think there is something uniquely wrong with it in the antiX-16 ISO.

antiX-16 uses the gparted-0.24.0-1mx150+1 package which contains gparted-0.24.0. Debian Stretch has already upgraded to version 0.25.0-1. Versions below 0.26.0 are not even available in Gentoo stable. I suggest you make sure you are using the latest 0.25.0-1 version and see if the problem still exists. If not, then the bug was probably already found and fixed.

Please let us know if an upgrade fixes the problem because that might be a good reason for us to make an antiX-16.1 release.

Without testing it directly, I'm almost certain that the FAT32 boot sector corruption problem is a gparted 0.24.0 issue. I acquired five of these old Dell Dimension 4100 computers and have been working on them for a while. One already had an old version of FreeBSD on it so I reconfigured its networking parameters and left it alone (I removed its 256MB RAM SIMM so I could have the 512MB minimum to install Linux Lite 3.0 on two of the other four machines (moving it between them as necessary). One of the two that could accommodate Linux Lite had a completely corrupt HD that needed to be low-level initialized before it could be used and that, of course, wiped it completely clean--Lite was installed on the entire drive. The other machine could accomodate Lite because there was very little on it besides Windows 2000 Pro (very few apps and almost no user files). Linux Lite comes with gparted 0.25.0 and it does not corrupt FAT32 boot sectors. However, in the process of"shrinking" the 20GB Win2k partition, that version of gparted running on the live USB ISO crashed before it was finished and the FAT32 file system was left in a corrupted state. I used PartedMagic on"The Ultimate Boot CD R5.1.1" to fix it (it has gparted Release 0.9.0 if you can believe it). Apparently, gparted has introduced new"bugs" of one kind or another as development has progressed (R0.9.0 fixed the FAT32 file system corrupted by the unstable R0.25.0 and created the partitions used to install Lite 3.0 as well). The other two boxes (Dell 4100 Win2k machines) both had many apps and user files that were advantageous to keep so antiX-16 (that had just been released) was perfect for the task (it also has the latest kernel of any Linux distribution I've tried). Installing antiX-16 on those boxes led to this thread.

So, that's all five boxes and I don't have any more available to test with (I might be able to find something else to work with but it would take me a while). If I were you, I'd follow the Gentoo stable lead and go with gparted 0.26.0 if you can get it to run with the antiX kernel.