Created attachment 5042 [details]
Urpmi plasma-applet-nm - kded crashes

Created attachment 5043 [details]
Place "Network management" widget onto the bar - plasma crashes

Created attachment 5044 [details]
/var/log/dmesg

Contents of /var/log/dmesg which show why dbus does not start automatically. On login i have dbus.service "inactive (dead)" on unknown reason.

Assigning to Colin, who can hopefully figure out what is causing
Breaking ordering cycle by deleting job dbus.socket/start

Note this is a Mageia 1 system, upgraded to 2, then 3, then 4.

(In reply to Dave Hodgins from comment #4)
> Note this is a Mageia 1 system, upgraded to 2, then 3, then 4.
Before it was Mandriva 2010.1 (with mib/mnb/plf repos) and so on.

(In reply to Albert Rayanov from comment #3)
> Created attachment 5044 [details]
> /var/log/dmesg
> 
> Contents of /var/log/dmesg which show why dbus does not start automatically.
> On login i have dbus.service "inactive (dead)" on unknown reason.

It would appear to me that the ordering cycle is due to the audit package. It's the only one in there that looks non-obvious.

Could you try disabling it (systemctl disable auditd.service) and rebooting and see if that fixes the ordering cycle stuff?

Looking at the package the initscript appears to not have any LSB headers which means that we can only go on the chkconfig symlink numbers and these are typically not well thought out and can cause ordering cycle problems. We did a big push to fix all these during MGA2 cycle (I had a big spreadsheet) to add LSB headers, but sadly it seems this one was missed.

If the above test works, then we can issue an update to the audit package to add a native systemd unit and drop the sysvinit one.

HTHs

(In reply to Colin Guthrie from comment #6)
> Could you try disabling it (systemctl disable auditd.service) and rebooting
> and see if that fixes the ordering cycle stuff?

Thanks, I confirm that disabling auditd.service lets dbus.service and NetworkManager.service work together.

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

Cool, so it seems this is due to overzealous patch removal in the audit package that removed my initscript patch.

audit these days has native systemd support so I've switched cauldron to that tho' as I don't know the package, I cannot test it.

Thomas, can you take a look at this (seeing as you removed my patch!) and work out what's best for MGA4? Either my changes in cauldron are good and you can just merge them to MGA4 + fiddle with rel and subrel and submit it to updates_testing, or you can restore my previous patch and submit that as an update to MGA4 instead.

Will reopen the bug as it's still a bug that needs fixed.

Status: RESOLVED => REOPENED
Resolution: WORKSFORME => (none)
Assignee: mageia => thomas
Summary: Plasma-applet-nm crashes kded on install, plasma-desktop on post, and D-Bus providing bad ptr => audit initscript causes ordering cycles at boot leading to dbus+NetworkManager failure incl. KDE plasma applet crashes

(In reply to Colin Guthrie from comment #8)
> Cool, so it seems this is due to overzealous patch removal in the audit
> package that removed my initscript patch.
> 
> audit these days has native systemd support so I've switched cauldron to
> that tho' as I don't know the package, I cannot test it.
> 
> Thomas, can you take a look at this (seeing as you removed my patch!) and
> work out what's best for MGA4? Either my changes in cauldron are good and
> you can just merge them to MGA4 + fiddle with rel and subrel and submit it
> to updates_testing, or you can restore my previous patch and submit that as
> an update to MGA4 instead.
> 
> Will reopen the bug as it's still a bug that needs fixed.

Thank Colin. You invested a lot of work.(In reply to Albert Rayanov from comment #3)
> Created attachment 5044 [details]
> /var/log/dmesg
> 
> Contents of /var/log/dmesg which show why dbus does not start automatically.
> On login i have dbus.service "inactive (dead)" on unknown reason.

(In reply to Colin Guthrie from comment #8)
> Cool, so it seems this is due to overzealous patch removal in the audit
> package that removed my initscript patch.
> 
> audit these days has native systemd support so I've switched cauldron to
> that tho' as I don't know the package, I cannot test it.
> 
> Thomas, can you take a look at this (seeing as you removed my patch!) and
> work out what's best for MGA4? Either my changes in cauldron are good and
> you can just merge them to MGA4 + fiddle with rel and subrel and submit it
> to updates_testing, or you can restore my previous patch and submit that as
> an update to MGA4 instead.
> 
> Will reopen the bug as it's still a bug that needs fixed.

Colin, you did a lot of work. Thanks a lot.
I cannot duplicate the problem. It may just be different on each installation.

But I have seen cycling problems in the journal.

I have back-ported your changes to mga4. The updated package is in updates testing with rel. 2.1

I was trying to install it, but get the following error:
 1/1: audit                 #########################################################################################################
Failed to issue method call: Operation refused, unit auditd.service may be requested by dependency only.
warning: %post(audit-2.3.2-2.1.mga4.x86_64) scriptlet failed, exit status 4
ERROR: 'script' failed for audit-2.3.2-2.1.mga4.x86_64: 

When manual starting it, it succeeds

(In reply to Thomas Spuhler from comment #10)
> I was trying to install it, but get the following error
Thomas, I had installed audit package using mandriva 2010.1 distribution (or newer) and after a long time upgraded it to Mageia from 1 to 4.

The packages are now in updates_testing:
audit-2.3.2-2.4.mga4.src.rpm
audit-2.3.2-2.4.mga4.x86_64.rpm
lib64audit1-2.3.2-2.4.mga4.x86_64.rpm
lib64audit-devel-2.3.2-2.4.mga4.x86_64.rpm
lib64auparse0-2.3.2-2.4.mga4.x86_64.rpm
lib64auparse-devel-2.3.2-2.4.mga4.x86_64.rpm
python-audit-2.3.2-2.4.mga4.x86_64.rpm
audispd-plugins-2.3.2-2.4.mga4.x86_64.rpm
audit-debuginfo-2.3.2-2.4.mga4.x86_64.rpm
and same for i586 packages

I have tested the installation and removal of audit
The install reported a missing audit.conf file, but it's not provided (same by upstream, Fedora) I believe the user is supposed to provide it.

After installation of audit, the auditd.service was enabled and running. The opposite after deleting. I cannot test the race condition because I never experienced it.

Status: REOPENED => ASSIGNED
CC: (none) => thomas
Assignee: thomas => qa-bugs

Testing MGA4 64-bit real hardware

I had installed already lib64audit1, lib64seaudit4, python-audit.
Added from Release media audit, lib64auparse0.
Rebooted. The auditd service was enabled and running.

Updated from Core Updates Testing:
 audit-2.3.2-2.4.mga4.x86_64.rpm
 lib64audit1-2.3.2-2.4.mga4.x86_64.rpm
 lib64auparse0-2.3.2-2.4.mga4.x86_64.rpm
 python-audit-2.3.2-2.4.mga4.x86_64.rpm
[note NO lib64seaudit4]

Rebooted. The auditd service was enabled and running. Under KDE, the network taskbar applet worked OK - it always had done. So no apparent change.
Is this enough for MGA4-64-OK ?

CC: (none) => lewyssmith

Testing complete mga4 32

As discussed, just ensuring the updated packages install cleanly.

We don't have an advisory text for this update. I've uploaded one more or less in line with the summary..

---
This update corrects audit initscripts which caused ordering cycles at boot, leading to dbus and NetworkManager failure.
---

Please amend it if it needs more detail or is incorrect.


Advisory uploaded. Validating.

Could sysadmin please push to 4 updates

Thanks

Keywords: (none) => validated_update
Whiteboard: MGA4-64-OK => advisory mga4-32-ok MGA4-64-OK
CC: (none) => sysadmin-bugs

Update pushed:
http://advisories.mageia.org/MGAA-2014-0120.html

Status: ASSIGNED => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED