no Package header | Unable to lock the list directory

[kimariterikishi]

Describe the bug
The error only occurs in the graphical interface.
When the panel is updated with an application when the GUI is not open, the update is OK. (Picture 5)
It may also be related to using the blacklist option. Signed up today, with version 5.6.7.

Screenshots
If applicable, add screenshots to help explain your problem, you can just drag & drop them here.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'mintupdate open GUI'
2. Click on 'Refresh'
3. See error

Expected behavior
Opening the mintupdate in the GUI, there is an error.

Distribution:

• Linux Mint 20 (beta), Cinnamon

Software version:
5.6.7 and 5.6.8

Logs:
Where is mintupdate.log? I don't know.

Crash report:
/usr/lib/linuxmint/mintUpdate/mintUpdate.py:1137: DeprecationWarning: Gdk.threads_init is deprecated
Gdk.threads_init()
/usr/lib/linuxmint/mintUpdate/mintUpdate.py:1283: DeprecationWarning: Gtk.ImageMenuItem.set_image is deprecated
menuItem3.set_image(image)
/usr/lib/linuxmint/mintUpdate/mintUpdate.py:1515: DeprecationWarning: Gdk.threads_enter is deprecated
Gdk.threads_enter()
/usr/lib/linuxmint/mintUpdate/mintUpdate.py:670: DeprecationWarning: Gdk.threads_leave is deprecated
Gdk.threads_leave()

Additional context
Could not download all repository indexes

The repository may no longer be available or could not be contacted because of network problems. If available an older version of the failed index will be used. Otherwise the repository will be ignored. Check your network connection and ensure the repository address in the preferences is correct.

An error occurred

The following details are provided:

E: Invalid record in the preferences file, no Package header
E: Unable to lock the list directory

Locale:
HU (Hungarian)
EN (LANGUAGE=en mintupdate)

[kimariterikishi]

By the way, the problem arose on a Mint forum.
I was looking for a reason ...

Cause of the error:

My forum partner blacklisted the mintstick application in Update Manager, but also locked the minstick application (in parallel) in Synaptic Package Manager.

So far, everything is working fine.

The error occurs when I unlock the minstick app in Synaptic!

I searched, Synaptic stores the lock in the preferences file.

File path:

/var/lib/synaptic/preferences

Contents

• at the time of locking:

-- read

cat /var/lib/synaptic/preferences

-- output

Package: mintstick
Pin: version 1.4.4
Pin-Priority: 1001

• a line that looks empty remains after the lock is released

Examined with the diff application, the empty line already looks different:
(I created a new lock, and then unlocked. Therefore, the preferences file that I renamed earlier „mv” exists.)

diff preferences.ORIG preferences

... there is no difference here.

and highlighted 0a1,3 what would (I think) be important, which is not visible in the lock settings after the lock above:

0a1,3
> Package: mintstick
> Pin: version 1.4.4
> Pin-Priority: 1001

To fix the Update Manager error, rename the preferences file:

sudo mv /var/lib/synaptic/preferences /var/lib/synaptic/preferences.ORIG

I've figured out the cause of the error, maybe it might be worth making some fixes for this event as well. I know the user's thinking wasn't reasonable, but he still did what he did ...

The cause of the error is to unlock the application in Synaptic Package Manager.

---

I tried to find out where the Update Manager stores the blacklist setting. No results yet, search in progress:

sudo grep -insr "mintstick" /

... but that’s just curiosity on the part, it doesn’t belong closely to the bug report.

[xenopeek]

You've provided a lot of information with this observation but it's not reproducible with the provided steps (1. Go to 'mintupdate open GUI'; 2. Click on 'Refresh'; 3. See error) nor does blacklisting a package in mintupdate and/or (I tried both) locking the version of the same package in Synaptic, or after lifting the lock, make a difference to reproduce this.

It looks unrelated to blacklisting / locking the version and to be that your apt lists files have a problem following from network issues on your system. I suggest you try to run Fix MergeList problems from Software Sources > Maintenance to see if that will fix it. Otherwise in Software Sources switch your main and base mirrors to a server closer to you. For further help with troubleshooting this I suggest to first take more help from the support forums to narrow down on exact steps to reproduce it, also on other systems. If you can narrow down on steps to reproduce this on other systems please open a new issue.

To answer some questions you had:

