### Upgrading to Fedora 34 from Fedora 32 (or Fedora 33)

#### (while being careful about cuda versions)

Suppose you already have a working Fedora 32 (or 33) machine, and want to upgrade : As always, the Nvidia drivers are going to be painful!

Once again, the negativo repo wants to keep Fedora too up-to-data (latest cuda is v11.4) for current builds of TF and PyTorch.

Fortunately, cuda v11.3 works (confirmed) for TF and PyTorch, so we can use the negativo repo for everything, if we are careful how it gets installed.

### Install the negativo repo

Get the negativo Nvidia repo if you haven’t already :

And (only if you need it for display ahead of the upgrade) install the nvidia driver :

### Remove cuda ahead of the upgrade

NB: Assuming we’re still on Fedora 32 (or 33).

If you’re currently below Fedora 32, you’ll need to upgrade to Fedora 32 before going further - it seems like more than 2 steps is too big a gap before FC34.

Remove the current cuda (since the upgrade process will try and upgrade to the latest, which is ‘too far’):

### Add back the correct cuda after the upgrade

See the rpm package lists to see where the version number information came from.

Install the correct cuda packages:

Now you should be able to check :

Surprisingly, even though the rpms should all be 11.3, the nvidia-smi mentions 11.4 at the top. This seems normal.

#### Stop cuda getting upgraded by mistake

To /etc/dnf/dnf.conf add:

### Python installation using virtual environments

The basic virtual environment creation (NB: the old environment won’t work any more, so move it away to ~/DELETE-ME_env38, for instance) :

#### Add TensorFlow (simple, for once!)

Still in env39 :

And test out the installation using a Python CLI instance:

For PyTorch, we must resort to messing with the cuda versions, though this should work, since Nvidia talks about backward compatibility post 11.1 (and this installation method does seem to work) :

And test out the installation using a Python CLI instance:

And add a finicky extra, if needed:

### NB: Crypto changes during upgrade

Fedora strengthened its cryptographic key standards in the move to Fedora 33 (and beyond), which essentially means that the default key type previously generated (ssh-rsa) isn’t acceptable any more.

This means that any key exchange with an upstream server where you have created an authorized_user using a ssh-rsa key won’t work any more unless you :

• Or:
• Create a new (better) certificate on your local machine; and
• Upload it to the server

The simplest way to do this is to first create a better certificate locally (once):

And then temporarily ‘backtrack’ locally to then copy the new id up to each server that needs it (in the case that you don’t want to type in the user password, or cannot…) :

This leaves the local system with ‘modern’ defaults again, while giving the server the option of a stronger key.

Later on, I guess, we should update the server(s) which accept older keys to exclude ssh-rsa keys too.

All done!