The Intel Fortran Compiler was restored in Sept. 2026... and more NVIDIA driver problems were solved along the way.
A report came in that mpiifx could not locate the Intel Fortran Compiler, ifx, which was causing PERSEUS compilations to fail.
The reason turned out to be that the prior "apt upgrade" from May, which added oneAPI 2026.0, omitted ifx for no apparent reason.
Repeating "apt upgrade" did not restore ifx, and worse, the latter upgrades turned out to break the NVIDIA graphics drivers as well.
## kill the snap process that is stuck in an "uninterruptible sleep" (D) state - $ sudo /usr/lib/snapd/snap-discard-ns firmware-updater $ snap changes
The last command showed that the stuck process remained. Of the options, it seemed that a reboot would be the best next move.
It's not the first time snap had caused trouble; there had been a lengthy troubleshooting session with Google AI in August as well.
In what follows, many of the ideas and suggestions came from interactions with Google AI (Gemini)...
$ apt list --installed | grep intel $ sudo apt-get install intel-oneapi-compiler-fortran [canceled because the version to be installed was 2026.1] ## after terminating the user desktop sessions... $ sudo apt update $ sudo apt upgrade [no intel-oneapi-compiler-fortran in the list of upgrades] $ sudo reboot $ which ifx [still no ifx in the path] $ sudo apt update $ sudo apt upgrade [still no intel-oneapi-compiler-fortran in the list of upgrades] $ sudo apt install intel-oneapi-compiler-fortran intel-hpckit ## Google AI said including intel-hpckit would trigger Fortran upgrades in the future
The final, separate installations fixed the problem with ifx, and PERSEUS could be compiled and linked successfully.
The path was seemingly clear for a reboot and final check.
$ sudo reboot $ sudo apt list --upgradable
Lots of NVIDIA packages appeared in the list of packages that hadn't been upgraded. It was worrisome; why were they blocked?
Google AI suggested checking first to see if they were part of a phased upgrade, then simulating how an installation would go:
$ apt policy nvidia-driver-590 nvidia-driver-590: Installed: 590.48.01-0ubuntu0.24.04.4 Candidate: 590.48.01-0ubuntu0.24.04.5 ... $ sudo apt install -s nvidia-driver-590 $ sudo apt full-upgrade -s
Nothing was held up due to a phased release; rather, the NVIDIA packages were being kept back due to a failed dependency.
It seemed like a very minor NVIDIA upgrade, so maybe it wasn't needed at all? But what if the NVIDIA drivers were now broken?
$ nvidia-smi NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.
Not good. Google AI had a few ideas as to why it wasn't running and recommended trying some diagnostics:
$ mokutil --sb-state SecureBoot disabled Platform is in Setup Mode $ lsmod | grep nvidia [no output, module is not even running in the background] $ sudo modprobe nvidia modprobe: FATAL: Module nvidia not found in directory /lib/modules/7.0.0-34-generic
The last result implies that the NVIDIA kernel modules were never built or installed after the kernel was upgraded to 7.0.
This situation arose as a result of the failed dependency check, which prevented the prebuilt modules from being installed.
After some back and forth with Google AI, the conclusion was that the pre-compiled NVIDIA packages were stuck.
The way to resolve the issue was to switch over to the dynamic compilation track and allow DKMS to do local builds.
## Install DKMS and the required Linux kernel header blueprints $ sudo apt install linux-headers-7.0.0-34-generic linux-headers-generic-hwe-24.04 $ sudo apt install dkms ## Re-trigger the installer so DKMS intercepts and builds the module $ sudo apt install --reinstall nvidia-driver-590 nvidia-kernel-source-590 ## Once it finishes processing, manually kick the module alive inside the runtime environment $ sudo modprobe nvidia ## Verify the environment right away by executing nvidia-smi $ nvidia-smi [looks good!] $ apt list --upgradable [the NVIDIA packages no longer show up!]
At this point, the remote desktop (Xfce) worked great, but the head terminal (GNOME) was blank and wouldn't wake up.
Google AI: "This is a classic quirk that happens when forcing NVIDIA modules into a live kernel via SSH."
The AI solution was simply to restart the Gnome Display Manager, which had to be done from a separate SSH session.
$ sudo systemctl restart gdm3 $ cat /proc/driver/nvidia/version $ sudo reboot
All this worked perfectly: the driver version was correctly updated, and the modifications survived a reboot.
GNOME now worked as expected on the head monitor, and Xfce worked properly on remote desktops.
A general OS refresh was done in May 2026... to patch the kernel against the CVE-2026-98432 security vulnerability.
$ sudo apt update && sudo apt upgrade $ sudo reboot
Several warnings pertaining to snap appeared when attempting to start firefox from a terminal on the desktop.
Google AI suggested trying all of the following steps, though only the last few ultimately resolved the issue:
$ sudo /usr/lib/snapd/snap-update-ns firefox $ sudo systemctl stop snapd.service snapd.socket $ sudo umount -l /var/lib/snapd/sandbox/* $ sudo systemctl start snapd.service snapd.socket $ sudo journalctl -b -e | grep -E "audit|apparmor|denied" $ sudo snap refresh core24 --channel=stable $ sudo apparmor_parser -r /var/lib/snapd/apparmor/profile $ sudo /usr/lib/snapd/snap-update-ns firefox ## These are the steps that finally stopped the warnings... $ sudo snap abort firefox $ sudo systemctl restart snapd.service $ sudo snap refresh firefox ## firefox now came up without warnings, but another reboot seemed advisable $ sudo reboot
In another quick test, "icx --version" gave warnings about preferring gcc 13 over 14 due to missing libstdc++ headers.
It seemed like it was getting confused due to side-by-side installations of gcc 13 and 14 (which is allowed in Ubuntu 24.04).
One further installation fixed this:
$ sudo apt install libstdc++-14-dev ## clean up old Intel oneAPI packages $ sudo apt autoremove