• mintupdate stores blacklists in the user's dconf database (~/.config/dconf/user). You can query the blacklists stored in the dconf database with command: gsettings get com.linuxmint.updates blacklisted-packages or dconf read /com/linuxmint/updates/blacklisted-packages.
• The empty line in /var/lib/synaptic/preferences is indeed just a newline character stored at the end of the file. This isn't a problem. You can dump the contents of the file with xxd /var/lib/synaptic/preferences to see after you've removed locks it just has 0x0a (newline) character in it. Not a problem.
• mintupdate logs are stored in the /tmp/mintUpdate/ directory. Look in the newest file after you have an issue in mintupdate.

[Jeronimo17]

The same thing happened to me after restoring a copy of timeshift,
sudo mv /var/lib/synaptic/preferences /var/lib/synaptic/preferences.ORIG
thanks

[hamishmb]

NB: I also had this issue. The error in my case was due to /var/lib/synaptic/preferences having a single blank line inside. I have previously pinned an application, so I assume that at some point the config file was modified incorrectly.

Thanks for the above fixes - otherwise I wouldn't have found the cause of the problem.

[Lefuneste83]

Thank you for this post. I've been searching everywhere for the origin of this stupid empty message... Now I understand why mintupdate was complaining but it would be nice to change the code a little to take this into account.

[Hordeking]

This fixed it for me, too.

Can we loop in one of the devs to include a couple of lines to handle this? It seems like a silly bug to leave in and I'm guessing if several of us who have it that have reported it, there are a lot of users out there who either just live with it (like I was, I just ran apt from the terminal) or simply wipe and reinstall their os (or move to another distro).

Now that we know what is happening, can we figure out why it happens in the first place? Like what triggers this prefs file to become invalid.

[Lefuneste83]

Yeah imagine reinstalling the whole system for this... It really needs fixing...
In my case I believe it was due to some expired key for a Skype repo that was duplicated with the official one. But really hard to pin down precisely as it is a leftover from a previous operation. The preferences file causing problem because it is empty should be easy to process in code. I guess it is a matter of adding a control and cleanup operation to make things tidy.
This error is also quite misleading as this kind of error usually points you toward the repos listings. But I suspected it was this type of flag file being malformed or leftover. But you need to know the mintupdate precise cinematic to know what to check.

[Hordeking]

Oof I actually tried updating from 19.3 to 20.0 or 20.0 to 20.1 to try to clear the issue (I forget which). But yes, the error is quite misleading, and I sat there going through each and every one of my repos trying to figure out which one was causing the problem (or which combination).

It actually popped up this error when I was trying to use mintupdate to upgrade from 20.1 to 20.2. It really caused me a lot of uncertainty trying to figure out if it had actually upgraded things or if it just changed the lsb_release file or did an otherwise incomplete job upgrading it.

[hamishmb]

Yeah, it's really misleading. I had this problem for about a year before it annoyed me enough to really sit down and try to figure it out.

Perhaps it should be reported separately for synaptic, but I'm not sure.

[Hordeking]

See also #657 It's the same bug.

[hamishmb]

Should not be closed. Shall I try and provide a consistent way to reproduce?

Either way, it's clear what the issue is - a blank link in a preferences file. The code that fails should either automatically fix this, or it should be made more able to cope with that apparently quite common situation.

[Hordeking]

I agree that it should not be closed until the bug is handled in the code. If you would like to find a consistent way to reproduce that would be great. We might even consider trying to figure out how that prefs file gets into the invalid state in the first place.

I just wanted to make sure to include a cross ref to the same bug in another thread. The author closed it, but I suggested not closing it there, too.

[clefebvre]

Ok, I can reproduce this.

It's a bit odd because both apt and synaptic are able to refresh, yet mintupdate can't even though it delegates this operation to synaptic itself. It might have to do with the different configurations they're using, I'm looking into it.

[clefebvre]

It's a bug in synaptic itself, reproducible with:

sudo /usr/sbin/synaptic --hide-main-window --update-at-startup --non-interactive

[clefebvre]

Fixed by https://gitlab.com/linuxmint/pins/mint/synaptic/-/commit/7477fb52b03b95695110216fe61b30aa00524ae9

[clefebvre]

Suggested upstream at mvo5/synaptic#90.

[clefebvre]

Fixed in synaptic 0.84.6+linuxmint3.

[hamishmb]

Thanks for this. I will verify once I receive the update.

[clefebvre]

It's only pushed towards 20.3 for now. We'll backport it to 20.x next week.

[clefebvre]

You can get it from http://packages.linuxmint.com/pool/upstream/s/synaptic/synaptic_0.84.6+linuxmint3_amd64.deb if you want to test it.

[hamishmb]

Can confirm fixed in 20.3.