Bug 1160891 - Only uses upper left part of the display [NEEDINFO]
Summary: Only uses upper left part of the display
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: initial-setup   
(Show other bugs)
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Martin Kolman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker AcceptedFreezeExcepti...
Keywords: CommonBugs, Reopened
: 1298718 1299869 1319506 (view as bug list)
Depends On:
Blocks: F24AlphaFreezeException F24FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2014-11-05 22:28 UTC by Brian Lane
Modified: 2016-04-05 14:02 UTC (History)
12 users (show)

Fixed In Version: initial-setup-0.3.40-1 initial-setup-0.3.40-1.fc24
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-04-05 14:02:38 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
fedora: needinfo? (mclasen)


Attachments (Terms of Use)
Output of journalctl -u initial-setup-graphical (18.29 KB, text/plain)
2014-11-05 22:29 UTC, Brian Lane
no flags Details

Description Brian Lane 2014-11-05 22:28:30 UTC
initial-setup-0.3.25-1 is not using the whole display. Initially it is using about 1/8 of the display, in the upper left. After vising the user spoke, which uses about 1/4 of the display, it resizes to use 1/4.

Comment 1 Brian Lane 2014-11-05 22:29:19 UTC
Created attachment 954237 [details]
Output of journalctl -u initial-setup-graphical

Comment 2 Vratislav Podzimek 2014-11-06 08:21:15 UTC
Nov 05 14:16:31 localhost.localdomain logger[780]: Running 0 window manager (/usr/bin/marco)
Nov 05 14:16:32 localhost.localdomain xinit[684]: (marco:801): GLib-GIO-ERROR **: Settings schema 'org.mate.interface' is not installed

Seems like "here we go again" with marco issues.

This is how initial-setup runs the window manager and itself:
https://git.fedorahosted.org/cgit/initial-setup.git/tree/firstboot-windowmanager

Comment 3 Wolfgang Ulbrich 2014-11-06 10:04:40 UTC
org.mate.interface.gschema.xml is in mate-desktop-libs package.
Is this installed?
How did you installed Mate?

Comment 4 Wolfgang Ulbrich 2014-11-06 11:15:53 UTC
A fresh Mate installation from fedora-server netiso in qemu VM shows me that initial-setup is working well with marco as window-manager.
I'm curious to hear your story as you have the Mate desktop installed ;)

Comment 5 Vratislav Podzimek 2014-11-07 06:49:37 UTC
Setting needinfo to reporter as per comment #4 and comment #3.

Comment 6 Brian Lane 2014-11-07 20:34:04 UTC
I didn't do a Mate install. I did a kickstart with @workstation-product and initial-setup in an addon repo.

Comment 7 Wolfgang Ulbrich 2014-11-07 21:07:45 UTC
Mate isn't a workstation product.
So why is marco installed?
And normaly gnome should use mutter as WM.
So if you didn't installed marco, where did it?
Which addon repo?

It would be very helpful if you find out why marco was installed, i.e search in logs, i expect this from someone with redhat in mail address.
Because that isn't a marco bug only a installation bug.
And if the kickstart file is wrong that should be seriously fixed before release.

Thank you

Comment 8 Brian Lane 2014-11-08 03:29:37 UTC
According to packaging.log marco was installed for initial-setup-gui. The system is running GNOME and not mate.

The addon repo simply has initial-setup and initial-setup-gui in it.

