Created attachment 954237 [details]
Output of journalctl -u initial-setup-graphical

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

org.mate.interface.gschema.xml is in mate-desktop-libs package.
Is this installed?
How did you installed Mate?

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 ;)

Setting needinfo to reporter as per comment #4 and comment #3.

I didn't do a Mate install. I did a kickstart with @workstation-product and initial-setup in an addon repo.

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

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.

(In reply to bcl 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 reply to Wolfgang Ulbrich from comment #9)
> (In reply to bcl 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.

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?

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

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?

(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.

(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.

(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.

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.

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.

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.

This unfortunately still sometimes happens in rawhide.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

*** Bug 1298718 has been marked as a duplicate of this bug. ***

*** Bug 1299869 has been marked as a duplicate of this bug. ***

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

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.

(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.

(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.

(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....

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/

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.

Looks like this issues has been caused by the window manager not being started properly - a fix has bee been posted for review.

*** Bug 1319506 has been marked as a duplicate of this bug. ***

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).

initial-setup-0.3.40-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-0c1cbc3888

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

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.

Since this was accepted as a blocker, we should really verify that it works.

Verified working on ARM with initial-setup-0.3.40-1.fc24.

Thanks, Paul! In that case closing again.