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: | anaconda | Assignee: | 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
Michael Schwendt
2003-08-19 10:38:25 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. 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 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. 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...). |