Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 102641

Summary: double-click in Disk Druid hard-drive layout locks up X
Product: [Retired] Red Hat Linux Beta Reporter: Michael Schwendt <bugs.michael>
Component: anacondaAssignee: Michael Fulbright <msf>
Status: CLOSED DEFERRED QA Contact: Mike McLean <mikem>
Severity: high Docs Contact:
Priority: medium    
Version: beta1   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-10-16 20:56:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 100643    
Attachments:
Description Flags
fdisk -l /dev/hdb none

Description Michael Schwendt 2003-08-19 10:38:25 UTC
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 10:52:01 UTC
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 19:12:07 UTC
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 20:28:45 UTC
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 20:59:14 UTC
Red Hat Linux 7.3 installer: NOT reproducible

Red Hat Linux 9 installer: reproducible


Comment 5 Jeremy Katz 2003-10-16 18:16:50 UTC
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 19:27:06 UTC
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 20:56:13 UTC
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...).