"Please switch to another Linux Mint mirror. Your APT cache is corrupted"

[Lakef]

Thanks! It should be gksudo mintupdate then because it is a graphical (GUI) application.

[Moem]

Lakef, that is exactly right.

[JohnFrumm]

OK, I figured out the problem today, and it is a noob problem...
So as everyone is aware Linux (and the rest of the world) is scrambling to fix Intel's stupid Meltdown blunder. So today I checked to see when my version of the kernel will be patched and.... it was not listed. So after doing some research I found out that Mint 18.3 uses kernel 4.4 while I am using kernel 4.10.

So why was I using this kernel series? Easy. Many months ago (last summer?) I was getting nag messages about updating the kernel. I HATE doing this, so I kept postponing it. Eventually I relented and updated the kernel. But I thought, "hey, since I hate doing this so much, I will just get the latest kernel available!" To me that was version 4.10.0-37ish. Well, everything seemed to work, so it has been this way for months.

Today when trying to update to kernel 4.4.0-108, the update manager freaked out when it finished, and again I got this "Your APT cache is corrupted." So I rebooted Linux, selected an old 4.4 kernel in GRUB, deleted the 4.10 kernels, rebooted, then upgraded to kernel 4.4.0-108. Now everything is happy.

Many other noobs will be updating their kernels soon, maybe this will help them if they get this bug. In the meantime it would be nice if there was kernel/OS version matrix in the update manager (and btw, why is it even possible to select a kernel from the wrong family???)

[Spearmint2]

Code: Select all

sudo apt-get update

[Schultz]

JohnFrumm wrote:
(and btw, why is it even possible to select a kernel from the wrong family???)

There's no such thing as a "wrong kernel family." Either it works or it doesn't (on any one given computer).

[Lakef]

My active kernel is 4.10.0-42. I had the same kernel in Sonya (18.2), before I updated to Sylvia (18.3). The APT cache corruption warning emerged after updating to Sylvia. People on this forum advised me to update to a newer kernel because I had issues with sound and screen (screen had low backlight). The update to 4.10.0-42 (from 4.10.0-38) was made because the update manager suggested me to do so because of security.

Each time after restarting my computer I have to perform gksudo mintupdate in a terminal window in order to correct for the error "Please switch to another Linux Mint mirror. Your APT cache is corrupted".

Note: In the Update Manager it is possible to select up to kernel 4.13.0-26, but I do not know if there is any risk of doing so. Is it? If I knew it was safe I would because I lack sound output for external speakers and headphones. Also, I have some screen tearing.

[Lakef]

I just updated to kernel to 4.13.0-26 as it was suggested by the Update Manager, though it was a level 4 update. I have restarted the computer. The necessity to open terminal and run gksudo mintupdate remains in order to clear the messsage "Please switch to another Linux Mint mirror. Your APT cache is corrupted".

[JohnFrumm]

I just updated to kernel to 4.13.0-26 as it was suggested by the Update Manager, though it was a level 4 update. I have restarted the computer. The necessity to open terminal and run gksudo mintupdate remains in order to clear the messsage "Please switch to another Linux Mint mirror. Your APT cache is corrupted".

Somewhere in the Linux Ubuntu/Mint world there must exist a single matrix/table that clearly shows the compatibilities between the kernels/ubuntu versions/ mint versions. I looked for it and could not find it anywhere. I still do not know what some kernel versions are for, but I will stick with the 4.4.0 kernel family for Mint 18. Last year when I got this error (with kernel 4.10) I was not even able to install new software in the software manager, gksudo or not. It basically broke my Linux install.

Now before making kernel updates I always backup my system partition. Yesterday when I ran into this problem it only took 5 minutes to restore the system partition from backup. If anyone else wants to implement this practice (backing up your computer partitions...) I highly recommend Clonezilla (free), it has saved my a$$ numerous times over the last 8 years, including two hard drive failures.

**EDIT**
I FOUND IT!!!!!!!!!!!!!!!
https://wiki.ubuntu.com/Kernel/LTSEnabl ... el_Support

[Lakef]

I use Back in Time (root) in order to backup files of operative system. It automatically backs up system files once a week. I think Back in Time uses rsync for backup. Would it function to recover a broken system by restoring backed-up system files?

I think Linux Mint Sylvia 18.3 is compatible with kernel 4.8, 4,10, 4.11 and 4.13. Although, there might be bugs that cause some unwanted beahaviour. Some bugs are corrected by newer kernels, while other bugs are introduced in newer kernels.

[Spearmint2]

I just use GParted to copy partitions to a backup area. I recently moved my OS to a new hard drive and all I had to do was copy the partition from old drive to new larger partition, download and install " boot-repair" and run it, then create (using dd) and set up a /swapfile again.

[Lakef]

I might have found what has caused the problem.

