Re: fdisk, parted, problems and questions.
On Sat, May 20, 2006 at 09:45:02PM +0300, David Baron wrote:
> This is the "print" from fdisk from my linux disk:
> Disk /dev/hdc: 41.1 GB, 41110142976 bytes
> 16 heads, 63 sectors/track, 79656 cylinders
> Units = cylinders of 1008 * 512 = 516096 bytes
> Device Boot Start End Blocks Id System
> /dev/hdc1 * 65520 77600 6088635 83 Linux
> /dev/hdc2 1 65519 33021544+ f W95 Ext'd (LBA)
> /dev/hdc3 77600 79640 1028160 82 Linux swap / Solaris
> /dev/hdc5 1 38753 19531449 b W95 FAT32
> /dev/hdc6 38753 46504 3906250+ 83 Linux
> /dev/hdc7 46504 52704 3125000+ 83 Linux
> /dev/hdc8 52704 56579 1953125+ 83 Linux
> /dev/hdc9 56580 60455 1953125+ 83 Linux
> /dev/hdc10 60455 65519 2552603 83 Linux
> Partition table entries are not in disk order
> The disk orginally had another large vfat partition which as removed and more
> ext3 partitions placed which is why they are in this "order".
> When I first partitioned the disk and after I repartitioned it, the partitions
> were all 100% legal. They read into parted, qtparted, partitionmagic, etc. no
> problem. After a while (and I have had this problem a long time now), parted
> would no longer accept the disk. Complains of overlapping cylinder
> boundaries. Partitionmagic just calls is "bad". Obviously, I have been using
> these partitions without problems.
> Since I have a lot of extra space on my other disk (windows which I use much
> less now), I would like to make changes. First to fix this up. So.
> 1. How might I re-legalize the above partition table without starting over,
> 2. Is it better to have swap on a different disk (and IDE)--this is one of the
> changes I am thinking of?
> Thanks for any advice.
I haven't seen anyone else respond to this yet, so I will have a go...
The partition table format used on PC is old and clumsy, with plenty of
scope for redundent/conflicting information such that you can end up
with some partitioning programs producing things that other
partitioners or operatating systems object to...
Two common sources of problem I have found are partition tables that
are not in the same order in the table as the partitions are on disk,
and the location and size of the extended partition in the primary
partition table (some systems require the extended partition to be
the last primary partition, others will create and use it anywhere)
Another annoyance is that most partitioners will only let you see/specify
start and end cylinders, whereas the partition table contains both
head-sector-cylinder values, as well as logical sector numbers for
the start and extent of partitions. This means you cannot, for example,
swap the first and second primary partitions and keep the sizes the
same, because the first primary partition starts on the second head
so the first track is reserved for boot data.
And to add to the sillyness, the head-sector-cylinder values are fudged
to deal with modern media sizes - usually claiming the maximum values of
255 heads and 63 sectors per track, giving 16065 sectors per cylinder.
This is an odd number, so unless you use even numbers of cylinders,
you get a little '+' or '*' symbol next the partition to indicate
that not all of the space could be used.
The good news is that providing you keep the phyical start and end
addressed partitions the same, you can generally get away with removing
and rewriting the partition table without losing your partition contents.
I have done this several times, recently when one of the more modern
partitioners decided to shrink my 'extended' partition to match the
total of the sizes of the partitions initially created within - rather
than leave it using the rest of the space on the media. This meant that
even though I was ony using about a third of the disk, I could not create
any additional partitions after completing the install because the
extended partition was full...
The procedure I used to fix this was to print a hardcopy of the output of
'fdisk -l /dev/thedisk'
Then I delete all of the logical partitions using fdisk, then
delete the extended partition, recreate the extended partition
with the correct size, and finally add logical partitions with
exactly the same start and end cylinder numbers as the originals,
in the correct order. Remember that the logical partitions are stored
in a list, so if you delete a middle one, all the subsequent ones may
disappear as well (at least with a dumb partitioner).
To re-order your primary partitions, delete and recreate those
as well. However I would be prepared to re-install your MBR if you recreate
the first partition, depending on the partitioning program you are
When finished, list the partition information and verify that
the start and end cylinders really do exactly match the original
values for the partitions you are retaining.
Finally save the table (ignoring the warning about all data being
destroyed on changed partitions), reboot to ensure the updated
partition table has been read, and check your filesystems to
confirm that all data is still there.
In your case you appear to have gotten your logical partitions
at the start of the disk, with your extended partition in the
middle of your primary partition table, which would be a real
torture test for most partitioners, and is a testament to the
flexability of the Linux drivers that they can accept it.
I'd probably make the FAT32 partition your hdc1, then create
an extended partition for the rest, and add entries for each
partition in order. But hdc6 and hdc7 could be made primary
partitions also if desired.
If it doesn't work, you should be able to boot from a CD or floppy
and restore the partition table to its original state, as the
partitions themselves are not changed by modifying the table.
Of course I would never advise doing such a procedure unless everything
valuable had been backed up first - just in case.
If all else fails, the save way of doing this would be to just create
identically sized partitions on another disk and dd stuff across.
Then repartition the old drive from scratch.
Regarding the swap partition - I think the main idea is to distribute
the load. If you do a lot of swapping, then put the swap partition
on the drive with the least accessed partitions. Alternatively,
allocate a swap partition on each drive, and let the system
spread the load.
Digby R. S. Tarvin digbyt(at)digbyt.com