Design Flaw With Installation Process...

[ytene]

I'm honestly not sure if this is a bug report or an enhancement request; it might be a bit of both. I've just recently had to attempt a re-installation of Mint 18.3, after an Update Manager series of updates bricked my machine all the way down to "kernel panic"... Unfortunately, as I'll explain below, it has proven to be impossible to re-install, so I am now without a Mint system on my main machine. Sorry if what follows gets a bit lengthy, but I'll try and set out why I think the installation process is flawed...

1. Hardware
Motherboard: MSI "Big Bang Power II"
CPU: Intel Core i7 Extreme 4960x
RAM: 32Gb 2400MHz DDR4
GPU: nVidia 1080GTX

2. The previous build on this hardware was completed shortly after Mint 18.3 went Gold. I was able to complete the build, install the nVidia proprietary drivers (I have a triple-monitor setup that Nouveau struggles with) and run a flawless Mint system up until earlier this month.

3. After the Mint Update caused the kernel panic [or, more accurately, after I was unable to diagnose and fix the root of that problem] I decided to wipe and perform a clean installation. This is not an issue for me - installing Mint is quick and easy; I keep no data on the system volume. The installation went flawlessly, right up to the point where I completed, rebooted, performed a system update and then tried to apply the nVidia driver. At that point the system hung, then rebooted into a Nouveau driver state, but with a corrupted dpkg database. No amount of trying - i.e. using "dpkg --configure -a" could repair that damage, because the step that broke was related to the kernel updates for the nVidia driver, a process which dpkg kept blindly trying to restart.

4. I've been unable to get past that point; I've even tried downloading and installing the vanilla nVidia drivers, but that process gets as far as recognising that the default kernel has portions of the Nouveau driver embedded and then stops...

5. Here's the issue... After completing the basic build and update and going to "Driver Manager" to deploy the nVidia driver, the *version* of the nVidia driver that I get from "Driver Manager" today is *different* from the version I got when I first successfully built my 18.3 image. In other words, because the nVidia driver version is decoupled from the binaries on the installation media, it means that it is not only possible to get different builds, but that this is exactly what's happening.

Something that worked perfectly given the various package versions around the middle of last year simply won't work today, even though I am following *exactly the same process*. Within Mint's "Driver Manager", there is no ability for me to apply my choice of nVidia driver version - I'm presented with the latest packaged version and that's it - no other options are available to me. Certainly the version offered today has been updated - it was released after my last system build completed successfully...

I raised a separate thread to ask for help with the nVidia problem, which you can read in detail here:-

viewtopic.php?f=59&t=265526&p=1442421#p1442421

and although I did receive some guidance, none of it proved effective, so I continue to be unable to run Mint on my system. However, as incredibly frustrating as that is [and it is, of course, frustrating], I think the possible issue with inconsistent builds is much, much more serious.

Now we get to the suggestion part...

I'm pretty sure that there is a way that I could export a complete transcript of the dpkg database into some form of text or XML file... However, is there a way of importing that back in to a Mint build, so that the resultant system is an exact mirror of the one from which the export is taken?

Finally, a question... Can anyone suggest to me any way that I might be able to perform a basic installation of 18.3 [i.e. running on the default-installed Nouveau driver] and then try each of the available packaged versions of the nVidia driver, working chronologically backwards until I find one that works? Even if that required me to perform another half-dozen installations until I found the right combination, I would be happy to do this if it got me a working machine.

I have a terrible feeling someone will tell me I missed my chance and that there is a way to do this, but I needed to do something on the machine before I trashed it with the Mint Update that broke it at the beginning of the month...

Any guidance you can offer would be gratefully received.

Thank you.

[catweazel]

5. Here's the issue... After completing the basic build and update and going to "Driver Manager" to deploy the nVidia driver, the *version* of the nVidia driver that I get from "Driver Manager" today is *different* from the version I got when I first successfully built my 18.3 image. In other words, because the nVidia driver version is decoupled from the binaries on the installation media, it means that it is not only possible to get different builds, but that this is exactly what's happening.

This is completely normal. If you wanted an exact replica of your original install then you ought to have made a backup by imaging the drive.

[michael louwe]

@ ytene, .......

.

.
It seems, the Meltdown and Spectre kernel patches are not compatible with the proprietary Nvidia and AMD graphics drivers(and also VirtualBox 5.0) = use the open-source nouveau driver or use the kernel without the Meltdown and Spectre patches, eg kernel 4.13.24. ... viewtopic.php?t=261343 (Re: How to update your kernel for Meltdown and Spectre)

[ytene]

Michael,

Thank you very much for the helpful pointer.

I can confirm for other readers that the application of kernel 4.13.0-37 does indeed solve this problem. This confirms the conclusion you drew in your response, which is that there is a compatibility issue between the nVidia proprietary driver and the Meltdown/Spectre-safe versions of the Linux kernel as adopted by Mint.

I have an account on the nVidia forums and will report this as an issue.

I am extremely grateful for the help and support that you provided here... I understand that I am now running an unsafe machine [hopefully temporarily] but at least I have a working system.

Thank you.

[ytene]

5. Here's the issue... After completing the basic build and update and going to "Driver Manager" to deploy the nVidia driver, the *version* of the nVidia driver that I get from "Driver Manager" today is *different* from the version I got when I first successfully built my 18.3 image. In other words, because the nVidia driver version is decoupled from the binaries on the installation media, it means that it is not only possible to get different builds, but that this is exactly what's happening.

This is completely normal. If you wanted an exact replica of your original install then you ought to have made a backup by imaging the drive.

Catweazel, thanks for this clear advice and for the earlier support that you offered me when I raised this issue originally. I think, in this instance, however, you have misunderstood the motivation that prompted me to start this thread. It wasn't to address the lack of roll-back capability [that was absolutely "my own fault"]. It was, however, the observation that the current design of "Driver Manager" is hard-coded to give the user no choice in the version of the proprietary driver they are offered. DM has basically hard-coded this to be "the latest".

I was trying to make the suggestion that there may be all sorts of reasons that a little flexibility here would be a good thing. Just as Update Manager allows me to go and select which of the available kernels I might like to deploy (I used exactly this feature to implement the work-around that Michael suggested) I would like to ask that the Maintainers consider doing something similar with Driver Manager, to allow a user to select from a range of available driver versions, just in case there is a reason they wish to deploy something other than the latest edition.

That was the sole purpose behind my starting of this thread.

Thank you.