output of terminal:

$ mcc
Too late to run INIT block at /usr/lib/perl5/vendor_perl/Glib/Object/Introspection.pm line 257.
Ignore the following Glib::Object::Introspection & Gtk3 warnings
No protocol specified
Unable to init server: Could not connect: Connection refused
Cannot be run in console mode.

hardware:

# lspcidrake
lpc_ich         : Intel Corporation|Atom Processor Z36xxx/Z37xxx Series Power Control Unit [BRIDGE_ISA] (rev: 09)
xhci_pci        : Intel Corporation|Atom Processor Z36xxx/Z37xxx, Celeron N2000 Series USB xHCI [SERIAL_USB] (rev: 09)
Card:Intel 810 and later: Intel Corporation|Atom Processor Z36xxx/Z37xxx Series Graphics & Display [DISPLAY_VGA] (rev: 09)
mei_txe         : Intel Corporation|Atom Processor Z36xxx/Z37xxx Series Trusted Execution Engine [CRYPT_OTHER] (rev: 09)
unknown         : Intel Corporation|Atom Processor Z36xxx/Z37xxx Series SoC Transaction Register [BRIDGE_HOST] (rev: 09)
hub             : Linux 5.10.12-desktop586-3.mga8 xhci-hcd|xHCI Host Controller [Hub|Unused|Full speed (or root) hub]
usbhid          : ASUSTek COMPUTER INC.|ASUS Base Station(T100) [Human Interface Device|Boot Interface Subclass|Keyboard]
hub             : Linux 5.10.12-desktop586-3.mga8 xhci-hcd|xHCI Host Controller [Hub|Unused|Full speed (or root) hub]
hid_generic     : ASUSTek COMPUTER INC. ASUS Base Station(T100)
hid_generic     : ASUSTek COMPUTER INC. ASUS Base Station(T100)
hid_generic     : ATML1000:00 03EB:8C0D
hid_generic     : ASUSTek COMPUTER INC. ASUS Base Station(T100)

heres a gotcha.

after running launchGUIs -t 2 as root, it will now work. 
however, not permanently.

issue returns after a reboot.

some  temporary change has been made?

Created attachment 12303 [details]
launchGUIs script

normally run as user.
if running as root, disable internet, also would not normally be recommended.

So, from the error message in the terminal, this is definitely an X authentication failure. Can you show the output from hostnamectl after this happens.

Does logging out and logging back in again allow it to work?

