This update reverts an upstream change which causes problems with both Atomic and live image boot. For live image boots, quite often booting would fail with a kernel null pointer dereference, which turns out to be triggered by the change in systemd's behaviour.
Updates may require up to 24 hours to propagate to mirrors. If the following command doesn't work, please retry later:
sudo dnf upgrade --refresh --advisory=FEDORA-2015-2655Please log in to add feedback.
| 0 | 0 | Test Case Services start |
| 0 | 0 | Test Case base service manipulation |
| 0 | 0 | Test Case base services start |
| 0 | 0 | Test Case base shutdown/reboot |
| 0 | 0 | Test Case User:Tablepc/Draft testcase reboot |
This update has been submitted for testing by adamwill.
Taskotron: depcheck test PASSED on i386. Result log: https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/41336/steps/runtask/logs/stdio (results are informative only)
Taskotron: depcheck test PASSED on x86_64. Result log: https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/41336/steps/runtask/logs/stdio (results are informative only)
This update is currently being pushed to the Fedora 22 testing updates repository.
This update has been pushed to testing
All OK - Tested on F22 X86_64
no problem
Critical path update approved
works for me
works fine
This update has been obsoleted by https://admin.fedoraproject.org/updates/systemd-219-6.fc22
This update has been submitted for stable by ausil.
This update is currently being pushed to the Fedora 22 stable updates repository.
This update is currently being pushed to the Fedora 22 stable updates repository.
This update has been pushed to stable
Taskotron: depcheck test FAILED on x86_64. Result log: https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/44896/steps/runtask/logs/stdio (results are informative only)
Automatic push to stable based on karma has been disabled for this update due to failure of an AutoQA test. Update submitter, please check the AutoQA test result and see if there is a valid problem to be fixed here, and fix it if so. If the failure is a mistake on AutoQA's part, you can re-enable the automatic push feature for this update if you like, or push it stable manually once it reaches the requirements under the Updates Policy.