-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bump supported Fedora release to 37 #859
Conversation
(I've taken the liberty to push a small commit to update the |
The Fedora 37 template is available now so technically this is already ready for review. |
I consistently get the following error when attempting to migrate from
To test the migration, I built an RPM from the branch, installed it in |
Fedora 37 template was released on 2023-03-03, and will be shipped by default by Qubes OS R4.1.2. For upgrades, we also need to ensure we're not changing the template for sd-fedora-dvm before the appropriate time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working through this! Unfortunately I'm still hitting an error during the migration. That said, it looks like the migration did complete -- the non-disposable sys-
templates are using fedora-37, and sd-fedora-dvm
uses the new template. 🎉
This Gist has the Salt error I'm getting: https://gist.github.com/eloquence/e5bca6fcd12ed6d7b7364c180bfe8bac
You may have an immediate hypothesis on what's causing this, but I'll leave one note at the line level on a part of the logic that's confusing to me.
dom0/sd-sys-vms.sls
Outdated
sd-{{ sys_vm }}-fedora-version-update: | ||
qvm.vm: | ||
- name: {{ sys_vm }} | ||
- prefs: | ||
- template: {{ sd_supported_fedora_template }} | ||
- require: | ||
- cmd: sd-{{ sys_vm }}-fedora-version-halt-wait | ||
{% if sd_supported_fedora_template.endswith("-dvm") %} | ||
{% if not dvm_needs_updating and sd_supported_fedora_template.endswith("-dvm") %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm confused by the not dvm_needs_updating
addition here -- what's the purpose of this additional check?
That said, what appears to be happening on my system is that this evaluates to true, but the create-
block itself is never defined, because the VM is already present and the {% if required_dispvm not in existing_vms %}
block evaluates to false.
I'm assuming you ran everything again without doing any manual Fedora 37 related cleaning operations, correct? If that's the case, your machine is in a state that the current patch would not get to by itself, which is also why it's not covered. That being said, I think we shouldn't assume that SDW is used in a completely isolated environment, power users may have done some manual template updating, so I'll take another look. Just to spell out the permutations of cases we would run into:
|
Yes, that's correct, I did not manually remove The only other state I can think of is with Qubes 4.1.2, which was released last week. A fresh install on 4.1.2 would be:
|
(Stepping through now to put some more eyes on this, will first try with no fedora-37 preinstall aka "regular update" scenario, then with fedora-37 template preinstalled aka "manual intervention or previous broken run") |
Shout out to @gonzalo-bulnes for bringing this up as a potential solution
I pushed some changes after a note from @gonzalo-bulnes came to mind again. I have not tested this, but I think this should cover all cases including the one @eloquence pointed out. This is all significantly more complex than https://github.com/freedomofpress/securedrop-workstation/pull/802/files in part due what I've introduced with #764 and #784. I consider the numbered approach now taken by this PR a workaround as removing and recreating an AppVM with the same contents wastes time and resources. However, this is a restriction of our deployment strategy which is IMO in dire need of fundamental restructuring. More notes on the direction I think would remove classes of pain-points is documented in https://github.com/freedomofpress/securedrop-engineering/pull/22 |
Given 4.1.2 is out and recommended, the fresh install case should actually be "SDW not installed, f37 exists, sd-fedora-dvm doesn't exist." For update cases we still have to allow for the 4.1.1 cases. |
On my system which has I'm going to try removing the
|
Yes, deleting Repeated runs after that also complete without errors. I think this is an edge case that resulted from a partially completed upgrade. I don't think you would encounter it on a Qubes 4.1.2 system with If we haven't tested that already, I think that would be useful to verify. Assuming that is the case, I think addressing this issue would be mostly a matter of overall resilience. |
Thanks for the sleuthing - you're right, I thought initially you were encountering the issue after only having downloaded the f37 template (as opposed to having set up the dvm as well). This is fixable, thanks for flagging. |
(A little bit annoying to remove the jinja optimization that was in there, but for now it's fine. We'll want to revisit our overall strategy here, as was suggested earlier) |
I'm stepping through one last time for good measure on a brand new 4.1.2 install. If someone wants to review on an existing 4.1 workstation by following the original test plan, that would be great (since I'm the last one to push some code I shouldn't review). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without any fedora-37
yet installed, and with the caveat that this test plan wasn't written when I started the make clone && sdw-admin --apply
sequence :-):
- Check out this branch in your sd-dev vm and ensure you set the SDW environment variables.
Ensure SD VMs (lookin at you, sd-whonix) are all shut down (otherwise, duringIn dom0make test
, you could encounter tests that report that VMs aren't fully updated).make clone
thenmake dev
sdw-admin --apply
-
make dev
sdw-admin-apply
completes without error -
sd-fedora-37-dvm
exists and is based onfedora-37
-
sd-fedora-dvm
is removed -
make test
passes in dom0- ...modulo qrexec policy changes I've made because this is my lowercase-W workstation too... :-)
- ...with one meaningful exception:
-
EXPECTED_KERNEL_VERSION = "5.15.41-grsec-workstation" |
[user@dom0 securedrop-workstation]$ qvm-run --pass-io sd-app uname -r
5.15.89-grsec-workstation
@cfm I still have the 5.15.41 grsec kernel when I've only ever built from dev on the SDW laptop. I'm guessing you had this machine on staging or prod before, since we don't do nightly kernel builds - that would explain the test failure. Thank you for the review :) I will finish clean install QA then merge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't do a full re-run, but did do another make dev
with latest changes and all LGTM, so adding another +1 for good measure :)
Thanks both. Tested on fresh 4.1.2 install; fedora 37 template handled just fine, although the first time, the installation errored out because our own template (workstation-bullseye) was not successfully downloaded. It was successful on a second run. Will keep an eye out for that issue in QA, but I think we're OK to proceed here. |
Description of Changes
Fedora 37 will be shipped with Qubes OS R4.1.2. As soon as Qubes R4.1.2 has been released, this should probably be merged so that the next release doesn't download Fedora 36 unnecessarily.
Fixes #841
Testing
sd-fedora-37-dvm
is used in place ofsd-fedora-dvm
through the repo (except for the salt state removing the latter)make test
, you could encounter tests that report that VMs aren't fully updated). In dom0make clone
thenmake dev
make dev
completes without errorsd-fedora-37-dvm
exists and is based onfedora-37
sd-fedora-dvm
is removedmake test
passes in dom0Note that removing the f36 template/f36-dvm template is not part of the template update process.