[Bug 45543] Re: Serious Data Loss resizing partitions

[billy at trigby.com]

I've now been able to recreate this bug on another system. The key seemed
be attempting to resize the 2nd partition on the disk; resizing /dev/hda1
worked every time for me; however, resizing /dev/hda2 resulted in a blank
error dialog (blank as in, GUI not responding to repaints) and then after
using window mgr to close error dialog, installer continued even though
resize failed. That's probably how my original disk got hosed.

I've saved my /var/log/installer/syslog and I also took a screenshot of
the error screen.  Do I attach these to the bug in launchpad? This list
probably doesn't want attachments right? :-)

Glad I was able to reproduce. Let me know what else I can do to help.

Cheers
Billy




> This bug can be confirmed now.
>
> Just tried an install with May 19 Dapper Live Daily build - same
> problem, a crash after resize.
>
> The worse is, I had already 2 partitions (swap and ext3), and didn't want
> to resize them (I had chosen to manually edit the partition table, but
> didn't change anything then just selected these two partitions to be
> formated (at no moment there was anything about a resize).
> Then after a click to continue, a windows pops up with sthg like
> "Resizing..."
> At the end of the resizing a window pops up saying " Installer crashed"
> Behind, the Installer window is still on and now says it's ready to
> install and it's going to format the two partitions.
>
> Strange is, the partitions have changed their numbers :
> Partition n° 10 became n°15 (swap)
> Partition n° 9 became n°14 (ext3)
>
> Another mistery is that partition /dev/hda9 (a 3 G ext3 partition) was
> /dev/hda13 under my previous (and still working just before I booted the
> Live CD) Dapper install.
>
> Here is the information after the crash :
>
> We're sorry; the installer crashed. Please file a bug report at
> https://launchpad.net/distros/ubuntu/+source/ubiquity/+filebug and a
> developer will attend to the problem as soon as possible. To help the
> developers understand what went wrong, include the following detail in
> your bug report:
>
>
> Traceback (most recent call last):
>   File "/usr/bin/ubiquity", line 120, in ?
>     install(sys.argv[1])
>   File "/usr/bin/ubiquity", line 54, in install
>     ret = wizard.run()
>   File "/usr/lib/python2.4/site-packages/ubiquity/frontend/gtkui.py", line
> 255, in run
>     self.process_step()
>   File "/usr/lib/python2.4/site-packages/ubiquity/frontend/gtkui.py", line
> 721, in process_step
>     self.mountpoints_to_summary()
>   File "/usr/lib/python2.4/site-packages/ubiquity/frontend/gtkui.py", line
> 974, in mountpoints_to_summary
>     if partman_commit.PartmanCommit(self).run_command(auto_process=True)
> != 0:
>   File "/usr/lib/python2.4/site-packages/ubiquity/filteredcommand.py",
> line 128, in run_command
>     self.start(auto_process=auto_process)
>   File "/usr/lib/python2.4/site-packages/ubiquity/filteredcommand.py",
> line 45, in start
>     self.db = DebconfCommunicator(PACKAGE, cloexec=True)
>   File "/usr/lib/python2.4/site-packages/debconf.py", line 125, in
> __init__
>     write=self.dccomm.tochild)
>   File "/usr/lib/python2.4/site-packages/debconf.py", line 48, in __init__
>     self.setUp(title)
>   File "/usr/lib/python2.4/site-packages/debconf.py", line 51, in setUp
>     self.version = self.version(2)
>   File "/usr/lib/python2.4/site-packages/debconf.py", line 60, in <lambda>
>     lambda *args, **kw: self.command(command, *args, **kw))
>   File "/usr/lib/python2.4/site-packages/debconf.py", line 81, in command
>     status = int(status)
> ValueError: invalid literal for int():
>
>
> ** Attachment added: "Syslog after the crash"
>    http://librarian.launchpad.net/2764961/syslog
>
> ** Attachment added: "partman after the crash"
>    http://librarian.launchpad.net/2764963/partman
>
> --
> Serious Data Loss resizing partitions
> https://launchpad.net/bugs/45543
>