Bug 869364 - Installation Destination screen is sometimes rendered not at full screen width
Summary: Installation Destination screen is sometimes rendered not at full screen width
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 19
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Chris Lumens
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
: 962994 965579 (view as bug list)
Depends On:
Blocks: F19-accepted, F19FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2012-10-23 17:12 UTC by Reartes Guillermo
Modified: 2013-12-18 19:08 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-18 19:08:01 UTC


Attachments (Terms of Use)
distorted manual partitioning screen (70.89 KB, image/png)
2012-10-23 17:12 UTC, Reartes Guillermo
no flags Details
distorted installation destination screen (67.80 KB, image/png)
2012-10-23 17:15 UTC, Reartes Guillermo
no flags Details
updated screenshot (69.46 KB, image/png)
2013-05-10 03:57 UTC, Reartes Guillermo
no flags Details
Screenshot of an extreme case (46.51 KB, image/png)
2013-05-12 16:46 UTC, Adam Williamson
no flags Details
screenshot of the bug being reproduced even with clumens' patch (47.30 KB, image/png)
2013-05-15 21:37 UTC, Adam Williamson
no flags Details
anaconda log from update.img from #33 (2.05 KB, text/plain)
2013-05-24 09:10 UTC, Vojtěch Boček
no flags Details
packagin.log from update.img from #33 (10.89 KB, text/plain)
2013-05-24 09:10 UTC, Vojtěch Boček
no flags Details

Description Reartes Guillermo 2012-10-23 17:12:31 UTC
Created attachment 632226 [details]
distorted manual partitioning screen

Description of problem:

Distorted, abnormal looking MANUAL PARTITIONING SCREEN.
See screen-shot.


Version-Release number of selected component (if applicable):
F18b TC6

How reproducible:
on very rare occasions, involving complex actions which are either very difficult to remember or impossible. (too many steps).

Steps to Reproduce:
unknown
  
Actual results:
graphical aberration, glitch.
It does not seem to affect the functionality.

Expected results:
normal looking screen

Additional info:

Comment 1 Reartes Guillermo 2012-10-23 17:15:15 UTC
Created attachment 632227 [details]
distorted installation destination screen

The main hub and the other areas are ok.

Comment 2 Vratislav Podzimek 2012-10-24 11:08:50 UTC
This happens to every spoke sometimes and I'm quite sure there exists a bug for this issue. I just cannot find it right now.

Comment 3 Chris Lumens 2012-11-13 18:46:41 UTC
I can reliably reproduce this on the installation destination spoke with anaconda-18.28 like so:

