Description of problem: Trying to lauch the mageia control center or other drak-tools just prints "no protocol specified This programm cannot be run in console mode" (although when you start drakconf as root, it runs find in console mode) I suspect a missing dependency or something. The check runs (in check_for_xserver in libDrakX/common.pm) $::xtest = xf86misc::main::Xtest($ENV{DISPLAY}); and that is a DynaLoader the Xtest function apparently is in libDrakX/auto/xf86misc/main/main.so but apparently it fails... critical - not being able to run the distro's configuration tools (and that includes rpmdrake) is a stopper.
How you try running them? Do you try running from a terminal after sudo su or sg like that?
Keywords: (none) => NEEDINFOCC: (none) => thierry.vignaudComponent: Installer => RPM PackagesSeverity: critical => normal
from the menu / overlay-thingie, or from gnome-terminal, as live user or switched to root user using "su" - apart from drakconf that then starts in console mode, the message is the same for the other tools)
Keywords: NEEDINFO => (none)
You reduced severity - while I don't really agree with that, it seems OK, as it indeed requires more investigation regarding the exact circumstances. Rebooted into Mageia alpha2 (GNOME live iso), and at the beginning the tools did work. After having setup network connection, browsing a little, tried again and the tools won't launch. Logging out and back in (resets keyboard layout to en-US btw) makes the tools work again. It is unclear to me what triggers this (at least not yet) - would be great if you could ping QA folks to have a look at this, i.e. to check whether they can start drakconf or laucn the network-configuration via netapplet or launch rpmdrake also after using the system for a while.
It's very clear: the odds're high you changed hostname. I guess quite a lot of other tools then fail too...
well, I myself did not type in any hostname - if hostname was changed, then not by me, but as a sideeffect of connecting to (wireless) network - but I'll double check.
(oh, and obviously: just changing the hostname should not have such a massive effect on the distro's configuration tools - so if it turns out to be hostname related, the issue is just as valid as any other reason)
Changing the hostname has an effect on _all_ graphic tools
So indeed it is a changed hostname that makes the tools fail because there is no matching xauthority entry anymore. So two (and a half) solutions * network-manager must not change hostname or * when netowork-manager changes hostname, it must add the new hostname xauth add "$(hostname)/unix:0" MIT-MAGIC-COOKIE-1 $COOKIEOF_OLD_HOSTNAME or * draktools should not just print "no protocol specified, command cannot be run in console mode", but suggest "the hostname changed, please log out and back in". if (xauth list |grep $(hostname) >/dev/null 2>&1)
Summary: Fails to start drak-tools (like Mageia Control Center, rpmdrake, etc) in alpha2 (GNOME) => Fails to start drak-tools (like Mageia Control Center, rpmdrake, etc) in alpha2 (GNOME) (network-manager changes hostname)
Impossible: when you run any of our tools, they just see the new hostname, they don't know whether it has changed or not. Like other tools too.
Source RPM: drakxtools => (none)
Source RPM: (none) => network-manager
not impossible, only impossible when you don't bother to check whether current xauth list contains the new hostname. And even if you cannot tell whether the hostname was changed: adding a hint "this could also be because the hostname was changed since you last logged in" is nowhere near the impossible.
Sure it's possible to patch thousands of graphical applications for that...
This is a stupid response, as this is about Mageias drakx-based tools. All other GUI applications I tried did not have any problems launching despite the hostname change. You need to patch one single location for that.
Before saying other people are stupid, you should check running other programs as root too...
before making ridiculous statements like "it's possible to patch thousands of graphical applications for that.." you should think about how many applications are affected by a hostname change. So: please name a few that the regular desktop-user will try to launch after installing Mageia / when playing around with a live iso. (and that are not drak-based) (and note that I called that response stupid, not you)
What does your hostname change from, and what does it change to ? And do you know where these values come from , e.g. /etc/hosts, DHCP, default set in drakconnect ?
CC: (none) => ftg
Summary: Fails to start drak-tools (like Mageia Control Center, rpmdrake, etc) in alpha2 (GNOME) (network-manager changes hostname) => Fails to start drakxtools (like Mageia Control Center, rpmdrake, etc) in alpha2 (GNOME) (network-manager changes hostname)
from the live-ISO's default "localhost" / no hostname to one from DHCP (and wrongly so to a fqdn) linux.fritz.box or something like that. And after disconnecting to localhost.localdomain ( not being able to configure the dhcp vs static ip settings is bug #3798 ) ( being forced to use nm and not net-applet is bug #3799 - being forced to use network manager is a big step backwards regarding usability - for me at least) But it doesn't really matter where the value comes from - why does nm change the hostname in the first place?
removed the dash in the package name no maintainer, so cc'ing the two persons who committed networkmanager most often
CC: (none) => balcaen.john, dmorganec, marja11Source RPM: network-manager => networkmanager
@ Christian Did you run into this issue again with Mga2b2?
Keywords: (none) => NEEDINFO
If there was a live iso, I could test, but there has not been a new live-iso since reporting this bug.
(In reply to comment #19) > If there was a live iso, I could test, but there has not been a new live-iso > since reporting this bug. I missed that this was about the Live CD, sorry. *No ping before new LiveCD*
Whiteboard: (none) => LiveCD
it mostly applies to liveCD, yes. But if the installer doesn't explicitly set a hostname, it would also apply to an installed copy.
(In reply to comment #16) > from the live-ISO's default "localhost" / no hostname to one from DHCP (and > wrongly so to a fqdn) linux.fritz.box or something like that. And after > disconnecting to localhost.localdomain > > ( not being able to configure the dhcp vs static ip settings is bug #3798 ) > ( being forced to use nm and not net-applet is bug #3799 - being forced to use > network manager is a big step backwards regarding usability - for me at least) > > But it doesn't really matter where the value comes from - why does nm change > the hostname in the first place? If you have checked "Accept hostname from DHCP" in drakconnect (NEEDHOSTNAME=yes in ifcfg-xxx) then bringing up that interface is *supposed* to set the hostname. Are you using this option ? If you are not, and you really want the hostname to stay localhost, then it is a bug on the part of whatever is changing it. If you are using the option, and you really want the hostname returned by DHCP as your hostname, then the problem is a longstanding complaint of mine that the DM is allowed to come up before the network is connected, or equivalently that network-up (especially wireless) is started too late in the boot sequence to be finished by the time the DM starts.
> If you have checked "Accept hostname from DHCP" in drakconnect > (NEEDHOSTNAME=yes in ifcfg-xxx) then bringing up that interface is *supposed* > to set the hostname. Are you using this option ? If this option is set, then it is the default, as it is impossible to configure the connection in the Live iso (see bug 3798) But even when the option is active, it should come with a warning/notification that the current desktop-session will be rendered unusable for big parts, as administrative programs cannot be started anymore. This is a "dangerous" option and thus should not be default for wireless connections.
>This is a "dangerous" option and thus should not be default for wireless connections. It isn't the default, at least in a standard install or a standard configuration of an interface via drakconnect. Is the option set in your ifcfg or not ?
@ Christian Beta 3 CD's are released, please test whether this bug is still valid http://blog.mageia.org/en/2012/04/18/last-run-for-mageia-2-test-beta-3/
@ Christian Could you please reply to the previous question? If you won't reply within two weeks from now, I will have to close this bug as OLD. Thank you.
It is still valid... It still doesn't offer a way to configure the network *before* connecting - so how would a user even request or disable a option to use a hostname provided by a remote machine? (Network manager doesn't even expose such a configuration setting) Again I'm booting straight into the live iso, fire up netapplet to change the CRDA domain (that network manager stupidly doesn't allow to change/set and without no connection is possible at all), then use network-manager to connect. network-manager did fix the password-prompt so it is no longer modal and one can open a file with the password and use copy'n'paste more easily, but that's the only change I can observe. before: localhost, while connected: linux.fritz.box # cat /etc/sysconfig/network-scripts/ifcfg-wlan0 DEVICE=wlan0 BOOTPROTO=dhcp ONBOOT=yes # grep -i need /etc/sysconfig/network-scripts/ifcfg-* # # cat /etc/sysconfig/network-scripts/ifcfg-ESSID ESSID="ESSID" MODE=Managed KEY_MGMT=WPA-PSK TYPE=Wireless BOOTPROTO=dhcp DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no NAME=ESSID UUID=095affa7-677d-4390-bd7d-c9aa0d04a3b8 ONBOOT=yes HWADDR=00:22:5F:62:81:80 WPA_ALLOW_WPA=yes WPA_ALLOW_WPA2=yes PEERDNS=yes PEERROUTES=yes IPV6_PEERDNS=yes IPV6_PEERROUTES=yes IPV6_PRIVACY=rfc3041 # So not requested by me by clicking any button, not requested by the config files either. And even if it was: When the hostname is changed and has such a big impact, there *needs* to be a warning/information dialog that one needs to relogin to complete the change and not run into "random" problems.
@ Christian Thanks :) cc'ing docteam. Although we won't write documentation for networkmanager, we'll consider adding a few lines about this issue in the help for drakxtools and/or drakx-net (still to be written). @ Thierry Do you have a suggestion as to what to write? I don't use networkmanager and have no experience with this issue, it is possible that I do not fully comprehend it.
Keywords: NEEDINFO => (none)CC: (none) => doc-bugs
CC: (none) => mageia
Problem is still present with RC (ran into it myself). Reworded summary to point to the root cause of this issue.
Summary: Fails to start drakxtools (like Mageia Control Center, rpmdrake, etc) in alpha2 (GNOME) (network-manager changes hostname) => networkmanager changes hostname upon connect (resulting in failure to start any GUI applications under the running X-session)Whiteboard: LiveCD => (none)Severity: normal => major
CC: (none) => remco
This should be handled by the s2u daemon. Though, it seems to be broken when using NetworkManager. When using ifup/ifdown, s2u was notified by /etc/sysconfig/network-scripts/hostname.d/s2u NetworkManager should call this script as well when modifying the hostname.
Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja
it is still valid for Mageia 2. The final iso has just the same problem as the previous ones. No matter whether you use wired or wireless network: When using DHCP the hostname is changed, rendering the system useless for administrative stuff (at least for those users who don't know this issue and just wonder why nothing happens when they try to launch control-center or other tools)
Keywords: NEEDINFO => (none)Whiteboard: (none) => MGA2TOO
*** Bug 5230 has been marked as a duplicate of this bug. ***
CC: (none) => n54
*** Bug 6362 has been marked as a duplicate of this bug. ***
CC: (none) => tac
Summary: networkmanager changes hostname upon connect (resulting in failure to start any GUI applications under the running X-session) => networkmanager changes hostname upon connect but does not notify s2u (resulting in failure to start any GUI applications under the running X-session)
Still valid
any work around possible ?
CC: (none) => philippe.l
*** Bug 5962 has been marked as a duplicate of this bug. ***
CC: (none) => pip
*** Bug 6792 has been marked as a duplicate of this bug. ***
CC: (none) => yves.brungard_mageia
For the record a link from pterjan : http://old.nabble.com/Re%3A-X-session-and-hostname-changing-policy-p28917407.html So we can « workaround » eventually this problem by not using hostname for X authentification.
Strangely, I wasn't seeing this bug until a recent reinstall. Kwrite wouldn't start with sudo because of dbus issues, so I used mousepad. Now both Kwrite and mousepad give me "no protocol specified." I haven't tried kdesu, suggested to somebody who insisted on being root.
CC: (none) => laidlaws
Priority: Normal => release_blocker
*** Bug 7300 has been marked as a duplicate of this bug. ***
CC: (none) => info
Blocks: (none) => 7557
Please refer to the discussion in bug#7873 and bug#2160 and see if your problems with NM go away if you either allow GNOME (if you have it installed) to activate it or you install plasma-network-management under KDE, add it to your panel, and use it to configure your SSID. For NM to handle wireless correctly, it needs to create SSID-specific files of its own by parsing the ifcfg files produced by drakconnect. GNOME's nm-applet does this automatically, since it has no option to *not* use NM, but since NM isn't the default yet for other desktops, it doesn't happen automatically there. You'll need to install NM and let it start, and recreate your wireless interface with drakconnect specifying "Allow NM to control this interface". Please test and post your results, as whether NM works for all the chips involved when it's properly configured will have a significant impact on how it needs to be handled for non-GNOME desktops in MGA3.
I can confirm that the NM related things are gone away recently (mageia3). The upower service has to be restarted after resume still. I hear some 'ticks' inside laptop otherwise. Don't know what device produces it. They disappear after I restart upower service manually
(In reply to comment #42) n/a here
(In reply to comment #44) > (In reply to comment #42) > > n/a here Sorry I meant https://bugs.mageia.org/show_bug.cgi?id=7551
Re: comment@27 : The interesting thing here is that NEEDHOSTNAME isn't set explicitly at all. If NM is generating the ifcfg-ESSID (I assume it is, since it contains way more than the ifcfg's I see from drakconnect), *and* if dhclient/dhcpcd defaults to requesting hostname, then that would explain the behavior. drakconnect defaults to explicitly setting NEEDHOSTNAME=NO, so for consistency, either NM should do this as well, if possible, or dhclient/dhcpcd should change its default behavior on this for MGA. Another point is that "linux.fritz.box" is not the usual DHCP hostname artificially created by the client, which means that someone has configured dhcpd to return a meaningful hostname.
Hi, I've adjusted our xinitrc package, implementing the solution as proposed in comment 39 . I believe this should fix this issue. Once the new live cd's are available (I fear this was just too late to go into Alpha 3), I appreciate if people experiencing this problem can test it.
While this should work and be ok, it does not look like the proper fix in our architecture, see comment 30 and the bug title... Ideally, s2u should edit the X11 cookie when the hostname changes. It already has code to do this, it should just be hooked into some NM event (directly in s2u) or hook script (if some hostname.d scripts are run by NM on hostname change).
@blino: I see what you are saying. I'll have a further look at it and see if I can get this changed in networkmanager. Still, I think the change as I made it is good to keep as: 1) It makes the symptoms of the problem go away, resulting in a usable live-CD etc. for affected configurations; 2) It will also allow one to change the hostname manually or through other means than networkmanager while still allowing one to launch new X11 applications. Let me know if you disagree.
CC: (none) => andras.salamon
can we have a status on this bug? Is it still valid ?
CC: (none) => ennael1
My issue (Comment 40) was with trying to start Kwrite from a terminal as root. On a test, I can now start "sudo kwrite," but I can't su to root then start kwrite; it crashes. I am not sure if that is related to the principal bug at all.
no, it's completly unrelated and also not a bug (you need complete environnement with su -)
Keywords: (none) => NEEDINFOPriority: release_blocker => High
In that case, I will take myself off the CC list.
CC: laidlaws => (none)
The bug is not actual for me. However, I used to assign the hostname under fresh install. I'll take myself off the CC list
It's unknown as to if this is still valid by this user, as the issue never presented itself in M2. HOWEVER... seeing an interesting process here may shed some light (then again, I could be totally completely wrong). There may be a reason why I've not had the issue. Of note is my hostname dedanna.rockz.net. It used to be that I had dedanna.rocks.net for years and years, until I found strange things happening right after installation of M2 with it, such as "domain is in use, dedanna.rocks.net". After a check online, indeed, the domain rocks.net is now on park. I further came to find when I changed to dedanna.rockz.net, that even though I was changing the SYSTEM hostname only (via editing /etc/sysconfig/network), it was also acting as an FQDN, which was not the intention, or what I wanted (I do not own rocks.net or rockz.net domains). I wondered what was going on until I did another search on setting the hostname, and found that our system hostname can be set as our owned domain (thanks to Jason Blevins here: http://jblevins.org/log/hostname). Note: My system hostname is actually a sub-domain format: dedanna.rockz.net (it was mentioned earlier in this bug about having that format for the system hostname), I set the hostname immediately after installation of my distribution (in all cases) permanently, and I've had absolutely no problem with draktools, other programs running, or with my hostname changing. It has remained permanent (and now that I know the difference of system hostname vs. an FQDN, I may be able to change back to dedanna.rocks.net). I also keep my CRDA set to the area I'm in, in the world. Why it "went" initially as an FQDN, is unknown by this user. Food for thought. .:[ dedanna@dedanna.rockz.net : 19:40:30 : ~ ]:. :) cat /etc/sysconfig/network HOSTNAME=dedanna.rockz.net NETWORKING=yes CRDA_DOMAIN=GB That was my only single hostname issue, all along, with Mageia 2.
CC: (none) => skeeter1029
Oh, this was on a netbook, Toshiba NB255, wireless and wired both.
CC: (none) => nic
(In reply to Nic Baxter from comment #57) > can we have a status on this bug? Is it still valid ? There was no reply and the only activity on this bug since april 2013 was your question. Closing as OLD Feel free to reopen if needed, or to file a new bug report (this one already contains too many comments, reading them all is exhausting)
Resolution: (none) => OLDStatus: NEW => RESOLVED