neotux
(Neo )
June 25, 2023, 11:52am
1
sudo dnf offline-upgrade download
Unknown argument "offline-upgrade" for command "dnf5". Add "--help" for more information about the arguments.
I have used this option mostly when I haven’t been updating my Fedora box for some time and there are many packages to update.
Isn’t offline-upgrade
supported with dnf5
anymore?
1 Like
vekruse
(Villy Kruse)
June 25, 2023, 12:06pm
2
dnf5 is still in rapid development, so it might not have been implemented yet.
1 Like
neotux
(Neo )
June 25, 2023, 12:15pm
3
Thanks for the reply @vekruse !
I do really like this option and find it useful. So there might be a chance that it will be implemented later on? Let’s hope so!
jn64
(Justin Koh)
June 25, 2023, 12:19pm
4
Refer to pinned issues in the dnf5 repo tracking progress of the various commands.
1 Like
neotux
(Neo )
June 25, 2023, 12:25pm
5
Thank you so much for posting the link! That’s really helpful! I will keep an eye on its progress.
Edit: I see that there is already a discussion going on:
opened 09:50AM - 30 Jan 23 UTC
Priority: MEDIUM
In DNF there is a possibility to perform offline upgrade for limited transaction… s and command. I suggest to extend the functionality to allow for any transaction operation offline upgrade and provide the functionality in API of LIBDNF5.
Components requiring that kind of functionality
- DNF
- system-upgrade
- offline-upgrade
- offline-distrosync
- PackageKit
- LEAPP
- Convert2rhel
- Imagebuilder
The workflow should be split to multiple steps:
- [ ] Creation transaction, download packages and storing of transaction
- Store all required data to perform identical transaction after reboot
- DNF4 implementation is good but not perfect
- not storing package or group reasons
- Store group planned operation
- Store module planned operation
- [ ] reboot or running in container
Primary implement rebooting mechanism like DNF4 system-upgrade uses. LEAPP uses an alternative way of running stored transaction. It is superior to DNF approach for system upgrade, because it uses rpm from target system, but there are also some weak sides.
- [ ] loading of stored transaction and performing
We need to ensure that the transaction will be identical to approved in step 4 from multiple sides - RPM content, groups, modules, history DB and System-state
We can:
- store more information about transaction (reason, package checksum, ...)
- add check step that replayed transaction is identical - removed packages are not checked much in DNF4.
- alternatively we don't need to rerun libsolv transaction
- transaction itself is verified by RPM
- ensure that RPMs are still identical what we stored (checksums + length)
- optionally - system was not changed - rpm content - using RPM cookies
- requires a new way how to update history DB, system state, and filling RPM transaction
1 Like
From the merge request linked on that issue:
For example, the process for running an offline upgrade would look like:
$ sudo dnf5 upgrade --offline mypackage
Updating and loading repositories:
Repositories loaded.
...
Transaction stored to be performed offline. Run `dnf5 offline reboot` to reboot and run the transaction.
$ sudo dnf5 offline reboot
The system will now reboot to perform the offline transaction initiated by the following command:
dnf5 upgrade --offline mypackage
Is this ok [y/N]:
1 Like
Thanks, @johnandmegh . I’d been unable to locate any documentation on it. Perhaps I should have read the man
more thoroughly, but there’s a lot in there.
grumpey
(Joe)
November 2, 2024, 10:34am
9
You can also find documentation here,
https://dnf5.readthedocs.io/en/latest/