Created attachment 996345 [details]
photo of Manual Partitioning
Description of problem: The Manual Partitioning mount point list UI lacks a scroll bar, or some way to navigate and locate all partitions/LVs/subvolumes. So it's possible when there are even a dozen LVs, subvolumes, or partitions, the some of them can't be selected and therefore can't be modified, used, or removed.
Version-Release number of selected component (if applicable):
Server 21 TC 7
Always, as long as there are a sufficient number of any combination of LVs, partitions, or btrfs subvolumes, to cause the listing to be full and additional items are out of view.
Steps to Reproduce & Actual Results:
There are multiple ways to reproduce, including doing it only with partitions (GPT which allows up to 128 partitions), only LVM LVs, or only subvolumes. Or any combination thereof.
The attached photo and logs are the result of a disk with one XFS /boot and a Btrfs volume with ~10 subvolumes (snapshots) which causes the mountpoint listing to not show the XFS partition, and I have no way to scroll down to make it visible. Therefore I can't select that XFS partition to use it, modify it, or delete it. Many of the Btrfs subvolumes are also affected.
Some way for the list to show all partitions, LVs, and subvolumes.
Proposed as a Blocker for 22-beta by Fedora user chrismurphy using the blocker tracking app because:
When using the custom partitioning flow, the installer must be able to:
Correctly interpret, and modify as described below, any disk with a valid ms-dos or gpt disk label and partition table containing ext4 partitions, LVM and/or btrfs volumes...
-Remove existing storage volumes
-Assign mount points to existing storage volumes
Created attachment 996346 [details]
Created attachment 996347 [details]
Created attachment 996348 [details]
Created attachment 996349 [details]
The 21 in the Description "Server 21 TC 7" is wrong, I definitely tested 22 Alpha TC7 boot.iso.
+1 AlphaBlocker based on:
The user must be able to select which of the disks connected to the system will be affected by the installation process.
Weird, the scroll bar on the disk selection went away, too. Nothing has changed on anaconda's side as far those being ScrolledWindows, so reassigning to gtk.
We are doing overlay scrollbars which appear as you approach the edge.
We've just fixed a bug this morning where this didn't work because motion events were not selected automatically. That might be what you are seeing here. Fix will be in a release later today.
Alternatively, if you don't like overlay scrollbars, they can be turned off altogether with gtk_scrolled_window_set_overlay_scrolling
Discussed at today's blocker review meeting .
This bug was accepted as Beta Blocker - This bug is a clear violation of the beta criterion: "Correctly interpret, and modify as described below, any disk with a valid ms-dos or gpt disk label and partition table containing ext4 partitions, LVM and/or btrfs volumes..." and might have impact on other parts of the GUI of anaconda.
The fix I mentioend in comment 9 is included in 3.15.10
On a system with an input device (trackpad) that supports two finger scrolling, this is sufficiently fixed. The scroll UI is invisible but if I use two finger scroll it appears.
On a system without such an input device, I can't discover a way to scroll or cause scroll UI to appear, so at this point I'd say it's not fixed.
Created attachment 997993 [details]
works for me with gtk3-3.15.10-1.fc22.x86_64.rpm. Tried with both server and workstation to make sure there wasn't something gnome is/isn't doing vs. non-live, and both worked.
Created attachment 997994 [details]
I don't have a scroll UI though, and I have no idea how to activate it. Neither hovering over the border where it would be or clicking does anything. On the computer that supports two finger scrolling, just by trying to scroll with two fingers the scroll UI appears - I'm not clicking or pointing anywhere special.
The overlay indicator appears when you move the mouse over the widget or scroll it in some other way (keynav/touchpad/scrollwheel/touch). If you move the mouse close to the edge, it turns into an actual, full-width scrollbar.
If that doesn't happen for you, I suspect that you don't have gtk3 3.15.10, but still 3.15.9
I don't know whether that has anything to do with what gtk3 is used in the boot environment though; this is i686 boot.iso. I'll report back once there's another compose.
"mouse over the widget" what does this mean in the context of Anaconda's Manual Partitioning UI? I don't know what/where the widget is.
"some other way (keynav/touchpad/scrollwheel/touch)" the hardware in question has only a touchpad, and it doesn't distinguish two fingers for anything, it's as if there's one finger. It's circa 2003...
Yes, the package in the tree is what would've been built into the anaconda environment too. So is this issue still visible on some hardware with Alpha RC3?
(In reply to Adam Williamson (Red Hat) from comment #18)
Yes, with Workstation boot.iso, but this:
claims this version gtk3-3.15.9-1.fc22.src.rpm, which isn't the fixed version.
I know, I just wanted to confirm for Alpha docs.
Moving this to modified now... the alpha is out, and the bug is fixed in the current f22 build of gtk3.
if it's fixed in current stable 22 it can be marked fixed; cmurf, can you check with beta tc1 or tc2? thanks!
beta tc2 worksforme.
let's call it good, then.