Mint 19 stable = forcing hands just like Microcrap

[rado84]

1. Doesn't allow to deselect intel microcode before clicking "apply updates". You check what's gonna be installed, go back and deselect intel microcode, then click apply. Check again and the stupid microcode is still included. In my book this is called "forcing hands"!
2. After installing the microcode it kept crying about a problem with these thumbnails which I never saw anyway.
3. After restart requested by the system in order to fix those thumbnails:


So: "thank you" for forcing my hands just like Microcrap do with their users - whether they want an update or not, they have it and are given no right to choose. This kind of forcing hands was the reason for me migrating to Android and it seems like now it's time to migrate again - from Mint to another less invasive distro!

Goodbye!

[karlchen]

Hi, rado84.

The intel-microcode package and the amd-microcode package hold fixes against the design flaws in Intel CPUs and AMD CPUs.
Ubuntu has decided that the kernel meta package linux-image-generic depends on both of them. So no chance of not installing them.
I assume that Ubuntu has done so because the kernel fixes against Spectre & Meltdown will only be fully effective, provided available Intel & AMD microcode patches can be loaded on system startup as applicable. Yet, as I am not a Canonical employee, this is only an assumption.
Anyway, on Ubuntu 14.04 (Mint 17.x), Ubuntu 16.04 (Mint 18.x) and Ubuntu 18.04 (Mint 19.x), intel-microcode and amd-microcode will be installed by the software management system.
Whether the kernel will really load any of the modules in intel-micrcocode or amd-microcode, this depends on your CPU.
In case there is a fix for your Intel CPU in the intel-microcode package, it will be loaded and applied. The same applies to AMD CPUs.
In case your CPU is old enough, there will be no patch for it in intel-microcode / amd-microcode. In this case the packages will simply be on your disk and make no difference at all.

Whether any such CPU patch is really applied on your system, I do not know; but it can be told from /var/log/syslog or with the help of "journalctl -b".

If you disagree with the dependencies of the Linux kernels, you are free to do so. You might try and start an argument with the Ubuntu development team on it.

Regards,
Karl

[gm10]

The intel-microcode package and the amd-microcode package hold fixes against the design flaws in Intel CPUs and AMD CPUs.
Ubuntu has decided that the kernel meta package linux-image-generic depends on both of them. So no chance of not installing them.

Sure there is. The kernel in the release version of Mint 19 doesn't depend on them. Besides, whatever happened here is not because of the microcode update, we both know it.

[karlchen]

Hi, gm10.

You caught me.
The dependencies on intel/amd-microcode are present in Ubuntu 14.04 (Mint 17.x) and Ubuntu 16.04 (Mint 18.x) - I know for sure, because kernel updates pulled them in on those systems, where I had not installed them beforehand on my own accord.
Yet, I will really have to check my Ubuntu 18.04 systems in order to verify linux-image-generic still depends on intel-microcode and on amd-microcode and will pull them in.
~~~
[Added 17:00]
Just verified that indeed on Ubuntu 18.04 the current kernel linux-image-generic 4.15.0-23(25) lists intel-microcode and amd64-microcode as dependencies. As you, gm10, have explained and documented the details in your posts below, there is no need to do so here.
Oh, yes, noted that the AMD microcode package is named amd64-microcode, not amd-microcode.
[/added]

Regards,
Karl

[Sir Charles]

Code: Select all

~ $ inxi -S
System:    Host: minty Kernel: 4.15.0-23-generic x86_64 bits: 64
           Desktop: Xfce 4.12.3 Distro: Linux Mint 19 Tara

Code: Select all

 ~$ apt depends linux-image-generic

linux-image-generic
  Depends: linux-image-4.15.0-23-generic
  Depends: linux-modules-extra-4.15.0-23-generic
  Depends: linux-firmware
  Depends: intel-microcode
  Depends: amd64-microcode
  Recommends: thermald

[gm10]

You caught me.

No, I think you misunderstood me actually. All I meant was that the specific kernel version in the Mint 19 release (4.15.0-20.21) does not depend on them. Once you update the kernel to the latest version you'll get the microcode as a dependency just as you described.

From the changelog:

Code: Select all

