PC MBR-style partition are _very_ often not sorted. It's the usual situation if you had some repartitioning without changing the whole disk structure (For example, changed only part of the disk) using *nix fdisk - it preserves old partion numbers in order not to screw OS booting (with MBR partition table, it's quite sensible thing to do....)
But it's not only Plan9's fdisk bug, IIRC Windows 2000 Server did the same to me (Or maybe it was something different), except that it only changed partition numbering to sorted - The only thing I had to was to boot from other medium and change /etc/fstab entries to match new numbers. On 5/5/06, Russ Cox <[EMAIL PROTECTED]> wrote:
> Is that the expected behaviour of plan9 fdisk? Not quite the expected behavior, but it's certainly believable. Fdisk assumes that it can pick up the partition table into its internal representation and then rewrite it from that internal representation without breaking anything. It never occurred to me that partitions might not be listed in order (in prep, which fdisk is based on, partition order is irrelevant and therefore always sorted!). I'm also not too surprised about changing the type of extended partition. That shouldn't matter, of course. Changing one of the partition sizes *is* surprising, since I tried very hard not to do that. PC disk partitioning is a giant mess. I've given up. If you think you can fix the bugs without introducing other problems, the source is in /sys/src/cmd/disk/prep/fdisk.c and I'd gladly accept a patch (see patch(1)). Thanks for the report. Russ
-- Paul Lasek
