(→Detailed Description: drop proof-of-concept language and promote the replacement as official..ish) |
(→Scope: add note about copr/package review status) |
||
Line 68: | Line 68: | ||
** Make DNF able to send progress output to Plymouth (basically done; see dnf [https://github.com/rpm-software-management/dnf/pull/281 #281] and [https://github.com/rpm-software-management/dnf/pull/313 #313]) | ** Make DNF able to send progress output to Plymouth (basically done; see dnf [https://github.com/rpm-software-management/dnf/pull/281 #281] and [https://github.com/rpm-software-management/dnf/pull/313 #313]) | ||
** Modify Offline System Updates spec as needed to support major system upgrades (in progress, see [http://lists.freedesktop.org/archives/systemd-devel/2015-July/033605.html this systemd-devel thread]) | ** Modify Offline System Updates spec as needed to support major system upgrades (in progress, see [http://lists.freedesktop.org/archives/systemd-devel/2015-July/033605.html this systemd-devel thread]) | ||
** Package [https://github.com/rpm-software-management/dnf-plugin-system-upgrade dnf-plugin-system-upgrade] | ** Package [https://github.com/rpm-software-management/dnf-plugin-system-upgrade dnf-plugin-system-upgrade] (rpms here: [https://copr.fedoraproject.org/coprs/wwoods/dnf-plugin-system-upgrade/ wwoods/dnf-plugin-system-upgrade], need review/import) | ||
** Write man pages and other documentation | ** Write man pages and other documentation | ||
** Obsolete and retire fedup | ** Write replacement for <code>/usr/bin/fedup</code> | ||
** Obsolete and retire fedup package | |||
* Other developers: | * Other developers: | ||
Line 76: | Line 77: | ||
*** See {{bz|1252500}} | *** See {{bz|1252500}} | ||
** In the unlikely event that some kind of offline system migration is necessary (like [[Features/UsrMove|UsrMove]]), it should be handled the same way as UsrMove - i.e. by a dracut script that runs the first time the new system boots after the upgrade. | ** In the unlikely event that some kind of offline system migration is necessary (like [[Features/UsrMove|UsrMove]]), it should be handled the same way as UsrMove - i.e. by a dracut script that runs the first time the new system boots after the upgrade. | ||
** Translations, etc. | |||
* Release engineering: | * Release engineering: |
Revision as of 18:28, 18 August 2015
DNF System Upgrades
Summary
fedup is being redesigned and integrated into DNF.
Owner
- Name: Will Woods (fedup author)
- Email: wwoods@redhat.com
- Name: Zbigniew Jędrzejewski-Szmek (systemd developer)
- Email: zbyszek@in.waw.pl
- Name: Radek Holy (DNF developer)
- Email: rholy@redhat.com
- Release notes owner:
Current status
- Targeted release: Fedora 23
- Last updated: 2015-08-18
- Tracker bug: #1250939
Detailed Description
While fedup worked well in many circumstances, there were a lot of problems resulting from using upgrade.img
. This has caused nasty, hard-to-debug blocker bugs for every release since it was introduced.
It turns out that upgrade.img
was relying on some undocumented, unsupported systemd behavior.
After F22 this was discussed
on the systemd-devel mailing list, and the conclusion
was that fedup's boot behavior is broken by design, and systemd can't (and won't) continue to support it.
systemd already supports a simpler, more reliable method for performing Offline System Updates; the systemd team suggests using that to perform system upgrades.
Most of the remaining problems with fedup were caused by the fact that it was separate from the system packaging tools, and therefore had slight (and confusing) differences from the normal package update mechanisms.
Therefore, we proposed that system upgrades should be handled by the system packaging tools.
For upgrades to F23, fedup is being replaced with dnf-plugin-system-upgrade, a DNF plugin that handles system upgrades using systemd's Offline System Updates.
Benefit to Fedora
The upgrade process will be much more reliable, and well-integrated with the system packaging tools.
Better integration with system packaging tools:
- Upgrades support
distro-sync
mode - Systems do not need to (re-)download update metadata after the upgrade
We no longer need to build upgrade.img
, which saves space in boot/install media.
Scope
- Proposal owners:
- Make DNF able to send progress output to Plymouth (basically done; see dnf #281 and #313)
- Modify Offline System Updates spec as needed to support major system upgrades (in progress, see this systemd-devel thread)
- Package dnf-plugin-system-upgrade (rpms here: wwoods/dnf-plugin-system-upgrade, need review/import)
- Write man pages and other documentation
- Write replacement for
/usr/bin/fedup
- Obsolete and retire fedup package
- Other developers:
- Fix any conflicts with
packagekit-offline-update.service
- See RHBZ #1252500
- In the unlikely event that some kind of offline system migration is necessary (like UsrMove), it should be handled the same way as UsrMove - i.e. by a dracut script that runs the first time the new system boots after the upgrade.
- Translations, etc.
- Fix any conflicts with
- Release engineering:
- Drop
upgrade.img
from image builds
- Drop
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
Existing systems can still use fedup to upgrade to F22, F21, and older.
If we backport the DNF changes (or provide them as plugins) we can even provide this as an alternate upgrade path from F21 (or earlier).
How To Test
NOTE: this will change as things evolve
- Install
dnf-plugin-system-upgrade
:dnf copr enable wwoods/dnf-plugin-system-upgrade
dnf install dnf-plugin-system-upgrade
systemctl mask packagekit-offline-update.service fwupd-offline-update.service
dnf system-upgrade download --releasever=23
- This should download lots of packages; it will probably also ask about importing the new GPG key.
dnf system-upgrade reboot
- Observe upgrade progress on plymouth boot splash
- System reboots at end of upgrade
systemctl unmask packagekit-offline-update.service fwupd-offline-update.service
- That's about it
(steps 2. and 7. are a temporary work-around, should be gone soon)
User Experience
System upgrades will look a lot more like offline updates (because they're just big offline updates).
The commands to upgrade the system will probably be more like:
sudo dnf system-upgrade download --releasever=23 sudo dnf system-upgrade reboot
Dependencies
None known.
Contingency Plan
- Contingency mechanism: There are a few options; none of them are good.
- Find someone to maintain fedup and keep using it for one more release, even though upstream systemd says not to
- Use a different upgrade method for one release
- Just don't support upgrades for one release
- Contingency deadline: Beta, at latest - any of the above contingency plans would take a lot of work.
- Blocks release? Yes. Upgrades are a release criteria.
- Blocks product? Not product-specific AFAIK.
Documentation
systemd-devel discussion:
- http://lists.freedesktop.org/archives/systemd-devel/2015-March/029030.html
- http://lists.freedesktop.org/archives/systemd-devel/2015-April/031013.html
fedora devel announcement:
Offline System Updates spec:
dnf system-upgrade
plugin
DNF upstream (links to API docs etc.)
Release Notes
The fedup
utility has been retired; system upgrades are now handled by dnf system-upgrade
.