Created attachment 688875 [details] picture of manual partitioning in 'broken' state Description of problem: The MANUAL PARTITIONING screen will be incomplete, parts of it will be off-screen. Also parts of the MAIN HUB will be visible. Most of the time it is possible to "repair" the screen by selecting a partition and expanding the 'customize' tree, that sometimes will restore the screen. The 'finish partitioning' button will remain mostly off screen but will be clickable. If one is able to "repair" the screen, then MANUAL PARTITIONING will be possible. AUTOMATIC PARTITIONING looks good, while i did not use it, i found no issues while navigating those screens. Version-Release number of selected component (if applicable): F18 Release How reproducible: always Steps to Reproduce: 1. Boot and go to manual partitioning Actual results: broken screen, but it can be repaired by performing the action specified above. Expected results: normal screen Additional info: Tested on: EEE 701
Note that the anaconda UI was not designed for such limited screen space, and as such doing anything here is going to be very low priority.
Created attachment 692750 [details] kvm guest with forced 800x480 resolution showing MANUAL PARTITIONING in a 'broken' state
Created attachment 692756 [details] kvm guest with forced 800x480 resolution showing MANUAL PARTITIONING in a 'repaired' state I do believe that it not a design problem. Since the 'repaired' screen does fit ok, the issue looks like "just a bug". (whenever fixing it is easy or difficult is another issue).
I cannot test at this resolution, but I believe this bug will be fixed with the same patch as bug 907883.
Tested with 19 Beta TC4. It's still misrendered (though probably barely usable) at 800x480, though it's fine at 800x600. Screenshot attached.
Created attachment 746916 [details] screenshot of 19 Beta TC4 custom partitioning at 800x480
clumens: you can test at any arbitrary resolution by just passing it as a kernel parameter: "resolution=800x480". It works at least for VMs.
What qemu-kvm arguments do I need to pass to get it to accept that resolution? I can't run at anything smaller than 800x480 here. Please keep comment #1 in mind, though. The UI simply was not designed to run at this resolution and if this ends up being too much work, it'll end up as WONTFIX.
sure, I'm in favour of the campaign to locate and forcibly destroy all Eee 701s as well. Or at least make sure none of the awkward buggers who still owns one has access to dl.fedoraproject.org. :P I haven't tried passing anything smaller than 800x480; 800x480 just worked for me, in F19 virt-manager, no special configuration needed. I wouldn't bother testing at anything smaller myself, it's the smallest resolution anyone seems to use any more (and only on those annoying old Eees).
After digging into this a bit, I think the problem is the right hand side pane for configuring the mount point just contains too much stuff to fit into a screen 480px tall. And really, the only way I can fix that is to just wrap that side of the screen in a scrolled window that will appear as necessary. I could of course also redo the screen entirely, but I'm not going to do that. I think the scrolled window approach makes for a pretty terrible experience, and we've got to draw the line somewhere on what resolutions we can possibly support. I suggest using text mode or VNC for screens with such limited screen real estate, and I'm going to focus my bug fixing time elsewhere.
Marking as 'requires release note' - doc team, can we have the release notes specify 800x600 as minimum resolution for graphical mode, and advise use of text or VNC install on lower resolution devices (especially the Eee 7xx, which is 800x480)? Thanks!
Thanks for flagging this, Adam. I've added an admonition stating the cited 800x600 resolution as the minimum.