Indicates that the partition table will be modified on an otherwise untouched disk
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| partman-partitioning (Ubuntu) |
Triaged
|
Low
|
Unassigned | ||
Bug Description
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.
| Matt Zimmerman (mdz) wrote | #1 |
| Matt Zimmerman (mdz) wrote | #2 |
| Colin Watson (cjwatson) wrote | #3 |
| Changed in partman-auto: | |
| importance: | Undecided → Low |
| status: | New → Triaged |
| Colin Watson (cjwatson) wrote | #4 |
This is a bug, but it's also not an immediate cause for panic (despite the obvious unnervingness).
/lib/
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.