rpm-software-management/dnf-plugins-extras

repository for DNF community plugins

dnf-plugins-extras's Issues

[WSL] System has not been booted with systemd as init system (PID 1). Can't operate.

(was rpm-software-management/dnf-plugin-system-upgrade#60)

I installed fedora 35 as a WSL distribution following this guide: https://dev.to/bowmanjd/install-fedora-on-windows-subsystem-for-linux-wsl-4b26

Then, I tried to follow these instructions to upgrade to 36: https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/

Here is the error I encountered:

$ sudo dnf system-upgrade download --releasever=36
$ sudo dnf system-upgrade reboot
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

I found the system-upgrade upgrade command, ran it, and that seemed to work. Is this expected behavior?

upgrade snapshot

Currently the system-upgrade plugin downloads all packages and the waits for a reboot to install them.

With thousands of packages and each needing the install, verify and clean cycles, this can take a while, making the machine unavailable while it's doing that.

While I have done "in place" (i.e. {urpmi|apt-get|yum|dnf|etc.} upgrade while the system runs) for decades, I won't debate the reasoning for wanting to do the upgrades in a minimal, quiescent system, achieved through a reboot the way the system-upgrade plugin does.

I want to suggest an alternative to attaining that quiescent state however. On systems where the filesystem(s) are build on LVM, or where filesystems supporting bootable, writable snapshots (forking), the upgrade could be done in a snapshot, which is then configured to boot when done and a system reboot is done then. Since the full upgrade was done in the snapshot, the reboot is only as long as it takes to reboot the system.

Once rebooted on the snapshot, the user can decide to archive the origin, delete it, etc.

This would not be unlike what I actually currently do before I do an upgrade which is to take an LVM snapshot of my /, /usr, /var, and /opt filesystems. In such a case where I am unhappy with the upgraded system, I can easily fall back to my pre-upgrade state by reconfiguring my system to boot from the snapshots (i.e. point grub at the / snapshot and edit the /etc/fstab in the / snapshot to mount the /usr, /var, and /opt snapshots) and rebooting again.

The system-upgrade plugin could actually formalize this being able to fall-back to the previous system by doing all of the above, and adding an entry to the grub menu for the pre-upgraded system.

[rfe] put each plugin in a separate sub package

Maybe it would be an idea to make a main dnf-plugins-extras an then put each plugin in a sub packages, to reduse the number of dependecies dragged in if I only what to install a single plugin and dont care about the rest.
Not a problem now when there is only one plugins, but in the future the where can be very specialized plugins with more complex dependecies.
there is no way to diasable a plugin permernant like there is with yum plugins, so it is not a good idea to install a big blob of comunity plugins, if you only uses one

Open Build Service repo management plugin (equivalent to copr plugin)

Description of problem:
DNF doesn't include an equivalent of the copr command to manage Open Build Service repositories (either on private OBS instances or on build.opensuse.org). It's rather irritating to manually add repositories, and having them managed through a plugin makes it easier to work with.

Version-Release number of selected component (if applicable):
dnf-plugins-core-0.1.10-1.fc22
dnf-plugins-extras-0.0.9-1.fc22

Extra notes:
I don't mind if this is an extras plugin instead of a core one, but it would be pretty nice if it was easier to list/add/remove OBS repos from a manageability perspective. Obviously, since OBS serves a number of RPM-based distros (Fedora, RHEL, CentOS, OpenSUSE, SLE, and Mageia), it would make sense for this plugin to be somewhat configurable to be able to support whatever naming/versioning scheme is used by these distributions.

via @Conan-Kudo from https://bugzilla.redhat.com/show_bug.cgi?id=1251959

poor rpmconf plugin documentation

In rpmconf plugin documentation IMO should be better described things as .rpmnew/.rpmsave or original config file deletion and how merge function works.
Also, doc says: "For list of valid frontends see rpmconf(8)." - but on rpmconf man page is no list of them.

Package does not meet expectations

The way that this is currently packaged in fedora, there are only man pages included in the package

$ rpm -ql dnf-plugins-extras
/usr/share/man/man8/dnf.plugin.debug.8.gz
/usr/share/man/man8/dnf.plugin.kickstart.8.gz
/usr/share/man/man8/dnf.plugin.leaves.8.gz
/usr/share/man/man8/dnf.plugin.local.8.gz
/usr/share/man/man8/dnf.plugin.migrate.8.gz
/usr/share/man/man8/dnf.plugin.repoclosure.8.gz
/usr/share/man/man8/dnf.plugin.repograph.8.gz
/usr/share/man/man8/dnf.plugin.repomanage.8.gz
/usr/share/man/man8/dnf.plugin.rpmconf.8.gz
/usr/share/man/man8/dnf.plugin.show-leaves.8.gz
/usr/share/man/man8/dnf.plugin.snapper.8.gz
/usr/share/man/man8/dnf.plugin.tracer.8.gz
/usr/share/man/man8/dnf.plugin.versionlock.8.gz

Nor does it have any dependencies on the actual packages....

I suspect that all of these have been broken into their own packages as that what seems to be revealed by my quick package search for dnf plugins - but that can be quite confusing too because there are both python and python3 versions for each. From a user perspective it's getting increasingly confusing...

Why not either remove the dnf-plugins-extras package, or better yet, make it into a meta package that installs the valid set of plugins as dependencies? (the set that it currently has mans for)

This way a user could install dnf-plugins-extras again and have all of them at once.

Otherwise, I fail to see why the package is even left behind to confuse people.

Edit: additionally, the package description in the spec is a "lie":

Available Packages
Name        : dnf-plugins-extras
Arch        : noarch
Epoch       : 0
Version     : 0.0.12
Release     : 4.fc25
Size        : 29 k
Repo        : fedora
Summary     : Extras Plugins for DNF
URL         : https://github.com/rpm-software-management/dnf-plugins-extras
License     : GPLv2+
Description : Extras Plugins for DNF.

snapper: Set userdata to important=yes

With snapper you can set --userdata important=yes when creating a snapshot which will make automatic cleanups more conservative by merit of supposedly being fewer and being counted separately. By default:

NUMBER_LIMIT="50"
NUMBER_LIMIT_IMPORTANT="10"

meaning that for snapshots marked for the "number" cleanup algorithm, it will keep the last 50 normal snapshots and the last 10 important snapshots. So even if the 10th oldest important snapshot is older than the 50th oldest snapshot, it gets preserved.

On openSUSE, zypper transactions are marked important, but snapper-boot.timer snapshots and YaST commands (which create pre-post snapshots) are not. It would seem prudent to mimic them in this, and mark DNF snapshots important. Even if we don't have YaST, we do have snapper-boot.timer and we do have snapper create --command which can wrap any command in a pre-post snapshot. It would be useful for DNF upgrades to be preserved more conservatively than those uses.

I'm not clear on what happens to "important" snapshots that are older than NUMBER_LIMIT_IMPORTANT but younger than NUMBER_LIMIT; do they get deleted before unimportant snapshots or do they get demoted to unimportant and kept until that limit is reached? Either way the idea seems to be that important snapshots are much rarer, and so take longer to reach the limits. That's understandable on openSUSE which wraps every YaST command in a pre-post snapshot, but it's less likely to be the case on a Fedora system unless you use snapper create --cleanup-algorithm number --command {cmd} liberally. But only by marking DNF snapshots important do we enable this use case, so it could be worth it. You can also adjust NUMBER_LIMIT_IMPORTANT if you find that only keeping 10 as opposed to 50 DNF snapshots isn't enough for you. The main point is that they're kept up to that limit regardless of how many other "number" snapshots you create for other purposes.

tracer: RPM packages for Fedora 21

Hello,
I want to ask you, if it would be possible to continue building rpm packages for Fedora 21.

One thing is that latest version of package dnf-plugins-extras-tracer in the repository is basically broken. It throws traceback every time. In the next commit, you fixed it by yourself, @ignatenkobrain and for F22 it works, but there are missing builds for F21.

Moreover, Tracer is my thesis and I will probably hand it over to my opponent in a few weeks and it would be nice if he gets the latest version. Ofc I don't know what version of Fedora he will use, but F21 is current stable, so I guess that will be it.

Thank you,
FrostyX

produce equivalent to yum.log (log of package installs, updates, and removes)

yum produced a nice neat log file which simply listed the dates and times for each package added, updated, and removed. This is extremely helpful for many purposes, such as:

1. tracking down which update caused a problem (useful in case it's necessary to revert to the older version, as well as for quality of bug reports to upstream)
2. tracking down how packages added/removed correlate with e.g. system performance or other issues
3. undoing a transaction (e.g. knowing all packages and dependencies which were installed if it's decided you don't want the software after all, or vis versa (think remove-with-leaves))
4. after-the-fact documentation of what software was manually added to an installation, which may need to be reproduced when migrating to another machine

An example of each type of entry in yum.log:

Apr 06 03:19:09 Updated: yum-3.2.29-81.el6.centos.noarch
May 25 20:10:54 Erased: postfix
Jul 12 05:59:27 Installed: kernel-2.6.32-696.3.2.el6.x86_64

Could this please be added to dnf?

Also, sorry if I've filed this in the wrong place -- it seems most of the dnf components don't allow reporting bugs / enhancement requests?

post-transaction actions

https://bugzilla.redhat.com/show_bug.cgi?id=1220182

We're just looking for the ability to configure arbitrary commands to run after certain packages are acted on.

For yum this was implemented in yum-plugin-post-transaction-actions ... if this were re-implemented for dnf, I think everyone would be happy, but I doubt anyone needs it to be implemented in exactly the same way (particularly because it doesn't seem to be very well documented), so long as it can accomplish the same thing.

Here's the description of yum-plugin-post-transaction-actions:
Yum plugin to run arbitrary commands when certain pkgs are acted on
This plugin allows the user to run arbitrary actions immediately following a transaction when specified packages are changed.

My understanding is that it creates a directory at /etc/yum/post-actions ... in that directory, a user could place "action" files for each package the user wishes to have post transaction actions apply to (e.g., the user could create a file named kernel.action if they want to run a command after the kernel is updated (actually, I don't think it matters what the file name is, as long as it ends in ".action", since the package name must be specified inside the file)) ... inside the file the user would enter the package name, an action (e.g. install or update), and the path to a script to run, like follows ...
kernel:update:/path-to/script-to-run.sh

In this case, the script will run any time the kernel package is updated.

You can also pass variables such as the package version to the script, like follows ...
kernel:update:/path-to/script-to-run.sh $ver $rel $arch

[RFE] Progress information for tracer runs

The tracer plugin can take a very long time to perform its scans, especially when a large update transaction has just completed. Today I upgraded some 400+ packages in the first dnf run on that system in nearly a month, and dnf took more than ten minutes to complete its post-transaction housekeeping. The majority of that time, as always after big jobs, was the tracker scan.

During that entire time, absolutely nothing is output on the terminal by dnf. A user could be forgiven if they assumed the process was hung or stuck in a busy loop.

Two things would be great to have:

1. At least a "Starting tracker scans (this may take a while)..."-style message displayed when the plugin begins executing. Perhaps even a line of output when each plugin starts executing.¹

2. To whatever extent is reasonably possible, some sort of visibility into the scan progress for the tracker plugin, specifically. (As it's by far the biggest contributor to post-transaction delays, especially for larger transactions.)

   Whether that means a simple horizontal progress bar, a scrolling list of items being scanned as it works through them², or some other display... heck, even just an ASCII spinner would be something, and it would at least provide reassurance that the dnf process is still working and not completely hung.

Notes

1. If they're run serially, then absolutely: every plugin, even if most finish in mere milliseconds. If the plugins run in parallel, then maybe it's better if only the slower plugins output a message. That way they don't all talk over each other.

2. Displaying progress as a transaction list, in the manner of the package actions themselves, could work nicely if tracker's scans are done on a package-by-package basis.

   OTOH, if its scans were done, say, by walking the system's process table, then reporting progress in list form probably won't fly. I imagine there are plenty of users who would consider it imprudent of dnf to suddenly start listing out of the entire process table. To say that's not an expected consequence of updating software would be an understatement.

dnf upgrade to Fedora 35 using --downloaddir just wiped out my entire home dir !

So... went to do an upgrade to Fedora 35 and found that I was lacking room for the downloads. I have /home set up on a separate drive, so I did the following:

dnf system-upgrade download --downloaddir=/home --releasever=35

The upgrade went well, except when I rebooted into F35 I couldn't log into my home directory. So I rebooted and logged into a console session. When I did, I got an error message stating that /home/ was missing. ls /home showed me that all my home directories are missing.

I'm guessing that dnf downloaded all the packages for the upgrade to /home and then did a rm -rf * on them, taking out my home directories in the process.

Just confirmed the dnf system-upgrade probably does a rm-rf on the "download" dir.

From dnf-plugins-extras/plugins/system_upgrade.py:

=======================================================================
def clear_dir(path):
if not os.path.isdir(path):
return

for entry in os.listdir(path):
    fullpath = os.path.join(path, entry)
    try:
        if os.path.isdir(fullpath):
            dnf.util.rm_rf(fullpath)
        else:
            os.unlink(fullpath)
    except OSError:
        pass

========================================================================

I'm guessing that dnf.util.rm_rf does a #rm -rf ! Which explains where my home directories went !

I am beyond angry that this happened.

This is crazy coding ? If the developer wanted to delete only dnf created files, s/he could have easily grouped them by creating a sub directory within the --downloaddir, downloaded the files there and then did an rm -rf from within that directory.

I just lost a couple months worth of work.

dnf-tracer should be executed even if dnf is run when there is "Nothing to do."

Currently, when "dnf upgrade" is run on a system on which packages have previously been upgraded since the last reboot and there are no new upgrades to install the output of tracer is not displayed. This is particularly suboptimal on systems where dnf-automatic is being run.

Test suite leaves /tmp/system_upgrade_test_installroot-* behind

Each run of the test suite, for example as part of fedpkg local, leaves around two dozen mostly empty /tmp/system_upgrade_test_installroot-* directories behind.

This should probably be fixed by amending /tmp/system_upgrade_test_installroot-*'s CommandTestCaseBase.tearDown() to do shutil.rmtree(self.installroot) as well, but in earlier versions self.cli.base.conf.installroot was set to /, so an appropriate amount of caution should be applied. (Maybe set self.installroot to the result of a tempfile.TemporaryDirectory() call, self.cli.base.conf.installroot to self.installroot.name, and call self.installroot.cleanup() in CommandTestCaseBase.tearDown().)

python-dnf-plugins-extras-local does not create /var/lib/dnf/plugins/local directory

Hi,

The local plugin does not create it's repository directory on my Fedora 22 computer.
Dnf-commands output the message "local: '/var/lib/dnf/plugins/local' is not a directory".

Claes

Tests broken with tracebacks for repoclosure, repograph, and repomanage plugins

When building dnf-plugins-extras in Mageia Cauldron, the tests bombed out on the repoclosure, repograph, and repomanage plugins.

Based on the error, it appears to be caused by libdnf. The version of libdnf in Mageia Cauldron is libdnf-0.7.0-0.2.git20161125.2d8ba15.mga6, which corresponds to rpm-software-management/libdnf@2d8ba15.

It last worked with rpm-software-management/libdnf@248dc84 + rpm-software-management/libdnf#213 on top in my dnf2-mga COPR.

The full build log is available for further analysis.

System-upgrade to rawhide tries to fetch nonexistent repo

An upgrade from F29 to rawhide fails because it tries to pull a repo that doesn't exist:
upgrade.txt
Pulling the metalink manually reveals that while the upgrade looks for fedora-modular-rawhide it likely should be looking for rawhide-modular instead.

fedora 29 dnf system-upgrade

Traceback (most recent call last):
File "/usr/bin/dnf", line 58, in
main.user_main(sys.argv[1:], exit_code=True)
File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 179, in user_main
errcode = main(args)
File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 64, in main
return _main(base, args, cli_class, option_parser_class)
File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 99, in _main
return cli_run(cli, base)
File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 115, in cli_run
cli.run()
File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 1055, in run
return self.command.run()
File "/usr/lib/python3.7/site-packages/dnf-plugins/system_upgrade.py", line 322, in run
self._call_sub("run")
File "/usr/lib/python3.7/site-packages/dnf-plugins/system_upgrade.py", line 330, in _call_sub
subfunc()
File "/usr/lib/python3.7/site-packages/dnf-plugins/system_upgrade.py", line 465, in run_download
state.destdir = self.base.conf.destdir
File "/usr/lib/python3.7/site-packages/dnf-plugins/system_upgrade.py", line 135, in exit
self.write()
File "/usr/lib/python3.7/site-packages/dnf-plugins/system_upgrade.py", line 123, in write
json.dump(self._data, outf)
File "/usr/lib64/python3.7/json/init.py", line 179, in dump
for chunk in iterable:
File "/usr/lib64/python3.7/json/encoder.py", line 431, in _iterencode
yield from _iterencode_dict(o, _current_indent_level)
File "/usr/lib64/python3.7/json/encoder.py", line 405, in _iterencode_dict
yield from chunks
File "/usr/lib64/python3.7/json/encoder.py", line 438, in _iterencode
o = _default(o)
File "/usr/lib64/python3.7/json/encoder.py", line 179, in default
raise TypeError(f'Object of type {o.class.name} '
TypeError: Object of type VectorString is not JSON serializable

Add virtual Provides for offline-upgrade and offline-distrosync commands

PR here https://src.fedoraproject.org/fork/mattdm/rpms/dnf-plugins-extras/c/d24b2e09de9afd1021a4e31f9e777d7de936caa5 already applied in Fedora dist-git but mentioning it here so it doesn't get lost. Simply needs

Provides:       dnf-command(offline-upgrade)
Provides:       dnf-command(offline-distrosync)

added to the python3-dnf-plugin-system-upgrade subpackage.

feature: system-upgrade should remove old rescue kernel and initramfs

Problem: Fedora creates a rescue kernel and initramfs pair at initial installation, which are never updated.

This pair is created by /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh found in dracut-config-rescue-046-5.fc27.x86_64 which is part of the dracut package, and only happens if the rescue items are missing, which most typically is only at initial installation.

Solution: Delete the two rescue files before new major version kernel RPMs are installed. This will ensure replacement rescue kernel and initramfs are automatically generated.

snapper: fails to check if snapshot is required

On a non btrfs/ext4/LVM system, where snapshots aren't required during yum/dnf install, the snapper plugin is still being called to snapshot and it errors out as below..

Reproducer:
After installing the dnf snapper plugin

Run

dnf install
::
snapper: creating pre_snapshot failed: error.unknown_config: org.freedesktop.DBus.Error.Failed
::
dbus[23850]: arguments to dbus_connection_close() were incorrect, assertion "connection->generation == _dbus_current_generation" failed in file ../../dbus/dbus-connection.c line 2936.
This is normally a bug in some application using the D-Bus library.

python3-dnf-plugin-torproxy utilizzo???

python3-dnf-plugin-torproxy

But how to use this plugin correctly, because you don't have to specify much about its use!!!

Unable to system-upgrade

Versions

dnf

dnf-3.6.1-1.fc29.noarch

dnf plugins

`dnf-plugins-core-3.0.4-1.fc29.noarch

Running on

Fedora 29

Stacktrace

[dvitali@pixelc ~]$ sudo dnf system-upgrade download --refresh --releasever=rawhide
Before you continue ensure that your system is fully upgraded by running "dnf --refresh upgrade". Do you want to continue [y/N]: y
Traceback (most recent call last):
  File "/usr/bin/dnf", line 58, in <module>
    main.user_main(sys.argv[1:], exit_code=True)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 179, in user_main
    errcode = main(args)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 64, in main
    return _main(base, args, cli_class, option_parser_class)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 95, in _main
    cli.configure(list(map(ucd, args)), option_parser())
  File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 910, in configure
    self.command.configure()
  File "/usr/lib/python3.7/site-packages/dnf-plugins/system_upgrade.py", line 318, in configure
    self._call_sub("configure")
  File "/usr/lib/python3.7/site-packages/dnf-plugins/system_upgrade.py", line 330, in _call_sub
    subfunc()
  File "/usr/lib/python3.7/site-packages/dnf-plugins/system_upgrade.py", line 375, in configure_download
    self.base.conf.tsflags += ["test"]
TypeError: can only concatenate tuple (not "list") to tuple

This is the line that the stacktrace is pointing to

Can't upgrade from iso

As I understand, this plugin has replaced fedup, but there's an important functional still missing: fedup could upgrade from an ISO (both mounted and raw), whereas this plugin can't.

This functional allows one to upgrade the system when there's a scarce of free disk space. Currently such systems can not be upgraded, because the only way one could try it is by setting up a local repository, and then following this instruction. But then there's a hitch: this still requires one to download all packages to be locally (which would mean trying to copy packages from an ISO to the system partition), which one can't do (low disk space).

Move dnf-plugin-kickstart to pykickstart-3

Over the past two years, I've been working on a new version of pykickstart that cleans up a bunch of stuff and corrects some inherent flaws, as well as stops using certain deprecated python modules. The result is that there are some incompatibilities between v2 and v3. The projects that are most affected are the ones that really dig in and do a lot of custom stuff. It's been in the works a long time now and with anaconda starting to adapt, I feel like it's probably time to get rid of pykickstart-2 and use pykickstart-3 in Fedora.

There is a copr with the new version here: https://copr.fedorainfracloud.org/coprs/clumens/pykickstart-3/, and there's a document describing the changes here: https://github.com/rhinstaller/pykickstart/blob/master/docs/2to3.

I've looked at dnf-plugin-kickstart.py and it doesn't look like there's anything that actually needs to change, however it would be worth double checking. If there's any specific tests that can be run, I'd be happy to try them out and develop any patches required. Any thoughts on this?

--debug-solver does not work with system-upgrade download

When dnf system-upgrade download runs into conflicts, adding --debug-solver products an empty debugdata directory, so it's much harder to troubleshoot what the source of the problem is in the conflicting packages.