I have a quick question about parted. I doubt its a bug in parted itself; rather, it is more likely that I am simply using it incorrectly. :)
Okay, here goes: I use parted in a large bash script to automate a lot of tedious (and difficult using any tool that doesn't let me tell it a partition size in megabytes) partition manipulation. The process is as follows: 1. I receive a machine with a partition table containing Windows and a special "Recovery Partition." 2. I shrink the windows partition using ntfsresize and then go in using fdisk to recreate the partition layout. 3. At this point, the recovery partition still works no matter how I get in to it (via the BIOS option or using a GRUB CD to boot into it). 4. Another step comes through later and uses parted to fill in the remaining space with useful stuff; HOWEVER, for some reason, parted changes the original disk geometry parameters. For example: the disk originally had 240 heads, but after parted "touches" it, this gets changed to a value like 16. 5. At this point, Windows (hda1) will boot just fine. The recovery partition, (hda2), is no longer accessible using the BIOS's recovery mechanism--which, for IBMs, is the "Access IBM" button. Additionally, any attempt to "use" it results in the standard "Blue Screen of Death." Unfortunately, this is irreversible... no matter what I do, I cannot recreate the partition (using the original geometry constraints) to make the recovery work again. My question is: why is parted modifying these values? Is there an invocation that says: "don't touch the number of heads, etc." As it stands, parted seems to do what it wants to the geometry parameters (though, I'm sure smarter people than me wrote parted and have a good reason WHY they're doing it :) ), but it's seriously breaking the recovery partition. Anyone have any ideas? _______________________________________________ Bug-parted mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-parted
