Bug 102641 - double-click in Disk Druid hard-drive layout locks up X
double-click in Disk Druid hard-drive layout locks up X
Status: CLOSED DEFERRED
Product: Red Hat Linux Beta
Classification: Retired
Component: anaconda (Show other bugs)
beta1
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Michael Fulbright
Mike McLean
:
Depends On:
Blocks: CambridgeBlocker
  Show dependency treegraph
 
Reported: 2003-08-19 06:38 EDT by Michael Schwendt
Modified: 2007-04-18 12:56 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-10-16 16:56:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
fdisk -l /dev/hdb (511 bytes, text/plain)
2003-08-25 16:28 EDT, Michael Schwendt
no flags Details

  None (edit)
Description Michael Schwendt 2003-08-19 06:38:25 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.


How reproducible:
Always

Steps to Reproduce:
1. Start installation.
2. In Disk Druid double-click (!) somewhere into the graphical partition layout
display.
    

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."

Additional info:

On the contrary, the partition table in the bottom half of Disk Druid works
flawlessly.
Comment 1 Michael Schwendt 2003-08-19 06:52:01 EDT
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.
Comment 2 Michael Fulbright 2003-08-25 15:12:07 EDT
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.
Comment 3 Michael Schwendt 2003-08-25 16:28:45 EDT
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.
Comment 4 Michael Schwendt 2003-08-25 16:59:14 EDT
Red Hat Linux 7.3 installer: NOT reproducible

Red Hat Linux 9 installer: reproducible
Comment 5 Jeremy Katz 2003-10-16 14:16:50 EDT
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?
Comment 6 Michael Schwendt 2003-10-16 15:27:06 EDT
You won't be able to reproduce it that way.

I can assure you it needs more than random clicking with an arbitrary partition
table.

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.
Comment 7 Michael Schwendt 2003-10-16 16:56:13 EDT
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...).

Note You need to log in before you can comment on or make changes to this bug.