(In reply to Martin Whitaker from comment #5)
> So, from the error message in the terminal, this is definitely an X
> authentication failure. Can you show the output from hostnamectl after this
> happens.
> 

[me@linux ~]$ hostnamectl
   Static hostname: localhost
Transient hostname: linux.local
         Icon name: computer-laptop
           Chassis: laptop
        Machine ID: f1101e7bcd974a3eb74ce91801f15733
           Boot ID: 1e4b8a00c0344481b946aefd165deb57
  Operating System: Mageia 8
            Kernel: Linux 5.10.12-desktop586-3.mga8
      Architecture: x86
[me@linux ~]$ mcc
Too late to run INIT block at /usr/lib/perl5/vendor_perl/Glib/Object/Introspection.pm line 257.
Ignore the following Glib::Object::Introspection & Gtk3 warnings
No protocol specified
Unable to init server: Could not connect: Connection refused
Cannot be run in console mode.

~
launchGUIs
~

$ mcc
Too late to run INIT block at /usr/lib/perl5/vendor_perl/Glib/Object/Introspection.pm line 257.
Ignore the following Glib::Object::Introspection & Gtk3 warnings
Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539.
GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib/perl5/DynaLoader.pm line 210.
GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib/perl5/DynaLoader.pm line 210.
GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib/perl5/DynaLoader.pm line 210.
GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib/perl5/DynaLoader.pm line 210.
"cannot run /usr/sbin/isodumper" since it is not installed [Writing ISO] at /usr/libexec/drakconf line 833.
Oops, secure memory pool already initialized
Oops, secure memory pool already initialized

(authenication dialogue presented, accepted and MCC GUI presented)

$ hostnamectl
   Static hostname: localhost
Transient hostname: linux.local
         Icon name: computer-laptop
           Chassis: laptop
        Machine ID: f1101e7bcd974a3eb74ce91801f15733
           Boot ID: 1e4b8a00c0344481b946aefd165deb57
  Operating System: Mageia 8
            Kernel: Linux 5.10.12-desktop586-3.mga8
      Architecture: x86

not sure what isodumper is doing in there.

will install and see what happens

> Does logging out and logging back in again allow it to work?

will find out in a minute - logging out
.....
no, after logging back in - problem persists.

will see if adding isodumper changes thing

adding isodumper (gtk) no difference

When you log out and log back in again, is it disconnecting and reconnecting the network?

(In reply to Martin Whitaker from comment #8)
> When you log out and log back in again, is it disconnecting and reconnecting
> the network?

yes

so other stuff: 

[me@localhost Documents]$ mcc
Too late to run INIT block at /usr/lib/perl5/vendor_perl/Glib/Object/Introspection.pm line 257.
Ignore the following Glib::Object::Introspection & Gtk3 warnings
No protocol specified
Unable to init server: Could not connect: Connection refused
Cannot be run in console mode.
[me@localhost Documents]$ ./launchGUIs -s 63 -d 1 -t 2
Version 5
Input applications file = /home/me/guiApps.txt
New Results file = /home/me/guiResults.txt
New Failures file will = /home/me/guiFails.txt
Running in Automatic mode
Doing 1 tests 63-63 of 115, for 2 seconds
The following lines will be run (unless excluded) [~ is space]
(it would help to show their source line numbers...)

/usr/bin/gparted~%f


Is this OK? Just Enter to continue, anything else to quit: 

========================================================
Trying line 63, test 1/1: '/usr/bin/gparted %f'
localuser:root being added to access control list
New process correctly found: 19067 gparted, killing it
./launchGUIs: line 326: 19067 Killed                  $COMMAND
y/usr/bin/gparted %f seems to WORK
========================================================

1/1 apparent successes, 0/1 apparent failures
Press Enter to see the result summary (Q|q to quit 'less')  

mv: cannot stat '/home/me/guiFails.txt.19029': No such file or directory
[me@localhost Documents]$ mcc
Too late to run INIT block at /usr/lib/perl5/vendor_perl/Glib/Object/Introspection.pm line 257.
Ignore the following Glib::Object::Introspection & Gtk3 warnings
Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539.
GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib/perl5/DynaLoader.pm line 210.
GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib/perl5/DynaLoader.pm line 210.
GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib/perl5/DynaLoader.pm line 210.
GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib/perl5/DynaLoader.pm line 210.
Oops, secure memory pool already initialized

(authenication dialogue presented, accepted and MCC GUI presented)

dont know if this is helpful:

running gparted from terminal and ctrl+c to kill the dialogue box does allow mcc then to present GUI

heres a trick:

connecting to the wifi via drakroam, then logging out or rebooting, MCC works.

disconnection wifi via drakroam and reconnect with network manager = no MCC

(In reply to ben mcmonagle from comment #9)
> (In reply to Martin Whitaker from comment #8)
> > When you log out and log back in again, is it disconnecting and reconnecting
> > the network?
> 
> yes

Ah, I suspect when you configured the network interface, you didn't tick the box to let all users share it. That would make a difference. Each time the connection is made, NetworkManager tries to discover and set the hostname from the network. linux.local is the default name returned by a reverse DNS lookup.

> Trying line 63, test 1/1: '/usr/bin/gparted %f'
> localuser:root being added to access control list

So either launchGUIs or gparted is relaxing the X access permissions, which is why MCC starts afterwards. You can do the same by (as your normal user)

  xhost +si:localuser:root

Setting a proper hostname should fix the problem. I don't know why 'hostnamectl set-hostname' didn't work for you. You could try doing it manually by editing the /etc/hostname file.

The other possible fix is to append the line

  hostname-mode=none

to the /etc/NetworkManager/NetworkManager.conf file, which will stop NetworkManager meddling with the hostname.

The problems are more widespread than first thought. Even on the Plasma Live, which doesn't use NM, running drakconnect to configure the network and leaving the host name as the default of localhost.localdomain causes subsequent attempts to start the MCC (or any drakx GUI tool) to fail. There has been some subtle change to the way host names are managed by the system. On Mageia 7, hostnamectl would report

[root@localhost ~]# hostnamectl
   Static hostname: localhost.localdomain
 
whilst on Mageia 8 it reports

[root@localhost ~]# hostnamectl
   Static hostname: localhost.localdomain
Transient hostname: localhost

So I think the fix for all this is to do the same as we used to do for GNOME/Wayland, and have a startup script that executes

  xhost +si:localuser:root

each time a user starts a graphical session.

I see this on Live Xfce 64 RC1 take 5

As an industrial machine designer i am stumped at why answering the phone in the office makes all control panels in manufacturing die...

Confirming workaround: In Terminal window:
 $ xhost +si:localuser:root
 localuser:root being added to access control list

forgot to say:

...and then MCC launches OK from both icon and Terminal.

(In reply to Martin Whitaker from comment #13)
> The problems are more widespread than first thought. Even on the Plasma
> Live, which doesn't use NM, running drakconnect to configure the network and
> leaving the host name as the default of localhost.localdomain causes
> subsequent attempts to start the MCC (or any drakx GUI tool) to fail. There
> has been some subtle change to the way host names are managed by the system.
>
Well now this is weird. I have a Plasma install created by the Live iso just yesterday, and it's not showing the problem. 

The system is wifi-only, and the wifi was set up using the net_applet before the install, so maybe that did an end-run around drakconnect. 

After the boot the first thing I did was call up MCC, and everything is normal. I set up the Princeton mirror, and went after updates. When there were none, I used urpmi --auto-update. That got me several, but even after another boot MCC behaves normally. 

I did retain /home through the install, and as far as that goes this /home once belonged to a Mageia 7 install. I didn't do anything with the hostname - it's whatever it was set by the installer.

CC: (none) => andrewsfarm

How about a script in /etc/X11/xinit.d/ with ...
#!/bin/sh
while inotifywait -e modify /proc/sys/kernel/hostname; do
    xhost +si:localuser:root
done

Untested at this point.

CC: (none) => davidwhodgins

(In reply to Martin Whitaker from comment #13)
> The problems are more widespread than first thought. Even on the Plasma
> Live, which doesn't use NM, running drakconnect to configure the network and
> leaving the host name as the default of localhost.localdomain causes
> subsequent attempts to start the MCC (or any drakx GUI tool) to fail. There
> has been some subtle change to the way host names are managed by the system.
> On Mageia 7, hostnamectl would report
> 
> [root@localhost ~]# hostnamectl
>    Static hostname: localhost.localdomain
>  
> whilst on Mageia 8 it reports
> 
> [root@localhost ~]# hostnamectl
>    Static hostname: localhost.localdomain
> Transient hostname: localhost
> 
> So I think the fix for all this is to do the same as we used to do for
> GNOME/Wayland, and have a startup script that executes
> 
>   xhost +si:localuser:root
> 
> each time a user starts a graphical session.


Seems no-one has a better solution for now so we should go for this one.
Can you do it so we can get wide testing 

Then with a little dreaming hope to get it better fixed in mga9

Workaround has been pushed to repository to xinitrc package

http://svnweb.mageia.org/packages?view=revision&revision=1675229
This need a Real test please.

Thanks Martin W.

Status comment: (none) => workaround added to xinitrc package and pushed.
CC: (none) => ouaurelien

Works as expected under Cinnamon, GNOME Wayland, GNOME, XFCE, icewm-session.

Reducing as not a blocker one.

Target Milestone: Mageia 8 => Mageia 9
Priority: release_blocker => High

Do the fix it not work in Plasma?

Is this related:
Bug 28365 - Control Center does not start in Plasma Wayland

(In reply to Morgan Leijström from comment #22)
> Is this related:
> Bug 28365 - Control Center does not start in Plasma Wayland

It's related in that it's an X authorisation problem, but it has a different cause. See bug 26101.

Now removed from Errata, including the mention of bug 27601.

Keywords: IN_ERRATA8 => (none)

(In reply to Aurelien Oudelet from comment #20)
> Works as expected under Cinnamon, GNOME Wayland, GNOME, XFCE, icewm-session.
> 
> Reducing as not a blocker one.

Workaround set in xinitrc script.

Assigning to Magiea Tools maintainers, against Cauldron.

Keywords: 8rc1 => (none)
Severity: major => normal
Whiteboard: round 5 => (none)
Assignee: bugsquad => mageiatools
Version: 8 => Cauldron

fixed

Status: NEW => RESOLVED
Resolution: (none) => FIXED