(1) Start with two blank disks (contents of the disks may not matter, but I'm being thorough here).
(2) Select both disks.
(3) Hit continue, accepting LVM as the default, and then hit continue again.  You don't need help.
(4) You are returned to the hub.
(5) Go back into the installation destination spoke, making sure both disks are still selected.
(6) Hit continue, change to Standard Partition by default, and then hit continue again.  You still don't need help.
(7) Go into the installation destination spoke a third time.  Bam, shrunken UI.

Comment 4 Chris Lumens 2012-11-14 15:26:41 UTC
We have what I hope is a potential fix for this with 57e284db4a1d1a1b7f7923a19681dec51660cb40.  Of course, I cannot reproduce it today for sure so I do not know but that patch should be fine on its own and maybe with some more broad testing, we can be sure.

Comment 5 Chris Lumens 2012-11-14 15:27:18 UTC
Note:  there's also a patch for the custom partitioning screen.

Comment 6 Reartes Guillermo 2012-12-07 22:41:31 UTC
I have seen it (image in my comment #1) with 20121205_f18-smoke4.

I don't know if comments #4, #5 do apply to 20121205_f18-smoke4.

Comment 7 Adam Williamson 2013-05-10 03:36:47 UTC
Reartes, have you still seen this issue with F18 final / F19 composes?

Comment 8 Reartes Guillermo 2013-05-10 03:54:40 UTC
Yes, but only in the Installation Destination. (attachment from comment #1).

Regarding Custom Partitioning, no, it does not happen anymore on that screen.

Comment 9 Reartes Guillermo 2013-05-10 03:57:23 UTC
Created attachment 745884 [details]
updated screenshot

Comment 10 Adam Williamson 2013-05-10 06:28:03 UTC
I've seen Installation Destination come up about 60% of the width of the screen a few times in F19 testing, yeah. Not sure what causes it. It's kind of 'cleanly' rendered in that space though, not distorted exactly...

Comment 11 Adam Williamson 2013-05-12 16:45:48 UTC
I just saw a fairly extreme version of this happening while I was fiddling about with keyboard layouts in a Polish install to try and reproduce https://bugzilla.redhat.com/show_bug.cgi?id=895766 . Screenshot attached. So this bug can render the screen virtually useless at times.

Comment 12 Adam Williamson 2013-05-12 16:46:16 UTC
Created attachment 746914 [details]
Screenshot of an extreme case

Comment 13 Adam Williamson 2013-05-12 16:49:34 UTC
Let me see if I can remember the reproducer there:

1. Start with a VM with a single disk with an F19 install on it
2. Boot Beta TC4 installer, select Polish language
3. Go to keyboard spoke, add English (UK) layout, arrange the layouts in the order Polish, English UK, English US, alt-shift till US is current layout
4. Go to Installation Destination spoke, hit Done, check the 'encryption' box, hit Reclaim Space, enter an encryption passphrase, and hit Done or OK or Next or whatever it is
5. In Reclaim Space, Pick to delete the entire disk
6. You're back at hub; go to Keyboard spoke and remove the English (US) layout
7. Go back to Installation Destination spoke, and voila, it looks like the screenshot.

Comment 14 Chris Lumens 2013-05-15 20:40:26 UTC
Can you give updates=http://clumens.fedorapeople.org/869364.img a try?  This updates image contains only a patch for this bug, nothing more.

Comment 15 Adam Williamson 2013-05-15 20:51:14 UTC
*** Bug 962994 has been marked as a duplicate of this bug. ***

Comment 16 Adam Williamson 2013-05-15 20:54:50 UTC
Proposing as an FE bug - I wouldn't want to poke this late in freeze, but it's an obvious bug in the installer that multiple people have encountered, and it can cause significant functionality problems in some cases (see c#11), and clumens' proposed fix just tries harder to maximize the spoke, so it seems fairly safe for an early-freeze exception.

Comment 17 Adam Williamson 2013-05-15 21:35:42 UTC
Well, it doesn't appear to be a complete fix, at any rate.

I tried c#13 again without the updates.img and it reproduces the bug - seems like a reliable reproducer. Then I tried it again with the updates.img and the installation destination spoke is full size. Awesome!

But then I went to the Time spoke and picked a random timezone, went back to hub, went to the Keyboard spoke again, and voila, the bug hit. Looks much like it always does, but I'll attach a screenshot anyway. Can't see anything relevant in any logs.

Comment 18 Adam Williamson 2013-05-15 21:37:34 UTC
Created attachment 748522 [details]
screenshot of the bug being reproduced even with clumens' patch

Comment 19 Fedora Update System 2013-05-15 22:26:05 UTC
anaconda-19.27-1.fc19, pykickstart-1.99.31-1.fc19, python-blivet-0.14-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/python-blivet-0.14-1.fc19,pykickstart-1.99.31-1.fc19,anaconda-19.27-1.fc19

Comment 20 Fedora Update System 2013-05-16 05:22:39 UTC
Package anaconda-19.27-1.fc19, pykickstart-1.99.31-1.fc19, python-blivet-0.14-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-19.27-1.fc19 pykickstart-1.99.31-1.fc19 python-blivet-0.14-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-8322/python-blivet-0.14-1.fc19,pykickstart-1.99.31-1.fc19,anaconda-19.27-1.fc19
then log in and leave karma (feedback).

Comment 21 Chris Lumens 2013-05-16 14:56:06 UTC
Poking around at it with an updates.img, I can't reproduce the new problem.  Can you lay out the steps a little more thoroughly?

Comment 22 Fedora Update System 2013-05-17 22:20:03 UTC
Package pykickstart-1.99.31-1.fc19, anaconda-19.28-1.fc19, python-blivet-0.14-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing pykickstart-1.99.31-1.fc19 anaconda-19.28-1.fc19 python-blivet-0.14-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-8322/python-blivet-0.14-1.fc19,pykickstart-1.99.31-1.fc19,anaconda-19.28-1.fc19
then log in and leave karma (feedback).

Comment 23 Fedora Update System 2013-05-18 04:56:03 UTC
pykickstart-1.99.31-1.fc19, anaconda-19.28-1.fc19, python-blivet-0.14-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 24 Adam Williamson 2013-05-21 20:01:50 UTC
Jeff Bastian reported seeing this on Beta RC2 during the test day today. It's clearly not entirely fixed. I still need to pin down a 100% reproducer and add it to the bug; it's been on my todo list since last week but haven't quite got around to it yet :(

Comment 25 Jeff Bastian 2013-05-21 20:08:37 UTC
My reproducer isn't 100% guaranteed, but it's worked for me twice today:

0. Create 6 LVM logical volumes to use as disks for a virtual machine
   and start the installation like this:

  virt-install --name=test-machine101 --ram=1024 --vcpus=2 \
    --graphics=vnc --noautoconsole \
    --os-type=linux --os-variant=fedora18 \
    --cdrom=/var/lib/libvirt/images/Fedora-19-Beta-x86_64-DVD.iso \
    --network=network=default,model=virtio \
    --disk=/dev/mapper/vg_virt_data-f19_d1,bus=virtio \
    --disk=/dev/mapper/vg_virt_data-f19_d2,bus=virtio \
    --disk=/dev/mapper/vg_virt_data-f19_d3,bus=virtio \
    --disk=/dev/mapper/vg_virt_data-f19_d4,bus=virtio \
    --disk=/dev/mapper/vg_virt_data-f19_d5,bus=virtio \
    --disk=/dev/mapper/vg_virt_data-f19_d6,bus=virtio

1. Choose English (United States) at the welcome screen and hit the
   checkbox for set keyboard to default layout for selected language
   Hit Continue.

2. Go to Date & Time spoke
  a. Change time zone to America/Chicago
  b. Adjust the list of ntp servers

3. Go to Software Selection spoke and choose Minimal Installation

4. Go to Storage spoke
  a. Select first 2 disks
  b. Hit Done
  c. Choose "I want to review/modify my disk partitions"
     and hit Continue
  d. Remove all existing partitions from the disks
  e. Hit the "Click here to create them automatically" link to create
     a default partition layout
  f. Choose the / partition and hit "Modify" for the Volume Group
  g. Unselect the 2nd disk and hit Save and then Update Settings
  h. Hit + to add a partition, add /var of size 8GB and note the
     warning (see bug 965623)
  i. Hit Done and Accept Changes

5. Click the Installation Destination spoke to revisit the disks
   and the screen is cut off

Comment 26 Adam Williamson 2013-05-21 21:12:56 UTC
Let's re-open this, as it clearly isn't really fixed. I hit it with the updates.img and Jeff has hit it multiple times in Beta RC2. It's a tough one to debug so we're not expecting miracles, but obviously it should be open.

Comment 27 Chris Lumens 2013-05-21 21:53:01 UTC
I'm pretty much out of ideas at this point, so barring any revelations, it's pretty quickly speeding towards CANTFIX.

Comment 28 Reartes Guillermo 2013-05-21 21:57:42 UTC
Is it possible to execute anaconda on an installed system?

If that is possible, maybe running it with strace or other tool might help.

Comment 29 Vratislav Podzimek 2013-05-22 10:21:49 UTC
Just an idea: has anybody seen this issue during live installation? I think the issue can be caused by the window manager (anaconda uses metacity), not by the installer.

Comment 30 Chris Lumens 2013-05-22 18:46:01 UTC
When I was testing with running under mutter, I got this behavior all the time.  That is perhaps a clue, and I should try running that way again.

Comment 31 Vojtěch Boček 2013-05-23 08:56:13 UTC
*** Bug 965579 has been marked as a duplicate of this bug. ***

Comment 32 Vojtěch Boček 2013-05-23 08:57:01 UTC
(In reply to Vratislav Podzimek from comment #29)
> Just an idea: has anybody seen this issue during live installation? I think
> the issue can be caused by the window manager (anaconda uses metacity), not
> by the installer.

I just replicated this bug on Fedora Beta RC4 live.iso image, using method described in bug 965579

Comment 33 Chris Lumens 2013-05-23 17:32:15 UTC
Okay, let's try a different direction here.  Can someone who is seeing this on x86-64 please give updates=http://clumens.fedorapeople.org/869364.img a try?  If this doesn't work, I have an additional tweak to try later.

This updates image contains compiled code.  If it gives a traceback or causes the installer to not start, I might have to be more clever in constructing the image.

Comment 34 Vojtěch Boček 2013-05-24 09:10:06 UTC
Created attachment 752516 [details]
anaconda log from update.img from #33

With image from #33 anaconda freezes after clicking "continue" on the first screen with language selection. Booted from Beta RC4 x86_64 DVD.iso with updates=... cmdline parameter.

Comment 35 Vojtěch Boček 2013-05-24 09:10:58 UTC
Created attachment 752518 [details]
packagin.log from update.img from #33

Comment 36 Chris Lumens 2013-05-24 14:27:05 UTC
I don't think that is related, but please check tty1 for more information and if you see any error messages there, please post them to this bug report.

Comment 37 Jeff Bastian 2013-05-24 19:15:01 UTC
With the 869364.img I get on my tty1:

Starting installer, one moment...
anaconda 19.28-1 for Fedora 19-Beta (pre-release) started.
LibThai: Fail to open dictionary at '/usr/share/libthai/thbrk.tri'.

Comment 38 Vojtěch Boček 2013-05-27 07:31:00 UTC
Yeah, I've got the same error:

Starting installer, one moment...
anaconda 19.30-1 for Fedora 19-Beta (pre-release) started.
LibThai: Fail to open dictionary at '/usr/share/libthai/thbrk.tri'.

I've chosen en_US as language on the first screen.

Comment 39 Vratislav Podzimek 2013-05-28 08:12:07 UTC
(In reply to Vojtěch Boček from comment #38)
> Yeah, I've got the same error:
> 
> Starting installer, one moment...
> anaconda 19.30-1 for Fedora 19-Beta (pre-release) started.
> LibThai: Fail to open dictionary at '/usr/share/libthai/thbrk.tri'.
This "error" appears in every installation and I'm not sure it even causes any issues.

Comment 40 Adam Williamson 2013-05-29 05:59:22 UTC
Nominating as a final freeze exception, obviously if we find a fix for this we should definitely go for it.

Comment 41 Adam Williamson 2013-06-05 18:13:11 UTC
Discussed at 2013-06-05 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-05/f19final-blocker-review-3.2013-06-05-16.05.log.txt .  Accepted as a freeze exception issue: quite a few people have managed to hit it, it obviously looks bad and it has practical consequences for very full spokes or when you hit the really bad '25% size' case. If you folks can come up with a fix not too close to release time, we'd definitely want to take it.

Comment 42 Adam Williamson 2013-12-02 19:21:07 UTC
Has anyone ever seen this in F20? Wondering if magic GTK+ pixies showed up and fixed it or something, I don't think I hit it once.

Comment 43 Vratislav Podzimek 2013-12-03 08:01:14 UTC
(In reply to Adam Williamson from comment #42)
> Has anyone ever seen this in F20? Wondering if magic GTK+ pixies showed up
> and fixed it or something, I don't think I hit it once.
I've seen it once on my netbook with a weird resolution (1024x600), but never on any higher resolution.

Comment 44 Reartes Guillermo 2013-12-03 17:53:44 UTC
Due to lack of time, i did not perform as many tests as previous versions.

The good thing is that i did not experienced the issue during the F20 development phase. (on 1024x769 and higher resolutions, as lower resolution are unsupported)

Maybe the pixies really fixed it.

Comment 45 Chris Lumens 2013-12-18 19:08:01 UTC
I've not seen this in a long time, too.  I'm going to close it for now, and hopefully that will not cause it to reappear.


Note You need to log in before you can comment on or make changes to this bug.