Ubiquity shows "no partition table changes" warning despite selecting use entire disk

OK I completed a successful install with only the 80GB drive connected, choosing "entire disc". But I followed it with another install choosing to "resize and choose between OS's" and that install failed with the same error message. I reported that as a separate bug #556458 to hopefully collect all pertinent debugging info.

Just to be perfectly clear, I did not go to the live desktop prior to installing. When presented with the options of running or installing I chose to install. When presented with partitioning options I chose "resize and choose between OS's". From looking at Gparted I can see that the partitioning did complete, but I was still presented with that error message. I then Quit the process to let apport collect info.

So we know it's not limited to multiple drive systems. Also the first time I was presented with that error I had been running a Live session for a bit prior to trying to install, this was not the case in either the subsequent successful "entire disc" install or the failed "auto-resize" install.

Not sure if this is helpful or not, but since the partitioning had been successful I just chose to install again, choosing to use largest continuous space and I was once again presented with the same error message. But I decided to go ahead with the install since this drive is used solely for testing (nothing to lose) and the installation does appear to have been successful. I'm actually posting this message from that install after having rebooted into it.

This appears to be fixed in the recent rebuild. I first tried an "auto-resize" install with only the 80GB drive connected and it succeeded without error, so I then reconnected the 500GB drive to completely duplicate the original hardware layout.

Having chosen to "use entire disc" (/dev/sdb) I was presented with the proper review of installation specs on the final screen rather than the aforementioned error warning. I'll do a couple more tests later this PM to be sure.

I'm absolutely not able to duplicate this failure with the rebuild so I think this should be marked "fix released" but I think that should be the decision of whoever fixed it.

I do want to give a "hat tip" to those who nail these nasty bugs quickly and efficiently.

This bug is still present in the Beta 2 installer, even after running "update this installer".

The exact circumstances are using "Erase and use the entire disk" when the disk has no partition layout. If "Erase and use the entire disk" is selected when the disk already has partitions, then the correct breakdown of actions is displayed.

This is very much an edge case, since it's rare to install on a completely blank disk, EXCEPT in the case of Virtual machines for testing purposes (how I found it). This also probably explains why Erick was unable to reproduce the bug - once his disk had a partition table, the bug no longer appeared.

Alan, you may be correct but did you see my duplicate from before the rebuild? In that case I was using "auto-resize" where an Ubuntu OS already existed.

I'll revisit this in a few days when Colin Watson gets the new Casper uploaded to check on this unrelated bug:
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/539027

I do hope this can be fixed by the RC. It's at least good to know I'm not the only one having seen this behavior.

I just had this occur doing iso testing for the Lucid RC, a true exact duplicate of the original failure, that is installing to a blank 80GB drive.

Just FYI I quit that last install, pre-partitioned with Gparted, then completed a "manual" install successfully. That is it did not display that error, but rather displayed the proper "preview" info as expected.

Also duplicated the behavior in my previous duplicate report. That is, only one drive, chose to "auto-resize", that error presented itself rather than the proper "review" info, but since that's my testing drive I let the installation proceed and it succeeded.

I fear this could be a real problem for first timers trying to dual boot with Windows, and choosing the "default" auto-resize! I surely wouldn't want to tell someone to just ignore the message.

I think I've missed the boat for RC now, but I can reproduce this and will see if I can get it fixed for final.

This only happens in ubiquity (at least as far as I've been able to test so far), although the bug may be in code in partman-base that's just being exercised differently.

Oh, drat, no. It's the specialised code in ubiquity/scripts/summary. That will take a bit of massaging ...

Colin, I'll be glad to do as much testing as requested between now and final.

Erick: Thanks. I've missed the boat for RC now, but this should be in the first or second daily build after RC and before final.

I had this problem when I chose "Install side by side" too.

Colin, I also saw this when doing a manual installation in an attempt to reproduce bug 568024. Hopefully, your fix applies for that as well.

I'm glad others have noticed this. I'm unsure why I was unable to reproduce the scenario when I posted comment #5. I can assure everyone that I'll do a very thorough job of testing as soon as Colin gives the go ahead.

I'd also very much appreciate testing from everyone else interested.

This bug was fixed in the package ubiquity - 2.2.21

---------------
ubiquity (2.2.21) lucid; urgency=low

  [ Evan Dandrea ]
  * Honor user-setup/force-encrypt-home (LP: #566552).
  * Check for LTS in the release name (LP: #558488).
  * Hide the keyboard query dialog when we encounter an error parsing
    the keymap decision tree (LP: #553087).
  * Fix broken comparisons against boolean debconf values (LP: #567749).
  * Return with the correct state value when a keyboard map is found
    (LP: #553087).
  * Update translations from Launchpad.
  * Automatic update of included source packages: debian-installer-utils
    1.72ubuntu5, partman-auto 89ubuntu7, partman-base 139ubuntu6,
    partman-target 64ubuntu9, tzsetup 1:0.26ubuntu9, user-setup
    1.28ubuntu7.

  [ Colin Watson ]
  * Handle new partman/confirm_nooverwrite question properly (LP: #556373).

  [ Mario Limonciello ]
  * In OEM user config, don't change the last page's button to "Install"
    to avoid confusion.
 -- Evan Dandrea <email address hidden> Fri, 23 Apr 2010 09:32:43 +0100

Can anyone tell me if there will be any daily builds between now and iso testing for the final?

I did perform one test by booting the RC to live desktop and installing updates, and it does seem to be fixed, but I'd kind of like to try at least three more install scenarios to be sure.

Thanks in advance.

I have tried to reproduce this bug with the 04/26 daily build and can't so I owe a hat tip to Colin, Evan, and all involved. Looking good!