linux-meta (4.15.0.23.25) bionic; urgency=medium

  * Need to ensure microcode updates are available to all bare-metal installs
    of Ubuntu (LP: #1738259)
    - Make kernel image packages depend on cpu microcode updates

[karlchen]

Ciao, Marziano.

Mille grazie! Thank you very much for confirming that my memory still serves me right and that I will not have to correct my initial answer.

Alla prossima,
Karl

[karlchen]

Hi, gm10.

I see.
Actually, having installed the system from scratch and rebooted, kernel 4.15.0-21 survived here only as long as it took to accept and install all the available updates, including kernel 4.15.0-22. And by now, the kernel in use is of course, 4.15.0-23.

Cheers,
Karl

[kc1di]

I Think what has upset rado84 isn't that mirco code get pulled but that he himself has no control over the process. He if able needs to make his own Distro and then he can control a lot of that. Maybe Gentoo or Arch would be better fit. I for one have had no problem with the way Ubuntu and Mint do their updates. Excepting maybe when Ubuntu tries to force Amazon on us. But hey, one of things we can love about linux is there is plenty of choice so I wish rado84 in finding a distro that suits his needs and satisfies his requirements. I Will say Mint is nothing like MS, thankfully.

[Sir Charles]

Bitte schön, Karl!

Alla prossima!

[gm10]

I Think what has upset rado84 isn't that mirco code get pulled but that he himself has no control over the process.

Again, sure he does. Nobody forced him to update the kernel. You don't get to update your kernel without reading the changelog and then act surprised tbh.

[karlchen]

linux-image-generic has always had a list of dependent packages, i.e. packages which it will pull in, in case they are not present or not up-to-date.
Ubuntu has added 2 more packages to the dependency list for good reasons.
In the end being as safe from the Spectre and Meltdown vulnerabilities as possible should be appreciated by Ubuntu and Linux Mint users.
Starting a rant instead seems to be disproportionate to me.

[whm1974]

linux-image-generic has always had a list of dependent packages, i.e. packages which it will pull in, in case they are not present or not up-to-date.
Ubuntu has added 2 more packages to the dependency list for good reasons.
In the end being as safe from the Spectre and Meltdown vulnerabilities as possible should be appreciated by Ubuntu and Linux Mint users.
Starting a rant instead seems to be disproportionate to me.

I agree and I think that the OP is making a tempest in a teapot. Given the huge outcry of the Spectre and Meltdown vulnerabilities after they were discovered, I'm very surprise at his ranting.

[rado84]

it can be told from /var/log/syslog or with the help of "journalctl -b".

This would work if the OS were capable of loading a normal DE. As you can see from the screenshot above, that's impossible! Every reboot gets me to this screen. Before updating the system (installing the dumb microcode), all reboots went normally. But ever since the dumb microcode made its way on my computer, this is all I get everytime I start Mint 19.
I'm not gonna deal with Micronical, I'll just find a distro that won't force me to install stuff I don't want to. It will be debian based for sure, just not sure which one yet.

[whm1974]

it can be told from /var/log/syslog or with the help of "journalctl -b".

This would work if the OS were capable of loading a normal DE. As you can see from the screenshot above, that's impossible! Every reboot gets me to this screen. Before updating the system (installing the dumb microcode), all reboots went normally. But ever since the dumb microcode made its way on my computer, this is all I get everytime I start Mint 19.
I'm not gonna deal with Micronical, I'll just find a distro that won't force me to install stuff I don't want to. It will be debian based for sure, just not sure which one yet.

What are your hardware specs? Are you sure it is the Intel microcode doing this?

[rado84]

Are you sure it is the Intel microcode doing this?

100% sure! When I installed the nvidia driver (before proceeding to update manager), everything was fine. I rebooted the system so that nvidia driver starts working and the DE appeared without much of a problem. But after the update manager refused to deselect the microcode, I had to no choice but to leave it selected. And after the reboot... Well, you say the screesnot, didn't you?

AsRock B85M Pro4, Core i3-4170, Palit GTX 1050 Ti 4GB, Corsair CX750 PSU, Corsair 32GB DDR3-1600, Corsair Force LE 120GB, WD Caviar Blue + Green = 1.5TB, Chromium

No need to answer here anymore, I'm done with Mint 19!

[karlchen]

Hello, rado84.

Let me answer nonetheless. In case you do not try and reply, well, maybe other users will experience a similar problem, and maybe my reply will help them troubleshoot.
As gm10 reported, it is kernel 4.15.0-23 which introduces the dependency on intel-microcode and amd64-microcode.
This means the previous kernel, from which you upgraded to 4.15.0.23, did not and does not have this dependency.
So after switching on the machine, it should be possible to invoke the Grub boot menu and select the previous kernel and boot it.

Provided the system comes up without hassle, when booted with the previous kernel, then the usual steps could be done to identify the culprit and hopefully solve the issue:

• posting an inxi -Fxz report
• inspecting the logfile(s) /var/log/syslog, /var/log/syslog.1 or even older syslog.?.gz files. Alternatively executing journalctl -b <no>, where <no> will be 0, -1, -2 etc in order to inspect the current boot and session, the previous one, the one before the previous one etc.
• inspecting the dpkg.log file in order to determine whether some update installation did not work correctly.
  Logfiles in directory /var/log/apt, like history.log and term.log, might hold relevant details as well.
• executing sudo apt-get check in order to check for potentially broken packages.
  executing sudo dpkg --configure -a in order to configure potentially unconfigured or only half-configured software packages.

In case booting the previous kernel does not convince your Mint 19 to startup, in this case it should still be possible to start the machine from the same Linux Mint 19 live system, which has been used to install Mint 19; only this time only boot to the live desktop and do not launch the Mint installer. The live desktop will permit to execute the steps, briefly explained above.

Regards,
Karl

[rado84]

Thanks, Karlchen, but it's not my job to fix the bullsh*t Mint devs have done.
A moment ago I exported from a backup the last supposedly stable Mint 18.3 Cinnamon edition. When it started, all the applets and desklets stopped working with the message they're no longer supported by the current system. Which is weird because when I made that backup they were supported and worked flawlessly. I checked the boot directory and discovered my Mint has downloaded (without asking me, ofcourse) a kernel version 4.15.something.something. When I created the backup, it was 4.13.0-45.
So, if nobody here can see how Mint devs behave just like Microcrap by forcing unwanted updates, it's your loss. I'm done with Mint for a very, very long time! I'd rather go back to Windows than to deal with the tyranny of Mint devs. Because of that digital tyranny I changed my phone from Windows 10 to an Android one.
It's been nice to talk to all of the members here (one moderator excluded because he doesn't know the meaning of the word "politeness"). Hopefully we'll talk again when the devs realize digital tyranny will lead to Mint's destruction.

[JosephM]

I'm done with Mint for a very, very long time! I'd rather go back to Windows than to deal with the tyranny of Mint devs.

Well have fun Ranting is hardly the way to help get anything accomplished.

[whm1974]

I'm done with Mint for a very, very long time! I'd rather go back to Windows than to deal with the tyranny of Mint devs.

Well have fun Ranting is hardly the way to help get anything accomplished.

Indeed and I don't think that Mint is even close to being digital tyrannical at all. It pays to read the release notes and known issues before doing an in place upgrade to a new release.