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