Reviewing partition info cause the system thought the partition table was changed

[Cynthia Qin]

1.Begin one installation;
2.Partition disk correctly;
3.Stop installation the "user add" and go back to review the partitional info;
4.Go back to "user add" and continue the installation;
5.Before the installation begin the base installation, rewriting partition table is required.

[Carlos Diener / emonkey (emonkey)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with latest Ubuntu release? Thanks in advance.

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

 We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

[Colin Watson (cjwatson)]

I have verified that this bug is still reproducible on current jaunty. (Any bug triager could have done this; the reporter's instructions are quite clear and it takes maybe ten minutes in a virtual machine. You should only ask reporters for more information when they have in fact not already given enough information.)

[Colin Watson (cjwatson)]

I think the problem here is that partman doesn't reset the "format this partition" state when you go back, so it always thinks it needs to reformat the partition. Actually this is quite bad.

[Colin Watson (cjwatson)]

The source of this is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256090 - while that's a valid bug, I think the approach taken to resolve it was too heavy-handed. Resetting "format this partition" to "keep existing data" would have been sufficient.

[Colin Watson (cjwatson)]

I have a couple of patches to partman-target to fix this, which I'm going to commit. However, after going back to the partitioner and forward again with these patches applied, I find that /target/cdrom is no longer mounted, which understandably rather confuses apt-setup. This is because partman-base unmounts everything under /target as the partitioner is starting up in order to avoid other problems, and nothing deals with putting the /target/cdrom bind-mount back unless you go through base-installer.

I'm tentatively opening a task on apt-setup for this, but this may not actually be where it's best to fix it. I'll investigate further.

[Launchpad Janitor (janitor)]

This bug was fixed in the package partman-target - 58ubuntu6

---------------
partman-target (58ubuntu6) jaunty; urgency=low

  * Rather than pretending that partitions have no longer been formatted
    after the partitioner is complete, reset their intended state from
    "format the partition" to "keep and use the existing data". This still
    solves the original problem reported in Debian bug #256090 while also
    stopping partitions from being needlessly reformatted if you go back to
    the partitioner after base system installation and then forward again
    (LP: #29712).
  * Don't clear partitions or complain about them not being formatted if
    they've already been formatted by a previous partitioner run.
  * Introduce partman/mount_style (choices: traditional, label, uuid) to
    allow controlling how filesystems are mounted. Default this to uuid, and
    stop using labels by default since they have unavoidable problems with
    removable disks (LP: #347817).

 -- Colin Watson <email address hidden> Fri, 27 Mar 2009 11:59:04 +0000