At one point when I wanted to run a command in the terminal, I got this error message: WARNING:root:could not open file '/etc/apt/sources.list.d/official-package-repositories.list'
So I changed the user privileges from 600 to 644 for the file "/etc/apt/sources.list.d/official-package-repositories.list".
I rebooted my computer, and this time there was no need for performing "gksudo mintupdate".

[Lakef]

Field repair
The solution with issuing the command sudo gksudo mintupdate is temporary. I got a permanent solution by assuring that the folder and its contents /etc/apt have sufficient privileges. I think the folders need read and execute privileges and the files read privileges for the group root and for others users. For folders I assure to have 755 (rwx r-x r-x) privileges and for files 644 (rw- r-- r--). Adding a new software source (PPA) might add a file with the wrong privileges, so one has to correct the privileges manually.

[JohnFrumm]

SOLVED
The solution with issuing the command sudo gksudo mintupdate is temporary. I got a permanent solution by assuring that the folder and its contents /etc/apt have sufficient privileges. I think the folders need read and execute privileges and the files read privileges for the group root and for others users. For folders I assure to have 755 (rwx r-x r-x) privileges and for files 644 (rw- r-- r--). Adding a new software source (PPA) might add a file with the wrong privileges, so one has to correct the privileges manually.

Yes, this problem somehow came back to haunt me on May 31. My solution was probably not the right one: I changed the owner of /etc/apt/sources.list.d/* from root to user. The permissions are set to 600 for the *.list files.

So changing this to 755 is the better solution? (the real question is, how does it get changed to begin with???)

[JerryF]

SOLVED
The solution with issuing the command sudo gksudo mintupdate is temporary. I got a permanent solution by assuring that the folder and its contents /etc/apt have sufficient privileges. I think the folders need read and execute privileges and the files read privileges for the group root and for others users. For folders I assure to have 755 (rwx r-x r-x) privileges and for files 644 (rw- r-- r--). Adding a new software source (PPA) might add a file with the wrong privileges, so one has to correct the privileges manually.

Could you edit your original post and place the SOLVED in the Subject: line. That way when members are browsing, they see that the issue has been solved.

Thanks.

[Moem]

Could you edit your original post and place the SOLVED in the Subject: line.

The problem here is that Lakef isn't the topic starter, so... no, they can't. That's a clear disadvantage of piggybacking on an existing subject (and a fine reason why it's formally against forum rules to do so).

I'll do it, though. It seems that the OP solved their problem as well.

[JerryF]

Could you edit your original post and place the SOLVED in the Subject: line.

The problem here is that Lakef isn't the topic starter, so... no, they can't. That's a clear disadvantage of piggybacking on an existing subject (and a fine reason why it's formally against forum rules to do so).

I'll do it, though. It seems that the OP solved their problem as well.

I didn't notice that, sorry.

[JohnFrumm]

Could you edit your original post and place the SOLVED in the Subject: line. That way when members are browsing, they see that the issue has been solved.

Thanks.

@JerryF
I did not mark this solved because as far as I am concerned, this issue is NOT SOLVED!

This BUG has popped up five (six?) different times on three different Linux installs, and I don't understand why. (Two different computers and a VM.) This is sure to return at some random time in the future, and since I will forget what I did to solve it I wrote a short script that "fixes" the problem. And that is not a solution, it is a jury-rigged patch at best.

And about 15 minutes before your post I asked a (skipped over) follow-up question.

[JerryF]

@JerryF
I did not mark this solved because as far as I am concerned, this issue is NOT SOLVED!

This BUG has popped up five (six?) different times on three different Linux installs, and I don't understand why. (Two different computers and a VM.) This is sure to return at some random time in the future, and since I will forget what I did to solve it I wrote a short script that "fixes" the problem. And that is not a solution, it is a jury-rigged patch at best.

And about 15 minutes before your post I asked a (skipped over) follow-up question.

Again, mea culpa. I didn't notice that Lakef wasn't the the original poster.

[Moem]

I did not mark this solved because as far as I am concerned, this issue is NOT SOLVED!

Sorry, I've removed the [SOLVED] marker. I was tripped up by your message where you said "I FOUND IT!!!!!!!!!!!!!!!"

[JohnFrumm]

I did not mark this solved because as far as I am concerned, this issue is NOT SOLVED!

Sorry, I've removed the [SOLVED] marker. I was tripped up by your message where you said "I FOUND IT!!!!!!!!!!!!!!!"

Yes, I did figure out how to temporarily solve it, but it keeps happening... and it just happened AGAIN, a few days ago after a kernel update.

Specifically the file:
/etc/apt/sources.list.d/official-package-repositories.list

is now owned by root with permissions 600, so when I refresh mintupdate an "APT cache corrupted" message pops up.

chown to user and it works again. This is not a permanant solution.