Comment 9 Wolfgang Ulbrich 2014-11-08 03:57:50 UTC
(In reply to bcl@redhat.com from comment #8)
> According to packaging.log marco was installed for initial-setup-gui. The
> system is running GNOME and not mate.
> 
> The addon repo simply has initial-setup and initial-setup-gui in it.

Seems like "here we go again" with initial-setup issues.

Comment 10 Vratislav Podzimek 2014-11-10 07:20:49 UTC
(In reply to Wolfgang Ulbrich from comment #9)
> (In reply to bcl@redhat.com from comment #8)
> > According to packaging.log marco was installed for initial-setup-gui. The
> > system is running GNOME and not mate.
> > 
> > The addon repo simply has initial-setup and initial-setup-gui in it.
> 
> Seems like "here we go again" with initial-setup issues.
In what way? No matter how marco was installed, it was installed and used by the initial-setup and should work. That's the reason why we have dependencies between packages. If there was something missing for marco on the installed system, it means that that something should be added to the marco's Requires. The initial-setup.spec file simply has the following line in it:

Requires: firstboot(windowmanager)

which pulls in marco as a provider. 'marco' is then responsible for pulling in all the other things it requires to run properly.

Comment 11 Wolfgang Ulbrich 2014-11-10 10:57:32 UTC
The issue is that initial-setup use marco as WM on a box with gnome as desktop.
Initial-setup should use mutter in this case. Seems it use a alphabetic order to choose the VM.
Shure i can add mate-desktop-libs as dependency, but do you really want that gnome use marco for initial-setup?

Comment 12 Fedora Update System 2014-11-10 12:43:15 UTC
marco-1.8.2-5.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/marco-1.8.2-5.fc21

Comment 13 Wolfgang Ulbrich 2014-11-10 12:55:12 UTC
I've add mate-desktop-libs as require to marco to fix the symptoms of the wrong selecting WM from anaconda/intial-setup in workstation product.
So i'm fine.
Feel free to change the subject of the report to something valid like 'anaconda/initial-setup use the wrong WM in workstation product', and reasign it to anaconda or workstation product.
Please do not reasign it to marco!!!!
Marco isn't responsible for choosing the right WM in workstation product.

Thank you


@ reporter
Could it be posible that you create the workstation image in mate desktop environment?

Comment 14 Vratislav Podzimek 2014-11-10 13:13:37 UTC
(In reply to Wolfgang Ulbrich from comment #13)
> I've add mate-desktop-libs as require to marco to fix the symptoms of the
> wrong selecting WM from anaconda/intial-setup in workstation product.
> So i'm fine.
Thanks for the fix.

> Feel free to change the subject of the report to something valid like
> 'anaconda/initial-setup use the wrong WM in workstation product', and
> reasign it to anaconda or workstation product.
This is not the issue (see below).

> Please do not reasign it to marco!!!!
> Marco isn't responsible for choosing the right WM in workstation product.
What about changing subject to 'marco doesn't require all packages it needs to run properly' and assigning this bug to marco which would make sense as you've provided a fix for it by adding those dependencies?

I agree that the choice of the WM is a different issue and if you think it is wrong now (I don't think so, see below), please file a new bug report.


(In reply to Wolfgang Ulbrich from comment #11)
> Initial-setup should use mutter in this case. Seems it use a alphabetic
> order to choose the VM.
mutter doesn't work with Anaconda's (and thus Initial Setup's) UI.

> Shure i can add mate-desktop-libs as dependency, but do you really want that
> gnome use marco for initial-setup?
Either marco or metacity (kwin and others are even worse choices, I think). I have now idea why yum pulls in marco as a dependecy instead of metacity or kwin, but it does. And it should work. Whether it is wrong choice or not is another question and could be filed in another bug report.

Comment 15 Matthias Clasen 2014-11-10 13:29:45 UTC
(In reply to Vratislav Podzimek from comment #14)

> Either marco or metacity (kwin and others are even worse choices, I think).
> I have now idea why yum pulls in marco as a dependecy instead of metacity or
> kwin, but it does. And it should work. Whether it is wrong choice or not is
> another question and could be filed in another bug report.

I want anaconda to use a gnome-shell mode on the workstation.

Comment 16 Wolfgang Ulbrich 2014-11-10 15:22:19 UTC
(In reply to Vratislav Podzimek from comment #14)
> (In reply to Wolfgang Ulbrich from comment #13)
> > I've add mate-desktop-libs as require to marco to fix the symptoms of the
> > wrong selecting WM from anaconda/intial-setup in workstation product.
> > So i'm fine.
> Thanks for the fix.
> 
> > Feel free to change the subject of the report to something valid like
> > 'anaconda/initial-setup use the wrong WM in workstation product', and
> > reasign it to anaconda or workstation product.
> This is not the issue (see below).
> 
> > Please do not reasign it to marco!!!!
> > Marco isn't responsible for choosing the right WM in workstation product.
> What about changing subject to 'marco doesn't require all packages it needs
> to run properly' and assigning this bug to marco which would make sense as
> you've provided a fix for it by adding those dependencies?
Do what you want, i'm tired about this discussion, but than nobody will get noticed about the real issue.
> 
> I agree that the choice of the WM is a different issue and if you think it
> is wrong now (I don't think so, see below), please file a new bug report.
> 
> 
> (In reply to Wolfgang Ulbrich from comment #11)
> > Initial-setup should use mutter in this case. Seems it use a alphabetic
> > order to choose the VM.
> mutter doesn't work with Anaconda's (and thus Initial Setup's) UI.
> 
> > Shure i can add mate-desktop-libs as dependency, but do you really want that
> > gnome use marco for initial-setup?
> Either marco or metacity (kwin and others are even worse choices, I think).
> I have now idea why yum pulls in marco as a dependecy instead of metacity or
> kwin, but it does. And it should work. Whether it is wrong choice or not is
> another question and could be filed in another bug report.
Could it be possible that metacity-3.12 doesn't work with GTK3-3.14?
Maybe this is the reason why marco is used.

Comment 17 Fedora Update System 2014-11-13 18:10:40 UTC
marco-1.8.2-5.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 18 Fedora End Of Life 2015-11-04 15:59:15 UTC
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 19 Fedora End Of Life 2015-12-02 04:44:29 UTC
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 20 Martin Kolman 2015-12-02 08:13:08 UTC
This unfortunately still sometimes happens in rawhide.

Comment 21 Fedora Admin XMLRPC Client 2016-01-11 08:00:53 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 22 Martin Kolman 2016-02-12 19:11:48 UTC
*** Bug 1298718 has been marked as a duplicate of this bug. ***

Comment 23 Martin Kolman 2016-02-12 19:12:08 UTC
*** Bug 1299869 has been marked as a duplicate of this bug. ***

Comment 24 Jan Kurik 2016-02-24 13:17:03 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

Comment 25 Fedora Blocker Bugs Application 2016-03-09 22:08:58 UTC
Proposed as a Blocker and Freeze Exception for 24-alpha by Fedora user juliuxpigface using the blocker tracking app because:

 On duplicate "1299869", the reporter noted that this issue affects Xfce on ARM, which is a release blocking desktop. However... The criterion is not fully violated. The "2.4.1 Expected installed system boot behavior" Alpha criterion says:

"On the first boot after installation, a utility for creating user accounts and other configuration may (may, not must) run prior to a log in screen appearing."

So... If we follow the guidelines strictly, this should not be a blocker. However, in my opinion, we should discuss about it, because it gives a really bad impression and might make that utility unusable.

Comment 26 Michael Catanzaro 2016-03-13 02:43:38 UTC
(In reply to Fedora Blocker Bugs Application from comment #25)
>  On duplicate "1299869", the reporter noted that this issue affects Xfce on
> ARM, which is a release blocking desktop.

No it's not? Only Fedora products and the KDE spin are release blocking.

Comment 27 Giulio 'juliuxpigface' 2016-03-13 08:14:52 UTC
(In reply to Michael Catanzaro from comment #26)
> (In reply to Fedora Blocker Bugs Application from comment #25)
> >  On duplicate "1299869", the reporter noted that this issue affects Xfce on
> > ARM, which is a release blocking desktop.
> 
> No it's not? Only Fedora products and the KDE spin are release blocking.

I'm pretty sure it is. If I remember correctly, it has been nominate as blocker during the F23 testing cycle.
For the record however, I've encountered the issue with the KDE spin too (with quemu-kvm)

I cited that specific duplicate because it appears to have been tested against bare metal.

Comment 28 Michael Catanzaro 2016-03-14 13:41:03 UTC
(In reply to Giulio 'juliuxpigface' from comment #27)
> I'm pretty sure it is.

Oh you're right, it's right there in https://fedoraproject.org/wiki/Fedora_24_Alpha_Release_Criteria#Alpha_Release_Requirements

That must be new since ARM became a primary architecture.

Sigh....

Comment 29 Kamil Páral 2016-03-14 16:25:35 UTC
Discussed at today's blocker review meeting [1]. Voted as AcceptedBlocker (Final) AcceptedFreezeException (Alpha) - this definitely impairs use of initial-setup, but it is possible to do what you need to; we agreed it makes sense to make it a Final blocker, Alpha users can be expected to cope. If not fixed it will be documented in Common Bugs.

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2016-03-14/

Comment 30 Dennis Gilmore 2016-03-19 20:50:54 UTC
I had this today on a clean F24 Xfce install. I could not actually see enough of the window to do anything. The reason why it was a FE for alpha was not true in my case. Though in my case all I needed to do was hit the "finish configuration" button since I needed to join the machine to my ipa server to setup users.

Comment 31 Martin Kolman 2016-03-23 12:41:31 UTC
Looks like this issues has been caused by the window manager not being started properly - a fix has bee been posted for review.

Comment 32 Martin Kolman 2016-03-24 12:24:45 UTC
*** Bug 1319506 has been marked as a duplicate of this bug. ***

Comment 33 Adam Williamson 2016-03-28 20:59:34 UTC
Dennis: you can see enough to do stuff, it's just not immediately obvious; you can scroll down to see the spoke links (the anaconda hub is scrollable these days).

Comment 34 Fedora Update System 2016-03-30 11:48:30 UTC
initial-setup-0.3.40-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-0c1cbc3888

Comment 35 Fedora Update System 2016-03-30 22:25:45 UTC
initial-setup-0.3.40-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-0c1cbc3888

Comment 36 Fedora Update System 2016-04-03 17:56:42 UTC
initial-setup-0.3.40-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Comment 37 Kamil Páral 2016-04-05 08:30:11 UTC
Since this was accepted as a blocker, we should really verify that it works.

Comment 38 Paul Whalen 2016-04-05 13:18:51 UTC
Verified working on ARM with initial-setup-0.3.40-1.fc24.

Comment 39 Kamil Páral 2016-04-05 14:02:38 UTC
Thanks, Paul! In that case closing again.


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