List of recent updates how to

How to obtain a list of recent updates?
This list is very useful when attached to bug.
In dnfdragora window a list of recent update is shown pressing Information -> History and choosing the right date and time. But I’m not able to copy the list and paste in a text file.
The hint in this post is not valid, at least for me. Today I updated more than 40 packages and these are the last rows of my /var/log/dnf.rpm.log

2019-03-29T17:39:18Z INFO --- logging initialized ---
2019-03-31T06:32:52Z INFO --- logging initialized ---
2019-03-31T14:38:47Z INFO --- logging initialized ---
2019-03-31T15:32:43Z INFO --- logging initialized ---
2019-03-31T16:25:06Z INFO --- logging initialized ---
2019-03-31T16:25:21Z INFO --- logging initialized ---
2019-03-31T16:25:45Z INFO --- logging initialized ---
2019-03-31T16:32:46Z INFO --- logging initialized ---
2019-03-31T17:32:50Z INFO --- logging initialized ---
2019-03-31T18:32:58Z INFO --- logging initialized ---

As you can see no packages listed.


Same as here
@Giorgio, uguale uguale… :wink:

1 Like

Also that can always be found in ‘/var/log/dnf.rpm.log’. And all dnf transactions going back to installation are in ‘/var/log/dnf.log’. There is a lot of debug stuff in those logs which makes it less likely that users will want to deal with them but the information is there. It is there right now for your previous transactions with dnf.

@Developers: Would it be wise to think about reducing the volume of debug output in those logs as all I see is a whole lot of completely irrelevant information repeated ad nauseam. This will inhibit users from using these logs.

Non farmi fare confronti. :unamused:
Avevo anche raccolto i vostri consigli in una guidina proprio carina.

Yesterday I updated several packages including glibc-6:2.29-1.x86_64.
I opened dnf.log with Kate but searching for “glibc-6:2.29-1.x86_64” don’t give any result.

The information is there but so is a lot of seemingly unnecessary debug stuff.

If you use something like Kate or Kwrite the file size is above the ordinary limit for these text editors so you have to select to “temporarily raise limit and reload file” first for all the information to be there. And the information that would be left out would be the most recent transactions.

So if you do that and find the right section for the recent transaction it will look like:

And it should be very clear that this is the dnf.log. What it contains looks exactly like the output you would get if you upgrade system in Konsole. Plus all the debug stuff I complain about. The debug stuff does make it hard for user to find their transaction. I have not yet tried using a search function in Kate or Kwrite myself but the should work if you raise the limit as described above.


Non avevo capito che funziona ancora. Quindi la guidina è ancora valida? Se è così il problema è risolto!

I tried only with Kate and of course raised limit but no way to “whois” package I just updated.
Instead Rugyada suggests a very good procedure.

The information was for all users. It is important for people to know that “I can’t find information about a previous transaction” with dnf is simply not true. Yes you can. (Unfortunately looking for it in the logs can be pain in the rear end but the information is there.)

There is no question that @rugyada’s suggestion would be easier.

FWIW: That command (rpm -qa --last) also will list all packages installed all the way back to installation of your system with dates installed.

Tried using LibreOffice too but in my system I’m still not able to find recent updates in dnf.log
May be I make a mistake, may be dnf.log isn’t the same in all systems.
If you need I can send my dnf.log and list of recent updates.

In fact I don’t know how to use ‘whois’ in Kate. I would use that in Konsole.

In Kate I would use >Edit>Find like this:

Note the up and down arrows to the right that allow you to go to previous or next match, ect.

The goal is not for me to do it for you (or any user) the goal if for you to be able to do it for yourself. Logs are logs, they are purposely designed to be the same for all systems. This could only be changed if someone changed the code in the dnf software.

Searching for information in logs is not something that is immediate, it sometimes takes a bit of time and patience to find what you want. If you haven’t done it before it requires a tiny amount of learning “How to find what I want”.

