That's where the train comes off the tracks, as my gparted won't shrink a partition. Runs for a while, gives me an option for converting to FAT32 instead of FAT16, yada yada yada then BOOM! a box pops up saying I've found a gparted bug. So, no gparted shrink here. At least, not for a FAT16 partition. I haven't tried anything else because it's FAT16 I'm working with, so if it works with something else it matters not. Now, if this solution were as simple as dd'ing the first 170MB of the image, that would be great because there is only about 150GB ± of data but I suspect that all OSes put something at the end of a partition instead of just from the front forward so only copying the front will lose the back and render the image useless. Or do I have that wrong? Once your dos based fat16 disk is defragmented you will only have data at the back of the disk, all the executable's data is moved to the front of the data area. The disk is in this order first partition table then mbr the FAT (File alocation tables) then directories and file names then last of all the actual file data, which the defragmenter loads the important executable files first. The outermost data is generally text and such like. If you had the old dos norton disk doctor utilities, I found them on some mirror about a year and a half ago, you could first defrag the disk and manually shrink the partition using norton diskedit via rewriting
On 01/03/2017 17:40, Christopher Myers wrote: the mbr and partition table. I used to do it all the time once when the world was young. If I remember where the mirror was I'll post it. Best regards Dave P -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org