Now that we have system-upgrade instead of fedup, I don't think we need to split every
single upgrade test case between bios and uefi, as we have it right now:
https://fedoraproject.org/wiki/Template:Installation_test_matrix#Upgrade
The difference is that fedup created its own upgrade environment, a new boot menu, a
special initrd, contained a lot of systemd-related hacks. System-upgrade uses the standard
"offline upgrade" environment, so if offline upgrades ever worked for you, there
should be no difference. It doesn't create its own boot menu, it doesn't have a
separate initrd. It uses the standard way of booting your system - if your system boots,
the upgrade process should boot as well :) Likewise for adding a new boot entries during
the upgrade - if kernel updates work well for you, there should be no problem adding a new
kernel entry during upgrade, it's the same operation.
So, I'd like to save some unnecessary work and merge "x86_64 BIOS" and
"x86_64 UEFI" columns into "x86_64" column in that wiki matrix.
I'd also like to add two new test cases:
QA:Testcase_upgrade_dnf_previous_bios
QA:Testcase_upgrade_dnf_previous_uefi
This will only serve as a way to track that we have tested both environments, but it no
longer matters which product was used to perform the testing, and also we no longer need
to test all combinations. So, if you tested workstation on bios, you can fill out two test
cases immediately (_workstation and _bios). If you tested minimal on uefi, the same
applies.
I think it's valuable to keep bios vs uefi differentiation in the table at least in
the form of these two additional test cases, because it's still a system upgrade, and
there are some critical components which can break (like a new major release of efibootmgr
or grub). We should make sure we've tested both variants. But this way, it adds
virtually no extra work (compared to testing all combinations of it) and still gives us
almost the same test value.
Thoughts?
Kamil