Bug 1878530
| Summary: | systemd has problems parsing capabilities of new kernel (Failed to parse bus message: Invalid argument) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michael Riss <Michael.Riss> | ||||||
| Component: | systemd | Assignee: | systemd-maint | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 31 | CC: | filbranden, flepied, lnykryn, msekleta, phil, ssahani, s, systemd-maint, yuwatana, zbyszek, z | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | systemd-245.8-2.fc32 systemd-243.9-1.fc31 | Doc Type: | If docs needed, set a value | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2020-09-23 17:12:52 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Michael Riss
2020-09-13 20:21:46 UTC
The compile problem seems to be analog to https://bugs.archlinux.org/task/67208 - microhttpd changed its API. Systemd seems to have a workaround for it: https://github.com/systemd/systemd/commit/d17eabb1052e7c8c432331a7a782845e36164f01 I now managed to apply the patch to systemd to build against the new version of microhttpd and it also solved the original capability problem. Nice! I attach patch and changed spec file as I'm rusty again with the developer tools. Sorry. I will see that I push it there also, if I figure out the names of the tools again ... and if I still have a valid account on src.fedoraproject.org. Created attachment 1714767 [details]
new spec file
Created attachment 1714768 [details]
microhttpd build patch
The call to test for the error is wrong, there is no "bash" service - sorry, I was tired - try some other, e.g. systemctl show -p CapabilityBoundingSet httpd I tested my patched version of the systemd with a full automated install of our production system. I created an extra repo with the new systemd packages and added this repo in the kickstart configuration, so it got used right from the start and during the initial installation of the system. It went well, the problem with the error message of "systemctl show ..." went away, ansible works again and I didn't notice any regressions. I think that's about as good as I can test it on my end here. So I would like to hand it over to the experts on your side for further testing. I opened a pull request https://src.fedoraproject.org/rpms/systemd/pull-request/35 containing my patch. Please take a look at it and if I can do anything else or better, please tell me. I just checked the packages that got generated by the pull request, they also work which indicates that the CI has the right kernel installed for this build - good! Well, at least on the x86_64 architecture. I can't test the others: https://koji.fedoraproject.org/koji/taskinfo?taskID=51617092 Quite cool build system btw. Question to the maintainers: How is the situation? Did you already look at this problem/fix/patch? Do you see a chance that it gets accepted? Or is it too late in the life cycle of Fedora 31 to release an update of such a central component? I have some machines that need this fix and am wondering whether I should set up a private update repo for it. Of course, if you accept and push this update tomorrow or some time soon there is no need for that. Would be nice to hear from you, to know where I'm at; also when it's a: "Sorry, didn't have time to look at it yet." That also gives me already some orientation. Oops, I just realized something odd. On https://koji.fedoraproject.org/koji/taskinfo?taskID=51617092 the top line is Information for task build (f31, systemd-243.8-2.fc30.src.rpm) It claims it did the build from a srpm for Fedora 30. But I pushed the branch for Fedora 31 and all the resulting rpms are for Fedora 31. There seems something off with the build system. FEDORA-2020-0d29e88946 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-0d29e88946 FEDORA-2020-dc4f0fb907 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-dc4f0fb907 FEDORA-2020-0d29e88946 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-0d29e88946` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-0d29e88946 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-dc4f0fb907 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-dc4f0fb907` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-dc4f0fb907 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-0d29e88946 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-0d29e88946 FEDORA-2020-0d29e88946 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-0d29e88946` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-0d29e88946 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. Michael, I forgot to thank you for the patches. In the end I didn't use them because there were other patches to apply too, and it's easier to do this through upstream stable branches. In the future, please consider opening a PR or issue under https://github.com/systemd/systemd-stable/ when there's something that needs to be quickly backported. Also, thank you for testing the update. Hello Zbigniew, no problem, I'm just glad the fix finds its way into the main distribution now and I do not have to run an own updates repo indefinitely. ;) About reporting the problem upstream - in this case I had the feeling it was a Fedora 31 specific situation, because: A. it just needed to get recompiled with the new kernel includes B. one of the dependencies *on Fedora 31* got an upgrade with API-breaking changes. So it was not really a systemd bug, reporting it at the systemd - repo ... they might ask me what they are supposed to do about build problems on Fedora 31. Therefore I opened the report here. But sure, should I encounter a bug within systemd itself it's faster to go to the source and then flush the fix down to the distributions, true. This was a bit of a special case. This bug was fixed in three semi-independent ways: be recompiling systemd against newer kernel headers, by adding a fallback define upstream, and by changing how capability parsing is done so that the bug won't be repeated the next time the kernel adds a new capability. So while the first two approaches are OK to do within Fedora, the last was a big enough change that it merited going through the systemd-stable repo. So... it's not all bugs that should go through upstream, just some. Ok, now I see. I have to admit, I did not look into what happened upstream. Code changes to prevent the need to recompile sure go there. FEDORA-2020-0d29e88946 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2020-dc4f0fb907 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report. |