crash while talking to gparted

I think I've just suffered the same problem - using Kubuntu Flight 7. The installer crashed when going from step 6>7 (after choosing to manually edit partitions...)

Output from the installer is:
Traceback (most recent call last):
  File "/usr/bin/ubiquity", line 112, in ?
    install(sys.argv[1])
  File "/usr/bin/ubiquity", line 52, in install
    ret = wizard.run()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/kde-ui.py", line 305, in run
    self.process_step()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/kde-ui.py", line 719, in process_step
    self.process_disk_selection()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/kde-ui.py", line 771, in process_disk_selection
    if self.manual_choice is None or unicode(choice, "utf-8") == self.manual_choice:
TypeError: decoding Unicode is not supported

My system is:
* AMD Athlon XP 1700+ ; 1Gb ram
* /dev/hda = ExcelStor J880 - 80Gb
*/dev/hdc = IBM Deskstar 80Gb (I think - code # is IC35L080AVVA07)

current partition setup is:
Using /dev/hda
(parted) print
Disk geometry for /dev/hda: 0kB - 82GB
Disk label type: msdos
Number Start End Size Type File system Flags
1 32kB 11GB 11GB primary ext3 boot
3 21GB 82GB 61GB extended
5 21GB 22GB 1077MB logical linux-swap
6 22GB 52GB 30GB logical ext3
7 52GB 82GB 30GB logical ext3
(parted) select /dev/hdc
Using /dev/hdc
(parted) print
Disk geometry for /dev/hdc: 0kB - 82GB
Disk label type: msdos
Number Start End Size Type File system Flags
1 32kB 82GB 82GB primary ext3
(parted)

Let me know if more info is needed...

Thomas, thanks for the report, but yours is a different bug, namely bug 43125; I fixed it on Friday. If you could default to filing new bugs for installer crashes rather than commenting on existing ones, I'd appreciate it; it's much easier to mark a bug as a duplicate than it is to untangle multiple different problems from a single bug report.

>If you could default to filing new bugs for installer crashes rather
>than commenting on existing ones, I'd appreciate it; it's much easier
>to mark a bug as a duplicate than it is to untangle multiple different
>problems from a single bug report.

So... you're actually saying I shouldn't check for previous reports of a possible bug I've found? Or do check for them, but file a new report anyway? All I'm saying it's not always easy for us 'simple users' to know for sure if we've found a duplicate or not. What's your advice on this?

You should still check for previous reports, but if there is any doubt at all that your bug is different you should file it separately. For example, two crashes are only the same bug if the backtraces are identical. If there is not enough information to determine whether the bugs are the same, it's better to file a duplicate than to risk having to disentangle multiple bugs out of one report later.

(There's some disagreement among the development team about this, so I can only really claim that the above applies to installer bugs. However, if you make a good-faith attempt to search for duplicate bugs, and note in any new bug reports that you think certain other bugs may be related, then I don't think too many people will complain.)

same here:
Traceback (most recent call last):
  File "/usr/bin/ubiquity", line 112, in ?
    install(sys.argv[1])
  File "/usr/bin/ubiquity", line 52, in install
    ret = wizard.run()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/kde-ui.py", line 305, in run
    self.process_step()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/kde-ui.py", line 719, in process_step
    self.process_disk_selection()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/kde-ui.py", line 771, in process_disk_selection
    if self.manual_choice is None or unicode(choice, "utf-8") == self.manual_choice:
TypeError: decoding Unicode is not supported

superstoned: That's a different bug, namely bug 43125, and is fixed in current daily builds. If the backtrace is not identical, it's generally a different bug.

I have an addition to make. After restarting the installer, althouhg the partitioning had actually been finished, there are black, "unknown" partitions there which are very hard to format again. I had to try several times. Even worse, changes made to them are not fully recognized in the next step when choosing the mountpoints. In detail:

I had started in the middle, so I had
hda 2: 6GB ext3
hda 1: 20GB ext2
hda 3: 1Gb swap
before the crash.

After the crash, I had
 6GB unknown
 20 GB unknown
 1 GB swap

Because I didn't like the order, I reformatted them as
hda 1: 6GB
hda2: 20 GB
hda3: swap

After the formatting the graphical partition display was blank and only reappeared after left-clickin on it.

When proceeding to the next step. I had still the old order (hda1 20GB and hda2 6GB) to choose from.

Going back, I saw that the formatting actually hadn't worked, there were black "unknown" partitions again.

I had to go through this four times, but now I have a perferctly running Dapper.

ubiquity (0.99.80) dapper; urgency=low

  * If we get an IOError when trying to tell gparted or qtparted to apply
    changes, just shut it down and try running it again (closes: Malone
    #43504, #44108).
  * Fix get_string to handle requests for fully-qualified debconf questions
    again.
  * Defend against progress_title being None in debconf_progress_start a bit
    harder.
  * Update Korean translation from Rosetta.

 -- Colin Watson <email address hidden> Fri, 12 May 2006 18:56:36 +0100