Hello, I do not whether the problem comes from the dbus update. Anyway, the problem I have for now matches well wih the yesterday update. So when I start Mageia, it takes a really long time from the time I push the power button and the time where the menu bar appears (between 5 and 10 minutes) And even when the menu bar is there, everything is not working fine. For example it seems that pulseaudio is not running. Another example is that firefox freezes during a long time when flash is used. The freeze terminates when flash has crashed. And so on I do not what information do you need to identify my problem so please ask. Reproducible: Steps to Reproduce:
Depends on: (none) => 14102, 14249
Hmmm, it seems that the problem was also related to https://bugs.mageia.org/show_bug.cgi?id=14249 (cpupower). I say "it was" because it disappeared. I decided to install all the updates in the Testing repos and after a reboot, it worked. (pulseaudio is gone back, flash does not crash any more, ...)
As with the other bug, have you rebooted since installing the update?
Yes I rebooted after installing the update. But before updating Mageia, I rebooted three or four times and it did not change anything (Mageia was still very slow). So rebooted several times seem to not solve the problem before I installed the updates.
As indicated in #14449, for me the problem was gone without any new updates applied, even from testing.
CC: (none) => lists.jjorge
Hmmm, I spoke too fast. I just rebooted my computer and the slowness is gone back. For now, I tried to reboot only once without any change.
*** Bug 14250 has been marked as a duplicate of this bug. ***
CC: (none) => christian-maryse.fischer
Hello Y have 4 Mageia4 on 3 conputers. When boot is in text mode , and then login and startx , all work fine. New dbus is good, but loading has a problem.
The problems appear only on some computers (laptop, old PC, etc.) but not on others (new PC). If you install the previous RPM of dbus (dbus-1.6.18-1.3.mga4), the problems disappear. explanations : With the last RPM of dbus dbus-1.6.18-1.4.mga4), some computers become very slow with the following errors (command used : 'journalctl /usr/bin/dbus-daemon'): -- Reboot -- oct. 09 14:37:35 localhost dbus[1203]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out oct. 09 14:37:35 localhost dbus[1203]: [system] Failed to activate service 'org.freedesktop.PolicyKit1': timed out oct. 09 14:37:35 localhost dbus[1203]: [system] Successfully activated service 'org.freedesktop.login1' oct. 09 14:37:46 localhost dbus[1203]: [system] Failed to activate service 'org.freedesktop.ColorManager': timed out oct. 09 14:37:52 localhost dbus[1203]: [system] Activating systemd to hand-off: service name='org.freedesktop.UPower' unit='upower.service' oct. 09 14:38:00 localhost dbus[1203]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out oct. 09 14:38:17 localhost dbus[1203]: [system] Failed to activate service 'org.freedesktop.UPower': timed out oct. 09 14 You can install the previous RPM like that : - download on the répository the previous rpm (dbus-1.6.18-1.3.mga4.x86_64.rpm) for your architecture in the uptdate section - install it with the command : 'rpm -Uhv ./dbus-1.6.18-1.3.mga4.x86_64.rpm --force' - reboot The errors have disappeared : -- Reboot -- oct. 09 17:10:12 localhost dbus[1192]: [system] Successfully activated service 'org.freedesktop.systemd1' oct. 09 17:10:13 localhost dbus[1192]: [system] Activating via systemd: service name='org.freedesktop.ColorManager' unit='colord.service' oct. 09 17:10:13 localhost dbus[1192]: [system] Activating via systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service' oct. 09 17:10:13 localhost dbus[1192]: [system] Successfully activated service 'org.freedesktop.ColorManager' oct. 09 17:10:13 localhost dbus[1192]: [system] Successfully activated service 'org.freedesktop.PolicyKit1' oct. 09 17:10:22 localhost dbus[1192]: [system] Activating via systemd: service name='org.freedesktop.UDisks2' unit='udisks2.service' oct. 09 17:10:25 localhost dbus[1192]: [system] Successfully activated service 'org.freedesktop.UDisks2'
CC: (none) => richard
Yes conputers AMD ( prosessors A4 and E1 ) are working properly with new dbus. only my old "core2duo" have to download to the old dbus. with : urpmi --downgrade dbus-1.6.18-1.3.mga4 lib64dbus1_3-1.6.18-1.3.mga4 dbus-x11-1.6.18-1.3.mga4 now boot is good on that old computer.
Thank you Christian for the "downgrade" option. It's easier like that.
Seeing the same problem with 32-bit desktop machines, both an Intel P4 and an AMD Sempron 3100+. The first uses the desktop kernel, the other uses the server kernel. Repeated boots do not solve the problem. I have discovered that booting into safe mode and using the [control-D] command to continue DOES fix things, but only for about three boots. I only just discovered this bug report, and will not have the time to look into downgrading dbus until later today. When I do, I will report back here with the results.
CC: (none) => andrewsfarm
On a 32 bit system you will need to downgrade libdbus1_3... and not lib64dbus1_3...
To add my 2c (or to increase the confusion): in contrary to Christian, my desktop and laptop (both Mageia4) are affected by the new dbus. The desktop has AMD FX(tm)-6100 Six-Core Processor, and the laptop has AMD Phenom II N950 Quad core.
CC: (none) => herman.viaene
CC: (none) => doktor5000, lmenutSee Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=14249
Downgrading dbus seems to eliminate the problem, just as with everybody else. Another symptom: When the problem manifests, my customized power management settings are ignored. Also, the computer is very slow to shut down.
Hi, I also encountered this problem and hounded me for days. I thought I messed up the system because I was trying to configure conky.What I did was to reformat my laptop and install Gnome3. After all the updates, I also noticed the same pattern but to a lesser extent. At one point, I boot my laptop and it gets stucked for a very long time (like waiting for 5 minutes) and I just have to restart by doing CTRL + ALT + F2 and then CTRL + ALT + DEL. The system would reboot and then it proceeds to my login screen. It seems to happen every other reboot / shutdown-power on. Since the preferred desktop of Mageia is KDE, I will reformat back to KDE and just follow the advice given here. My Laptop is MSI CX41 Intel i5 Ivy Bridge Processor 3210m Dual graphics - HD4000 Graphics and AMD Radeon 7670m I'm not sure if this helps. When I was still on KDE, I noticed that when I get into my desktop to a working state (which takes at around 15 minutes) my conky is running but lacked some details. I am specifically referring to a program (hddtemp) to display information on my conky. Running it manually (via terminal) produces an error something with permissions and polkitd.
CC: (none) => lewmail101-mailbox
Experienced this myself on my mums laptop. The only difference with this machine was it updated dbus and kernel at the same time. I suspect this might have something to do with it. I had to boot runlevel 3 to get to a login. After downgrading dbus and rebooting it was back to normal. Updating dbus again caused no regression. I have the journal if it's needed.
CC: (none) => tmb
CC: (none) => eeeemail
CC: (none) => wrw105
(In reply to christian fischer from comment #9) > urpmi --downgrade dbus-1.6.18-1.3.mga4 lib64dbus1_3-1.6.18-1.3.mga4 > dbus-x11-1.6.18-1.3.mga4 > now boot is good on that old computer. These packages made huge problems for my Dell Dimension 8300, but now that I downgraded the packages according to this command everything was solved. I also made the following additions to /etc/urpmi/skip.list: QUOTE /^dbus-1.6.18-1.4.mga4/ /^libdbus1_3-1.6.18-1.4.mga4/ /^dbus-x11-1.6.18-1.4.mga4/ END QUOTE
CC: (none) => ole.reier
I have submitted to core/updates_testing a dbus that fixed the boot problem on my 2 systems : to workaround a CVE, the timeout was changed from 30s to 5s, which triggered timeout bugs on some systems. I have found that a 10s timeout both is better than 30s, and does not trigger timeouts anymore. Please, test dbus-1.6.18-1.5.mga4 and report if it fixes your systems, so that we can push it into regular updates.
Status: NEW => ASSIGNED
I installed dbus, dbus-x11, lib64dbus-devel, libdbus1_3, lib64dbus1_3 (with 1.6.18-1.5.mga4 at the end of the package name) and I have still the problem: Mageia is really slow. I will now test the procedure given by Thomas Backlund (https://bugs.mageia.org/show_bug.cgi?id=14249#c37) and I come back
Since there is so much writing about the computer being slow I believe I should add my experience. I am talking about a Dell Dimension 8300, a 32-bit computer. The problems was that, yes, KDE took 20 times longer to load, but the screens were messed up, that was worse. I have a dual screen system with a DVI 1920x1080 and a VGA 1680x1050. My system then shows a screen of almost 3600x1080. (1920+1680=3600) Because of the dbus-1.6.18-1.4 packages the VGA screen became only a clone of the DVI screen, and just the upper left part of the DVI screen which has more pixels. The VGA screen was also not present in the System Settings - Display Configuration. But when I started the machine in safe mode and press ctrl-D when I am asked to do so or give the root password, the machine started as it used to with no display problems. I also tried to start the machine in normal mode after safe mode, but it made no difference for the normal mode situation.
OK, there is now a dbus-1.6.18-1.6.mga4 in updates_testing so both i586 and x86_64 users can test
New 32-bit packages worked OK with a Dell Dimension E310 (P4 processor, desktop kernel) but did not work with a machine with an AMD Sempron 3100+ processor and the server kernel. With the latter machine I got two reboots before failure, and as before booting into safe mode and continuing using Control-D avoids the problem. Please post the procedure for downgrading from the test packages. I get a message that the ***.3 versions aren't in the database.
Inability to downgrade was solved by changing from MIRRORLIST to the specific US kernel.org mirror.
Installation of dbus-1.6.18-1.6.mga4 and cie solves the problem of slowness here. Mageia boots as before. Thank you.
On a laptop and a Desktop PC which have had the issue with 1.6.18-4, all is ok now with the version "1.6.18-1.6" of dbus and lib64dbus
Confirm dbus-1.6.18-1.6.mga4 update on 64-bit laptop (AMD- Phenom N950) with KDE desktop works OK , no slowness seen.
dbus-1.6.18-1.6.mga4 update works on a 64bit i5 system npw. Booting fast and reliable to KDE, Mate or Cinnamon now. Thanky you!
CC: (none) => bernd.deinzer
@Thomas: Do you want QA to get started with this one, or do you plan to investigate some more?
CC: (none) => remi
Note to testers, the procedure to test is easy, install the update, reboot and check that everything still works. Now if you didn't have an issue with the dbus released in MGASA-2014-0395, you shouldnt see any issue with this update either as the only change is an added 15s to the default auth_timeout. Now the -1.6.mga4 had 15s timeout, but some issues still remained, so I bumped it to 20s in -1.7.mga4 wich is now handed over to QA And even if no "official bug-report" has showed up against mga3 yet, we do the same there to "be safe" as it simply might mean it has less users with affected systems nowdays... Advisory: Updated dbus backages fixes a regression with default auth_timeout As part of the earlier security update for dbus (MGASA-2014-0395) default auth_timeout was changed from 30s to 5s to make it harder to abuse on systems with no auth_timeout defined. As it turns out it 5s is not enough for some systems to boot up and activate services properly, so they ended up with services failing to start up, leading to slow or unusable systems. This update changes the default auth_timeout to 20s wich appears to be enough to fix the issue. References: https://bugs.mageia.org/show_bug.cgi?id=14251 https://bugs.mageia.org/show_bug.cgi?id=14249 Mga4: SRPMS: dbus-1.6.18-1.7.mga4.src.rpm i586: dbus-1.6.18-1.7.mga4.i586.rpm dbus-doc-1.6.18-1.7.mga4.noarch.rpm dbus-x11-1.6.18-1.7.mga4.i586.rpm libdbus1_3-1.6.18-1.7.mga4.i586.rpm libdbus-devel-1.6.18-1.7.mga4.i586.rpm x86_64: dbus-1.6.18-1.7.mga4.x86_64.rpm dbus-doc-1.6.18-1.7.mga4.noarch.rpm dbus-x11-1.6.18-1.7.mga4.x86_64.rpm lib64dbus1_3-1.6.18-1.7.mga4.x86_64.rpm lib64dbus-devel-1.6.18-1.7.mga4.x86_64.rpm Mga3: SRPMS: dbus-1.6.8-4.7.mga3.src.rpm i586: dbus-1.6.8-4.7.mga3.i586.rpm dbus-doc-1.6.8-4.7.mga3.noarch.rpm dbus-x11-1.6.8-4.7.mga3.i586.rpm libdbus1_3-1.6.8-4.7.mga3.i586.rpm libdbus-devel-1.6.8-4.7.mga3.i586.rpm x86_64: dbus-1.6.8-4.7.mga3.x86_64.rpm dbus-doc-1.6.8-4.7.mga3.noarch.rpm dbus-x11-1.6.8-4.7.mga3.x86_64.rpm lib64dbus1_3-1.6.8-4.7.mga3.x86_64.rpm lib64dbus-devel-1.6.8-4.7.mga3.x86_64.rpm
Hardware: x86_64 => AllAssignee: bugsquad => qa-bugsWhiteboard: (none) => MGA3TOO
Tested OK for MGA4_32
Whiteboard: MGA3TOO => MGA3TOO MGA4-32-OK
Been running mga4 32 and 64 with this for a few days, no problems to report. Indeed, I had an issue with MCC not starting after the previous update and that's been resolved as well.
Whiteboard: MGA3TOO MGA4-32-OK => MGA3TOO MGA4-32-OK mga4-64-ok
(In reply to Bill Wilkinson from comment #31) Are you sure? dbus-1.6.18-1.7.mga4 only became available today.
I guess he means dbus-1.6.18-1.6.mga4 released on 2014-10-22 The dbus-1.6.18-1.7.mga4 only added 5 more seconds to the auth_timeout, so if the 1.6 works good, so will 1.7
Just tried the newest one on the machine that failed with the .6 version, and all seems OK now. Did five reboots with no problems. Could only get 1 or 2 before.
(In reply to Thomas Andrews from comment #34) > Just tried the newest one on the machine that failed with the .6 version, > and all seems OK now. Did five reboots with no problems. Could only get 1 or > 2 before. Awesome :) Your report in comment 22 was one of the reasons I added an additional 5s in the .7 version
tested updated packages on my affected mediacenter (mga4-64bit) and performed several reboots: everything is fine. Tested same update on my laptop (also mga4-64bit), which is not affected and after several reboots no regression detected.
CC: (none) => marc.lattemann
CC: marc.lattemann => (none)
(In reply to Thomas Backlund from comment #35) > > Your report in comment 22 was one of the reasons I added an additional 5s in > the .7 version Glad to be of help. I guess these two creaky old systems can still be useful after all.
I tested Mageia 3 64&32 ok i added whiteboard it.
CC: (none) => ozkysterWhiteboard: MGA3TOO MGA4-32-OK mga4-64-ok => MGA3TOO MGA4-32-OK MGA4-64-OK MGA3-32-OK MGA3-64-OK
Advisory uploaded. Validating the update, please push dbus to 3 & 4 core/updates.
Keywords: (none) => validated_updateWhiteboard: MGA3TOO MGA4-32-OK MGA4-64-OK MGA3-32-OK MGA3-64-OK => MGA3TOO MGA4-32-OK MGA4-64-OK MGA3-32-OK MGA3-64-OK advisoryCC: (none) => sysadmin-bugs
Source RPM: (none) => dbus-1.6.18-1.4.mga4
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGAA-2014-0182.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
After applying the latest updates, the problem appears again. I downgraded dbus as stated above, and restarted. Now the computer is running well.
In comment #13, you report a laptop and a desktop that both experienced the bug. In comment #26 you report having tested the update successfully only on your laptop. Can you confirm that you did not test the update on your desktop and that it is that system that is now experiencing the bug.
hello for mi all is good
I did not test the 1.6 version on the desktop, but a soon as the 1.7 version appeared on the repository, I did this update. So I reverted back from 1.7 to 1.3, and running it now. In fact, I had two laptops with Mageia4 affected, I checked the one I tested in comment 26, and that one is running 1.7 without problems. Should I reinstall the latest updates to check if the problem replicates?
(In reply to Herman Viaene from comment #44) > I did not test the 1.6 version on the desktop, but a soon as the 1.7 version > appeared on the repository, I did this update. So I reverted back from 1.7 > to 1.3, and running it now. I had the bug this morning on a system that worked nicely with 1.7. A single reboot fixed it. So: - it looks like 20s timeout is not enough for everyone - I think you should try again 1.7 and, with several boots, report if it fails often.
OK, I reinstalled 1.7 and rebooted, all OK for now. I'll keep an eye on it.
I too had one boot with the AMD machine that 1.6 didn't fix where it appeared to have the problem resurface. I'm not sure about the slow boot, as I had started it and then was called away and so didn't see it. But when I got back I had no audio, which was one of the symptoms. It went away on another reboot.
To me this problem is not solved. Reinstalled 1.7, made sure the PC is fully updated. First reboot was OK (mentioned in comment 46) Second reboot was again very slow. I let it go through and then tried (as recommended above) to reboot. But that gave a lot of problems. 1. I choose "Leave - Restart" from the menu, but that made KDE only unresponsive, but did not close it. The screeb remained at the normal KDE with splash and panel, but did not react to any mouse action. After some minutes, I recurred to Ctrl-Alt-Backspace, and that brought me back to the login screen. There I choose again for "Shutdown - Restart" and that removed the splash, but leaves me again with a hanging system. The last messages on the screen (5 or 6 of them) all refer to "rpc.mountd: could not open connection for udp6 (or tcp6)". I had to use the reset button on the PC to get anything happening. 2. The third reboot was also slow, especially starting up KDE. It took about 8 minutes to get to a workable state, the login screen appeared a but slower than usually, then splash appeared after about 5 min, but then another 3 min. passed before the bottom panel appeared and KDE became usable. One of the QA testers suggested that .xsession_errors might give injformation, so I attach it. In case you wonder at that file: I have firefox and thunderbird and 4 files to be opened with Kwrite in Autostart. 3. Once KDE is on, some things like Kmahjongg start in a jiffy, but dolphin from the "Home" button on the desktop takes 6 min to open its (then still blank) window. Starting it from the CLI gives [herman@xxxx ~]$ dolphin Object::connect: No such signal QDBusAbstractInterface::DeviceAdded(QString) Object::connect: No such signal QDBusAbstractInterface::DeviceRemoved(QString) Object::connect: No such signal QDBusAbstractInterface::DeviceAdded(QDBusObjectPath) Object::connect: No such signal QDBusAbstractInterface::DeviceRemoved(QDBusObjectPath) dolphin(29443)/kdecore (K*TimeZone*): KSystemTimeZones: ktimezoned initialize() D-Bus call failed: "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken." Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.TimedOut" "Activation of org.freedesktop.UDisks2 timed out" Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.TimedOut" "Activation of org.freedesktop.UDisks2 timed out" Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.TimedOut" "Activation of org.freedesktop.UDisks2 timed out" Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.TimedOut" and more of these UDisks timeouts. The messages at the top on QDBusAbstractInterface are the same as in the .xsession_errors file. I'll defintely revert back to dbus 1.3 till more positive news.
Created attachment 5574 [details] Errors on slow startup
Attachment 5574 mime type: application/octet-stream => text/plain
Comment 48 was on my desktop, now my laptop has the issue again.I'll check if there is more/other info in its .xsession_errors. And BTW, this lpatop has nothing in its Autostart.
Tested on the same desktop (6Core AMD with 8Gb mem) and with another user than my usually own. Reinstalled dbus 1.7 3 reboots were OK, 4 and 5 were again very slow, 6 and 7 again OK.
The more I read, the more I think we should go back to 30 seconds timeout : lots of us are experiencing at least 10% boot errors with 20 seconds timeout. I've just got it again.
I have now experienced the problem twice more on my AMD desktop with the 1.7 dbus in place. It's happening with much less frequency than before, at least. I haven't counted successful vs. slow boots, but my impression is that 10% slow is about right.
Can you try dbus-1.6.18-1.8.mga4 And report your findings in bug: https://bugs.mageia.org/show_bug.cgi?id=14494
Reported upstream, <https://bugs.freedesktop.org/show_bug.cgi?id=86431>. Mageia security / D-Bus maintainers: please report regressions upstream, particularly if they are regressions in security updates. We can't fix bugs we don't know about.
CC: (none) => simon.mcvittieSee Also: (none) => https://bugs.freedesktop.org/show_bug.cgi?id=86431
If you have had this bug in the past, can you help me fix it for everyone by providing more information, or doing some testing for me? Please see <https://bugs.mageia.org/show_bug.cgi?id=14249#c54> for details.
> The more I read, the more I think we should go back to 30 seconds timeout FYI, I did this in 1.6.28 and 1.8.12 upstream.