partition customization ....how do I ???

Wed Mar 3 07:23:57 UTC 2010

On Tue, Mar 2, 2010 at 9:56 PM, Tim <ignored_mailbox at yahoo.com.au> wrote:
> One answer:  Use a command line tool, like fdisk, that does exactly what
> you tell it to, rather than a GUI tool which works in the manner it
> thinks best.

The very best tool for partitioning exactly the way you tell it to is
sfdisk.  Unfortunately it only works with Master Boot Record (MBR)
partition tables - the "Classic MS-DOS" partitions.  It doesn't work
at all with GUID Partition Tables (GPT), the Apple Partition Scheme,
BSD Slices and so on.  Just MBR.

But for MBR, it really is the very best tool.

Unfortunately it is a little tricky to use, so you would do well to
practice with a drive that does not contain any data at all.  It need
not be a rotating drive; a USB stick will work fine.  One can even
"partition" a regular file, just for practice.  You'll get a warning
message, but your "partition table" really will be written into that
file in the same way that it would be written to a physical disk.

There is an interactive mode for sfdisk.  Don't even try to use it -
it is the Cruel Shoes of partition table editors.

No, what makes sfdisk so cool is that it has the option of generating
a text file listing of your partition table, with the additional
option that that text file can be expressed in a format that is
machine-readible, so that you can apply a partiton map to any disk
just by reading that file back into sfdisk.

Further, it supports sector-level partition specifications.  The
finest granularity a partition offset and length can have is one
sector - 512 bytes on almost all regular rotating disks.  sfdisk
natively supports sector level addressing.  Some other partition tools
can do that, but either discourage it or are difficult to use if one
selects sector-accurate partitions.

Some partition tools enforce the "rule" that partitions must start on
a cylinder boundary, despite that fact that hard drive cylinders
haven't represented the physical geometry of drive platters for well
over ten years.  I think they enforce the cylinder rule for
compatibility with older operating systems like MS-DOS and Windows 95
that don't understand Logical Block Addressing.  Every modern
operating system, as well as every modern motherboard BIOS can handle
LBA natively, so it's really quite silly to have that cylinder rule
anymore.

See "man sfdisk".

To generate a machine-readible text file from your drive's partition map:

   # sfdisk -d /dev/sda > sda-mbr.txt

Replace "sda" with the device file for your entire hard drive.  "sda"
is for SCSI, SAS, USB, FireWire and SAS drives.  "hda" is for parallel
IDE.  "hda" is the first IDE drive, "hdb" is the second.

"-d" means "dump".  You can then edit sda-mbr.txt using your favorite
text editor.  To then apply the revised scheme to your drive:

   # sfdisk /dev/sda < sda-mbr.txt

You would do well to print hardcopies of the partition dump file for
all your drives, then tape them to the cases of each of your
computers.  Also copy the text files onto some backup medium, and keep
it in a safe place.

That is the real beauty of sfdisk: it only takes a few seconds to
completely restore a totally destroyed partition table!  There are
lots of ways that can happen, but most partition table editors are
completely unable to fix them.  With sfdisk, it only takes a few
seconds - provided you had the foresight to save the table dump files
ahead of time!

Totally wiping or utterly corrupting your partition table, despite
popular opinion, is in no way harmful to end-user data, so long as the
corruption only affects the table itself, and not the "payload" areas
of the partitions.  So long as that is the case, repairing a scragged
MBR will completely repair what most people would regard as an
unrecoverable drive.

Now, there is one other way to back up your MBR, but its usefulness
depends on your particular partition scheme:

   # dd if=/dev/sda of=sda.mbr bs=512 count=1

That will copy the Master Boot Record, which includes both the
partition table and the initial boot loader, into a 512-byte binary
file.   Note that any time you use dd on a physical drive - either the
whole drive device or a partition device, the "bs" - block size - must
be a multiple of 512.

To restore from that backup:

   # dd if=sda.mbr of=/dev/sda bs=512

This second method, of preparing a binary back of the whole boot
sector will work if you only have primary partitions.  If you have any
logical partitions, the "dd" method WILL NOT back up the logical
partitions - only the primary ones.  So use it only if you're quite
certain that you know what you are doing!

The reason is that the primary and extended partitions are specified
in a table towards the end of the first 512-byte sector on the drive,
but to allow for more than four partitions, the logical partitions are
written into a linked list that can span the entire drive.  sfdisk
will capture the logicals, but dd'ing the first sector will not.

I wrote a HOWTO a while back, that explains how to transfer a BeOS
installation from a physical disk partition into a disk image file
suitable for use with QEMU or VirtualBox.  I needed to do that because
QEMU doesn't know how to deal with the BeOS 5 Pro installation CD, so
my workaround was to install on a real drive, then transfer it into a
virtual disk image file:

    http://www.oggfrog.com/howto/emulators/

I mention this because my HOWTO beats the subject of cylinder-accurate
sfdisk completely to death.

Share and Enjoy!

Don Quixote
-- 
Don Quixote de la Mancha
quixote at dulcineatech.com
http://www.dulcineatech.com

   Dulcinea Technologies Corporation: Software of Elegance and Beauty.