Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1346082 - systemd reports multiple failures after upgrade to F24
Summary: systemd reports multiple failures after upgrade to F24
Keywords:
Status: CLOSED DUPLICATE of bug 1350686
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 24
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-13 22:05 UTC by Bojan Smojver
Modified: 2016-07-22 13:12 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-22 06:34:19 UTC
Type: Bug


Attachments (Terms of Use)

Description Bojan Smojver 2016-06-13 22:05:29 UTC
Description of problem:

Jun 13 18:28:27: Failed to start Rebuild Hardware Database.
Jun 13 18:28:27: multipathd.service: Start request repeated too quickly.
Jun 13 18:28:27: Failed to start Device-Mapper Multipath Device Controller.
Jun 13 18:28:27: systemd-binfmt.service: Start request repeated too quickly.
Jun 13 18:28:27: Failed to start Set Up Additional Binary Formats.
Jun 13 18:28:27: systemd-modules-load.service: Start request repeated too quickly.
Jun 13 18:28:27: Failed to start Load Kernel Modules.
Jun 13 18:28:27: sys-fs-fuse-connections.mount: Start request repeated too quickly.
Jun 13 18:28:27: Failed to mount FUSE Control File System.
Jun 13 18:28:27: ldconfig.service: Start request repeated too quickly.
Jun 13 18:28:27: Failed to start Rebuild Dynamic Linker Cache.
Jun 13 18:28:27: systemd-firstboot.service: Start request repeated too quickly.
Jun 13 18:28:27: Failed to start First Boot Wizard.
Jun 13 18:28:27: systemd-sysusers.service: Start request repeated too quickly.
Jun 13 18:28:27: Failed to start Create System Users.
Jun 13 18:28:27: systemd-ask-password-console.path: Start request repeated too quickly.
Jun 13 18:28:27: Failed to start Dispatch Password Requests to Console Directory Watch.

Version-Release number of selected component (if applicable):
systemd-229-8.fc24.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. Boot (ThinkPad T450s, upgrade from F23 using distro-sync).
2. Watch the failures in journal, console, boot.log etc.

Actual results:
Multiple failed starts.

Expected results:
Worked on F23.

Additional info:

Possibly:

https://github.com/systemd/systemd/issues/2684

Comment 1 Jan Synacek 2016-06-14 05:55:00 UTC
I've been running F24 since pre-alpha on a T440s and don't remember seeing anything like this. Did you reboot after update? Does it happen every boot? If yes, does setting selinux to permissive help?

Comment 2 Bojan Smojver 2016-06-14 06:32:42 UTC
(In reply to Jan Synacek from comment #1)
> Did you reboot after update?

Yes, multiple times.

> Does it happen every boot?

Yes.

> If yes, does setting selinux to permissive help?

Tried that, but sadly no.

If it helps or is related, I also noticed other strange anomalies, like nscd not picking up /etc/resolv.conf, which then results in DNS not working correctly. So, I worked around that by putting something like this in /etc/systemd/system/nscd.service.d:
----------
[Unit]
Requires=network-online.target
After=network-online.target
----------

Comment 3 Bojan Smojver 2016-06-15 05:03:50 UTC
Output of the status command:
-------------------
● systemd-hwdb-update.service - Rebuild Hardware Database
   Loaded: loaded (/usr/lib/systemd/system/systemd-hwdb-update.service; static; vendor preset: disabled)
   Active: inactive (dead)
Condition: start condition failed at Tue 2016-06-14 13:21:42 AEST; 1 day 1h ago
     Docs: man:hwdb(7)
           man:systemd-hwdb(8)

Jun 14 13:21:42 <host> systemd[1]: systemd-hwdb-update.service: Start request repeated too quickly.
Jun 14 13:21:42 <host> systemd[1]: Failed to start Rebuild Hardware Database.
-------------------

So, the condition failed (probably because /etc/udev/hwdb.d is empty), so this wasn't supposed to be started anyway, if I understand things correctly. So, why does systemd repeat the start request?

Maybe my computer is too fast... :-)

Every single unit in that list failed the same way: start condition failed.

Comment 4 Jan Synacek 2016-06-15 08:39:52 UTC
Zbyszek, any idea?

Comment 5 perutka.ondrej 2016-07-07 10:31:18 UTC
I have the same problem on my ThinkPad W520 after upgrading from F23 to F24.

Comment 6 Arkady L. Shane 2016-07-18 07:34:39 UTC
Yes, Patch https://github.com/systemd/systemd/commit/7629ec4642b03517742d09b7303c204fddf82108 fixes this issue.

Comment 7 Bojan Smojver 2016-07-20 07:21:08 UTC
Could we get a build into testing based on the above patch?

Comment 8 Bojan Smojver 2016-07-22 06:34:19 UTC

*** This bug has been marked as a duplicate of bug 1350686 ***


Note You need to log in before you can comment on or make changes to this bug.