qubes-issues
qubes-issues copied to clipboard
QubesOS
In-place upgrade from 4.1 to 4.2 shows error message that it could not find qrexec-legacy-convert
Qubes OS release
4.1
Brief summary
In-place upgrade from 4.1 to 4.2 shows error message that it could not find qrexec-legacy-convert
Steps to reproduce
follow the https://www.qubes-os.org/doc/upgrade/4.2/ steps and
sudo qubes-dist-upgrade --all-post-reboot
Expected behavior
qubes-dist-upgrade shows no error message
Actual behavior
qubes-dist-upgrade shows error message that it could not find qrexec-legacy-convert
partial diag. (since this came up on various qubes related chats in the last days)
qrexec-legacy-convert is supplied by pkg qubes-core-qrexec. but according to https://github.com/QubesOS/qubes-core-qrexec/ this is only present in the q4.2 version of the pkg.
whether it should be present in q4.1 version too, or the q4.2 version should already be installed at the time it is being called, or the call is simply to early ... i dont know.
@marmarek ?!
I just hit this.
The problem in my case is:
when running qubes-dist-upgrade --all-pre-reboot several qube templates failed to update for various reasons.
That aborted the whole execution of the dist-upgrade with exit code 20 without clear indication that phases 2 and 3 were not executed.
so post reboot you run the post-reboot phases while dom0 remains on 4.1 (you can see in /etc/os-release it still says 4.1.2 or such)
In my case I had to rerun dist-upgrade -r followed by -s to execute the actual phase 2 and 3 (phase3 failed because out of space - so definitely watch that too and free up space as needed)
I had to reboot after that to start all the new services.
and then I had to rerun qubes-dist-upgrade --all-post-reboot (phase 5 also silently failed in because qvm-features-request failed too and I had a bunch of permission issues). - because all templates did not need any updates the qvm-features-request was not rerun though so I am not sure if that's something I need to trigger somehow (may be not since the post install is run unconditionally as a separate step).
it was a bit confusing when phase 4 tells me templates are being updated to 4.1, but I guess that's just some stale message?
After all these steps I rebooted once more into what looks a fully functioning 4.2 system now. I still get permissions denied from sys-usb for qubes-input-tablet - I don't think I had tha tbefore (no touchscreen on this laptop)
What I think needs to be done:
- When phase 1 was running and not all templates updated - perhaps ask if the user wants to continue and ignore the failed ones? Non-functioning templates are a fact of life and I certainly have some from past experiments that I just never bothered to remove.
- A very visible message to the dist-upgrade combined pre-reboot option if not all phases executed
- Post-reboot phases should check os-release to ensure dom0 is already on 4.2 (or whatever the expected release is) before commencing with further changes and if not it should exit with the diagnostic that prior requires phases did not run. In fact os-release only tells you phase2 was successful, really need to check the booted kernel version to ensure the upgrade completed and installed successfully post reboot since as I now see phase3 can also fail.
@fepitre since you touch dist-upgrade already, can you add also relevant check to later phases if earlier completed? Specifically, steps 4 and 5 should check if dom0 is 4.2 already (by looking at /etc/os-release?)
Automated announcement from builder-github
The component dist-upgrade (including package qubes-dist-upgrade-4.1.6-1.fc32) has been pushed to the r4.1 testing repository for dom0.
To test this update, please install it with the following command:
sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing
Changes included in this update