Post-edit: To put in perspective what it takes to find things in these logs on the computer I’m on at this moment the dnf.rpm.log is over 16,500 lines the dnf.log is over 97,500 lines. That is not unusual, many users will find their logs to be as big or bigger.

Of course but I’m not able to find updated package. May be I make a mistake this is why I suggest to send you my file.

I’m not convinced. This morning (4 april 2019) I opened OMLx 4, updated several packages and few seconds after I closed.
Here’s last rows of my dnf.log:

2019-04-03T18:11:14Z DEBUG Creazione dei file di cache per i metadati.
2019-04-03T18:11:14Z INFO Il timer per la cache dei metadati è disabilitato quando si è su una connessione a consumo.
2019-04-03T18:11:14Z DDEBUG Cleaning up.

As you can see not even a row on 2019-04-04.

Why do you keep talking about “last rows of my dnf.log”? That is not the right place to be looking. You have to go further back in the logs.

Using my own dnf.log as an example currently last line is 107,602. Now I want to scroll back past all lines that have DEBUG, DDEBUG, INFO, or WARNING. Which in this case takes me to line 105,601. That happens to be an update I did less than 5 hours ago. What??? 2001 lines to go back less than 5 hours? Yep, I’m afraid that this currently how this log works.

Now I do understand your frustration and hope that you and others see my frustration. How will we get users to use a log where you have to go back 2000 lines to find an update that user did less than 5 hours ago. Developers are you paying attention? (Here’s the question: Developers will all this debug output go away when repos are split for Lx 4.0? I’m hoping so.)

Also now you and other users are perhaps more aware of why I would use the ‘Find’ utility in Kate or Kwrite to find things in this dnf.log or the dnf.rpm.log. Scrolling takes more time a patience than most of us have.

1 Like


In my dnf.log there are several lines reading
followed by the list of packages installed in that given instance.
I think if you make a search like this, that may help.

At any rate, the simple command in console is the easiest way to get just all you wanted to know

therefore I don’t see the point of having to look into thousands of lines of logs.

1 Like

Of course I used “Find” but no way to find any of the updated packages.

My most recent “installing” is on 29 march 2019. Then this don’t works either.
This just to show that dnf.log don’t contain information on updated packages, at least in my system.
If I need a list of updates I will use konsole.

There are also lines
and, maybe the best
Transaction Summary

1 Like

Then you have a serious problem and need to figure out what has been done to corrupt your system.

I’ll say this one more time. Your dnf.log is supposed to contain every transaction by dnf going back to and including installation on you system. I’ve looked at dnf.log on quite a few hardware systems by now and I have never seen otherwise. I won’t say something is impossible without confirmation, so post your entire dnf.log. And I mean the entire log, every line. Post-edit: To post every line may require you to split the log in to 2 or more files. Or compress it with xz which can be done easily in Dolphin and xz files will upload here.

As per example the dnf.log on the machine I am on right now begins with entries dated Feb. 04, 2019 with the packages that Calamares initially installed. Here’s is what line 1 should look like (your date and time will obviously be different):

2019-02-04T14:36:42Z INFO --- logging initialized ---

Then line 5 is an incredibly long line because it is the exact line from Calamares installer to install entire system. Here’s first part of line 5:

2019-02-04T14:36:42Z DDEBUG Command: dnf install -y --refresh --nogpgcheck --forcearch=x86_64 --exclude=*.i686 --setopt=install_weak_deps=False --installroot /home/omv/iso_builder/BASE

Note the “/home/omv/iso_builder/BASE” that is the Calamares installer.

Then the log at current moment goes to line 107,748. If your log is not something like that something is really wrong. Let’s do some simple math here. Feb. 4 until today just happens to be exactly 2 months. So that is 107,748 lines after 2 months.

1 Like

By the way, you won’t find glibc-6:2.29-1. Most likely you will find glibc-2.29-1.

1 Like