The tale starts with some laptops (IBM R40e) delivered with XP.

The plan was roughly as follows:

- resize the XP partition (to about 1/3rd of the disk)

- set up a Win32 partition of about the same size (can be accessed
from either operating system)

- install a version of SL into the remaining space.  We used SL301 at
first. We allowed the installer to autopartition the available free
space (the relevance of which may become clear later).

However, later on the users complained that the XP partition was too
small.  The only reliable tool I have for resizing an existing XP
partition (complete with contents) is Partition Magic (let's say
version 7.01 for example).

Unfortunately, when PM was booted up, it declared the partition table
to be corrupt (error #114) and refused to proceed.

I had installed in this way on several similar laptops, and they all
exhibit the same problem.  Attempting a re-installation of SL303 by
using the same procedures still produced the same problem.

I thought it might be helpful to run fdisk against the allegedly
corrupt partition table, to make some irrelevant change to it, and
then write the results back, hoping that fdisk might clean the table
up enough for PM - but no such luck, PM still reported error #114.

The only way I could get PM to do any work on the XP NTFS partition
was to delete all of the partitions which the linux installer had
created (*including* their enclosing "extended partition"), then I was
able to successfully re-size the NTFS partition, and re-install linux
as before (whereupon PM again declared the partition table to be
corrupt, of course).

A search on the web for the PM symptoms produced a suggestion that one
ought not to let the linux installer ("Disk Druid") get anywhere near
the partition table, but instead one should define the partitions by
hand beforehand, using linux fdisk, and then tell the installer to use
those existing partitions.

I've just tried that (booting knoppix from CD and using its fdisk
to define appropriate partitions - similar in size to what the
autopartitioning had produced before).

And now I can report that PM is quite happy with the resulting
partition table!!


So, it looks as if (at least according to Partition Magic's
expectations) the linux installer writes a defective partition table,
whereas using fdisk to assign partitions produced a good result.
(Possibly partition magic could be used for that task instead, I
didn't try it).

OK, that's where I'm up to.

----
Just a footnote to clear up a possible misunderstanding.

A colleague said to me "probably your version of Partition Magic
doesn't understand ext3 filesystems".  True enough - but it doesn't
have any relevance to the problems described above. PM never got as
far as considering the partitions themselves: it already walked out
after looking at the partition -table-.

And indeed, now that I've done the SL installation with a
pre-partitioned disk, PM7 is quite happy to display the partitions and
to allow me to resize NTFS and FAT32 partitions.  However, the linux
partitions are shown as ext2 (rather than 3) and the resize option is
greyed-out, confirming that this PM version doesn't support that.

I know how to handle that - on an earlier occasion I resized an ext3
filesystem using Partition Magic, by first running linux and using
tune2fs to remove the has_journal option.  Then resize with PM, and
then use tune2fs to put the journalling on again.  Sure, there are
other ways of dealing with that problem, but let's not get
side-tracked - I only wanted to make the point that PM's lack of
support for ext3 is not the cause of the chief problem that this mail
is about.

hope this is useful to somebody.  thanks.