Red Hat Bugzilla – Bug 102641
double-click in Disk Druid hard-drive layout locks up X
Last modified: 2007-04-18 12:56:58 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
Description of problem:
A simple double-click into the graphical hard-drive layout area at the top of
the Disk Druid screen locks up the X installer display reproducibly.
A single-click selects a partition. A double-click locks up X. Switching to
virtual consoles still works.
Steps to Reproduce:
1. Start installation.
2. In Disk Druid double-click (!) somewhere into the graphical partition layout
Actual Results: Graphical installer session locks up.
Expected Results: According to the installation guide, a double-click should
work as a way "to edit an existing partition or to create a partition out of
existing free space."
On the contrary, the partition table in the bottom half of Disk Druid works
It's the second drive here in that display. Both single-click and double-click
into 2nd drive's layout lock up X.
No such problems with layout of first drive.
Could you attach the output from 'fdisk -l ' for the drives in question? I've
never been able to reproduce this issue when reported so maybe if I can
duplicate you partitioning scheme that would help.
Created attachment 93917 [details]
fdisk -l /dev/hdb
The important discovery is, that in the bottom half of the Disk Druid screen I
can click/edit hdb's partition table without problems. Only clicking into the
graphical layout of the partition table of /dev/hdb locks up. Reproducibly.
Red Hat Linux 7.3 installer: NOT reproducible
Red Hat Linux 9 installer: reproducible
I was doing lots of clicking around in disk druid yesterday after testing doing
40+ partitions on one of my test boxes and I didn't have any problems. Do you
still see this with current code?
If so, which X server and what type of mouse?
You won't be able to reproduce it that way.
I can assure you it needs more than random clicking with an arbitrary partition
If it's not reproducible with the requested info from comment 3, I can't help
you any further. I would have provided more info if someone had asked for it
(e.g. "parted /dev/hdb print" output instead of fdisk) or had had any ideas.
For me to reproduce it (100%) with the affected installer versions, I had to
start an installation and when Disk Druid is displayed, the first click had to
be into the 2nd drive graphical partition slice thing at the top of the screen.
Instead of highlighting the clicked partition, it locked up. When I clicked
somewhere else before that, e.g. into the table at the bottom or on the 1st
drive layout, the lockup was not reproducible with subsequent clicks/double-clicks.
It smells as if the specific partition table is needed to reproduce it. Of
course, that depends on what the Disk Druid code does when it is clicked into
the graphical partition layout the first time.
Meanwhile--the report is almost two months old--the drive has been repartitioned
for a Red Hat Linux 7.3/8.0 build environment for fedora.us. If there are any
specific ideas I could try recreating the partition table on that drive for
additional tests. If I failed to reproduce it then, it would not rule out a bug
in Disk Druid, though.
The graphics adapter is Matrox Millennium G400 AGP. The mouse is an ordinary
Logitech serial mouse, 3-buttons.
Backed up hdb and recreated the partition table, but I'm unable to reproduce it
(even though it was really easy when I submitted the bug report). Could be that
the completely different partitioning on hda would need to be recreated, too,
which is impossible now. With the old constellation and old partitioning--which
this bug was about--hda had a partition table that created "partition alignment
warnings" (as described in bug 67981). Maybe that played a role.
I would need insight into what Disk Druid does to be able to comment on where it
could lock up theoretically (GUI event handling, partition slice rendering, any
things like that...).