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:
Created attachment 632227 [details] distorted installation destination screen The main hub and the other areas are ok.
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.
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.
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.
Note: there's also a patch for the custom partitioning screen.
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.
Reartes, have you still seen this issue with F18 final / F19 composes?
Yes, but only in the Installation Destination. (attachment from comment #1). Regarding Custom Partitioning, no, it does not happen anymore on that screen.
Created attachment 745884 [details] updated screenshot
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...
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.
Created attachment 746914 [details] Screenshot of an extreme case
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.
Can you give updates=http://clumens.fedorapeople.org/869364.img a try? This updates image contains only a patch for this bug, nothing more.
*** Bug 962994 has been marked as a duplicate of this bug. ***
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.
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.
Created attachment 748522 [details] screenshot of the bug being reproduced even with clumens' patch
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
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).
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?
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).
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.
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 :(
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
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.
I'm pretty much out of ideas at this point, so barring any revelations, it's pretty quickly speeding towards CANTFIX.
Is it possible to execute anaconda on an installed system? If that is possible, maybe running it with strace or other tool might help.
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.
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.
*** Bug 965579 has been marked as a duplicate of this bug. ***
(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
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.
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.
Created attachment 752518 [details] packagin.log from update.img from #33
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.
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'.
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.
(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.
Nominating as a final freeze exception, obviously if we find a fix for this we should definitely go for it.
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.
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.
(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.
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.
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.