Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1389762
Summary: | systemd presets request - switcheroo-control.service | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Bastien Nocera <bnocera> | ||||
Component: | fedora-release | Assignee: | Dennis Gilmore <dennis> | ||||
Status: | CLOSED ERRATA | QA Contact: | Dennis Gilmore <dennis> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | CC: | awilliam, bnocera, dennis, gmarr, jdisnard, kevin, klember, mboddu, pbrobinson, robatino, sgallagh, zbyszek | ||||
Target Milestone: | --- | Keywords: | Reopened | ||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | RejectedBlocker AcceptedFreezeException | ||||||
Fixed In Version: | fedora-release-25-0.12 fedora-release-25-1 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2016-11-05 19:07:03 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 1277290 | ||||||
Attachments: |
|
Description
Bastien Nocera
2016-10-28 13:50:23 UTC
Proposed as a Blocker and Freeze Exception for 25-final by Fedora user hadess using the blocker tracking app because: Advertised functionality is not working as expected. References: http://news.softpedia.com/news/fedora-25-linux-to-offer-better-dual-gpu-integration-in-the-gnome-3-22-desktop-509680.shtml This meets all the requirements of auto-acceptance, so I'll take it and get a PR ready for fedora-release. I'm going to put this in the default preset for all Fedora Editions for now. If Server decides to disable it in their preset, we can modify that later. https://pagure.io/fedora-release/pull-request/59 (Rawhide) https://pagure.io/fedora-release/pull-request/60 (F25) FYI, you haven't given any reason to treat this as a blocker. When filing something as a potential blocker, please cite the blocker criterion that you think it is failing: https://fedoraproject.org/wiki/Fedora_25_Alpha_Release_Criteria https://fedoraproject.org/wiki/Fedora_25_Beta_Release_Criteria https://fedoraproject.org/wiki/Fedora_25_Final_Release_Criteria As of right now, I'm assuming that this new feature doesn't work, but dual-GPU systems aren't generally broken. If that's the case, I'm -1 blocker, +1 FE. Those aren't linked from the form I filled in. FWIW, it's worse than a regression when a new feature doesn't work as (quite widely) advertised. (In reply to Bastien Nocera from comment #5) > Those aren't linked from the form I filled in. FWIW, it's worse than a > regression when a new feature doesn't work as (quite widely) advertised. If you used https://qa.fedoraproject.org/blockerbugs/propose_bug (which the comment indicates) those pages are linked. That being said, as long as this hasn't *broken* existing functionality, it's not a blocker. I'm still fine with +1 Freeze Exception. If you really feel that getting this working needs to be a blocker, contact FESCo and ask for them to make a ruling. They're the only group with privilege to assert blocker status without a previously-written criterion. At this point, I'd say that it's likely just academic, since if all that was missing was the preset, then this is basically solved (just waiting for a merge so we can test it). We're not even in Freeze yet, so if this gets merged before next Tuesday, all should be well. Yeah, I wouldn't sweat the blocker bureaucracy at this point. We clearly have enough time to make the release here. Discussed during the 2016-10-31 blocker review meeting: [1] The decision to classify this bug as a RejectedBlocker and an AcceptedFreezeException was made as the bug does not fit any existing criteria; incomplete changes are not inherently release blocking. However, this will be classified as an AcceptedFreezeException. Note that FESCo can declare this bug a blocker if so chosen to. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2016-10-31/f25-blocker-review.2016-10-31-16.01.txt fedora-release-25-0.12 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-399b120d6e fedora-release-25-0.14 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-bdcaf5493c fedora-release-25-0.12 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-399b120d6e fedora-release-25-0.14 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-bdcaf5493c Just for the record, adding this service introduces a different bug: switcheroo-control exits 1 if there is "No switcheroo support available" (i.e. the system doesn't have hybrid graphics), which causes the service to fail. The relevant criterion has a get-out clause - "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present." - so it's not technically a blocker, but this is still dumb, we shouldn't have a service which we know full well will fail on many machines. We should tweak either switcheroo-control or the service somehow not to fail in this case. I will file a separate bug. <kwizart> adamw, switcheroo-control.service isn't automatically loaded, (despite having the workstation 25-0 <kwizart> 25-0.14 rpm <adamw> kwizart: mmf, i suppose it may be missing a scriptlet to handle updates <adamw> try 'systemctl preset switcheroo-control.service' or similar (In reply to Adam Williamson from comment #15) > <kwizart> adamw, switcheroo-control.service isn't automatically loaded, > (despite having the workstation 25-0 > <kwizart> 25-0.14 rpm > <adamw> kwizart: mmf, i suppose it may be missing a scriptlet to handle > updates > <adamw> try 'systemctl preset switcheroo-control.service' or similar That's not its job though. It does run "preset" on install. fedora-release is supposed to update the preset services, no? (I mean, how would the switcheroo-control package know that its preset changed, it didn't install it) (In reply to Bastien Nocera from comment #16) > (In reply to Adam Williamson from comment #15) > > <kwizart> adamw, switcheroo-control.service isn't automatically loaded, > > (despite having the workstation 25-0 > > <kwizart> 25-0.14 rpm > > <adamw> kwizart: mmf, i suppose it may be missing a scriptlet to handle > > updates > > <adamw> try 'systemctl preset switcheroo-control.service' or similar > > That's not its job though. It does run "preset" on install. fedora-release > is supposed to update the preset services, no? (I mean, how would the > switcheroo-control package know that its preset changed, it didn't install > it) We can't run the preset on update because that command resets user-specified operations. So if a user had previously run `systemctl disable switcheroo-control.service` manually, running `systemctl preset` results in it being re-enabled. This would be unexpected by an end-user. I don't think it's possible to detect whether such a manual change has been made, either. So the best we can do is ensure that new installations have the preset properly loaded and tell people who are upgrading from a pre-release to either manually run `systemctl preset`, `systemctl preset switcheroo-control.service` or `systemctl enable switcheroo-control.service` and then run `systemctl start switcheroo-control.service` or reboot. (In reply to Bastien Nocera from comment #16) > (In reply to Adam Williamson from comment #15) > > <kwizart> adamw, switcheroo-control.service isn't automatically loaded, > > (despite having the workstation 25-0 > > <kwizart> 25-0.14 rpm > > <adamw> kwizart: mmf, i suppose it may be missing a scriptlet to handle > > updates > > <adamw> try 'systemctl preset switcheroo-control.service' or similar > > That's not its job though. It does run "preset" on install. fedora-release > is supposed to update the preset services, no? (I mean, how would the > switcheroo-control package know that its preset changed, it didn't install > it) we do not change services post system install so we do not undo user changes, in this case it may be worth getting a exception from FESCo to enable reseting the preset for switcheroo-control.service it would mean that users who disable it will get it re-enabled on updates and can not realistically disable it if there is problems outside forcing it to be removed Meh, since it's only been there for like a week or two, probably not worth it, we can just mention it on a mailing list or something as sgallagh said. Created attachment 1217085 [details]
patch to add trigger script to re-preset on upgrades
When upgrading from old fedora-release:
$ systemctl list-unit-files switcheroo-control.service
UNIT FILE STATE
switcheroo-control.service disabled
$ sudo dnf upgrade ./switcheroo-control-1.0-2.fc26.x86_64.rpm ./fedora-release-26-0.4.noarch.rpm
...
$ systemctl list-unit-files switcheroo-control.service
UNIT FILE STATE
switcheroo-control.service enabled
Check that state is preserved on subsequent upgrades:
$ sudo systemctl disable switcheroo-control.service
Removed /etc/systemd/system/graphical.target.wants/switcheroo-control.service.
$ systemctl list-unit-files switcheroo-control.service
UNIT FILE STATE
switcheroo-control.service disabled
$ sudo dnf reinstall ./switcheroo-control-1.0-2.fc26.x86_64.rpm
...
$ systemctl list-unit-files switcheroo-control.service
UNIT FILE STATE
switcheroo-control.service disabled
This version is for rawhide, for F25 fedora_release_min_version should be 25-0.14.
generic-release-25-1 fedora-release-25-1 fedora-repos-25-1 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-7b70ad9b8e (In reply to Zbigniew Jędrzejewski-Szmek from comment #20) > Created attachment 1217085 [details] > patch to add trigger script to re-preset on upgrades > > When upgrading from old fedora-release: > > $ systemctl list-unit-files switcheroo-control.service > UNIT FILE STATE > switcheroo-control.service disabled > > $ sudo dnf upgrade ./switcheroo-control-1.0-2.fc26.x86_64.rpm > ./fedora-release-26-0.4.noarch.rpm > ... > > $ systemctl list-unit-files switcheroo-control.service > UNIT FILE STATE > switcheroo-control.service enabled > > Check that state is preserved on subsequent upgrades: > > $ sudo systemctl disable switcheroo-control.service > Removed > /etc/systemd/system/graphical.target.wants/switcheroo-control.service. > > $ systemctl list-unit-files switcheroo-control.service > UNIT FILE STATE > switcheroo-control.service disabled > > $ sudo dnf reinstall ./switcheroo-control-1.0-2.fc26.x86_64.rpm > ... > > $ systemctl list-unit-files switcheroo-control.service > UNIT FILE STATE > switcheroo-control.service disabled > > This version is for rawhide, for F25 fedora_release_min_version should be > 25-0.14. This really isn't necessary, it turns out. The only people at risk for this are those who installed the switcheroo-control package before fedora-release was updated (which basically means people who updated a prerelease of Fedora 25 in the last week). That's a small enough sample set of people who *did* click through the prerelease timbuktu warning that I don't think there's a desperate need to account for it. Anyone upgrading from Fedora 24 or earlier will install the package for the first time during the upgrade and its %systemd_post macro will cause the preset to be applied. fedora-release-25-0.12 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report. I think we need 0.14, right? fedora-release-25-1, fedora-repos-25-1, generic-release-25-1 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-7b70ad9b8e fedora-release-25-1, fedora-repos-25-1, generic-release-25-1 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report. fedora-release-25-0.12 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report. |