Indicates that the partition table will be modified on an otherwise untouched disk

[Matt Zimmerman]

Binary package hint: partman-auto

When using guided partitioning on a system with two disks, I selected the second disk for automatic partitioning. partman said that it would modify both the partition tables, but only listed specific changes affecting one disk. I went back, selected the free space for automatic partitioning, and it then listed pending changes to only one disk as expected.

I confirmed this with both 8.04 RC and with later dailies using the Kubuntu alternate amd64 ISO.

After the auto-resize operation completed on sdb, this is what I saw:

The partition tables of the following devices are changed:
    SCSI1 (0,0,0) (sda) <--- !!
    SCSI6 (0,0,0) (sdb)

The following partitions are going to be formatted:
    partition #6 of SCSI6 (0,0,0) (sdb) as ext3
    partition #7 of SCSI6 (0,0,0) (sdb) as swap

I tried to backup my MBR and compare it to see whether any changes were actually made, but I completely blew it and backed up the sdb MBR instead (which I was intentionally changing). I will attach /var/log/partman and /var/log/syslog which hopefully will be telling.

[Colin Watson (cjwatson)]

This is a bug, but it's also not an immediate cause for panic (despite the obvious unnervingness).

  /lib/partman/commit.d/45format_swap: IN: CREATE_FILE_SYSTEM =dev=sda 97000759296-100027630079 linux-swap
  parted_server: Read command: CREATE_FILE_SYSTEM
  parted_server: Note =dev=sda as changed

The installer automatically uses all the swap it can, and (annoyingly) it's more efficient to just create swap partitions from scratch (and put the previous UUID back afterwards) than to check whether they're valid. However, the CREATE_FILE_SYSTEM operation marks the partition table as changed, probably because it might change the partition type. The bug here is that CREATE_FILE_SYSTEM should only mark the partition table as changed if the new values it sets are different from those previously in place.

[Colin Watson (cjwatson)]

Upon further reflection I've completely misdiagnosed this problem. Of course CREATE_FILE_SYSTEM is only called when the partitioner is committing changes anyway, so this doesn't matter.

The real problem is that the perform_resizing function (a) calls commit.d scripts which operate on all disks (b) invokes the COMMIT operation only on the disk containing the partition being resized. An ideal solution would have the commit.d scripts operate only on the current disk, but that's tricky due to the interface involved. An acceptable solution would invoke the COMMIT operation on all disks.