主机A是一台新购的GPU主机,在该主机上执行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.
该GPU主机,其内存为32G,已要求商家安装ubuntu 20.04操作系统,并安装好nvidia显卡驱动。
由于主机内存偏小,在启动主机前,我首先给主机增加了一条内存,将内存扩展至64G,然后再开机。开机后,执行nvidia-smi命令出现了以上报错。
难道商家忘了安装显卡驱动,那就自行安装吧。在自行安装之前,还是简单检查了一下系统是否有安装nvidia显卡驱动相关软件,结果发现系统已经包含了一系列nvidia相关软件包,那就说明商家应该是已经装过显卡驱动了,不过我没有深究,只是清理了相关软件,然后重新安装显卡驱动。
显卡驱动安装成功后,重启主机,执行nvidia-smi命令,发现依然在报同样的错误。
暂时把这个问题放在一边,因为还有另外一台GPU主机面临着一个更加棘手的问题需要处理。
主机B同样是一台GPU主机,该主机没有配备显示器,一直通过远程ssh连接的方式来操作,后来计划给该主机增加一条内存,本以为这是基本操作,没有想到增加内存后无法远程连接到该主机了,多次重启皆是如此,只好给该主机连上显示器,结果发现,增加内存后主机启动会卡住,有如下提示:
- Memory modules were found on non-optimized memoryslot. Please follow the instruction
- and move the yellow-marked memory modules to the arrow-marked optimized memory slots.
- 【确定】【Don`t Remind】

其大意是内存条没有安装到推荐的内存插槽,无法发挥最佳性能。
根据提示重新调整内存条的安装位置后,主机可以正常启动了。
这个问题的坑点在于,内存条没有安装到推荐位置,主机只是没法发挥最佳性能,并非不能运行。因此,这应该是一个可选提示,可自动跳过,而不应该阻断系统启动,要求用户必须手动选择下一步的操作。更坑的点在于,对于通过远程使用的主机,用户因为这一设定根本就没法连接上主机了,只有搞个显示器给主机装上才能发现问题。
一台全新的主机出现一个问题已经够倒霉了,要是同时出现几个问题,不但令人头大,还可能几个问题相互影响,相互误导,使得问题更加难以定位。
主机C是另外一台新购的GPU主机,在使用该主机的过程中,安装一个软件时出现了错误:
- (base) root@yons-MS-7E06:/# apt install nvidia-cuda-toolkit
- W: 由于文件系统为只读,因而无法使用文件锁 /var/lib/dpkg/lock-frontend
- W: 由于文件系统为只读,因而无法使用文件锁 /var/lib/dpkg/lock
- E: dpkg 被中断,您必须手工运行 ‘dpkg --configure -a’ 解决此问题。
这应该只是一个小问题,重启大法伺候,结果,系统重启失败,屏幕上提示:
- /dev/sda: UNEXPECTED INCONSISTENCY;RUN fsck MANUALLY.
- the root filesystem on /dev/sda requeries a manual fsck
这意思是硬盘出现了故障,需要手动修复/dev/sda。
于是直接运行:
fsck.ext4 -y dev/sda
修复完成reboot重启,系统正常启动。新主机就出现硬盘故障,还有谁。
还是主机C,该主机的使用者反馈,使用scp从其他主机拷贝过来的一些文件无法使用,似乎已经损坏,经过确认,拷贝后的文件与源文件的文件摘要并不相同。在拷贝小文件时,没有出现过问题,在拷贝几个GB以上的大文件时,该问题才暴露出来,而拷贝过程没有任何错误提示。
在收到反馈后,马上联想到了一天前该主机上才出现的文件系统故障问题,难道真的中招了,碰到了一块有问题的硬盘?
除了出现过文件系统故障的硬盘,该主机还有另外一块硬盘,也是新的。然而,使用人员表示,拷贝到这块硬盘的文件也有损坏的现象。难道我同时遇到了两块有问题的新硬盘,人品没有那么差吧!
于是我在该主机上执行了几次拷贝测试,并没有发现使用者所反馈的问题,一切正常。让使用者继续使用该主机,接着,使用者反馈,用root用户来拷贝文件就没有问题,使用其他用户来拷贝文件则会出现文件坏的问题,这么诡异?
又过了一天,使用者又反馈说,又遇到了文件拷贝损坏的问题了,看来该问题和系统用户身份无关,并且是概率性的。又想到不太可能两块新硬盘同时有问题,并且我也对两块硬盘都执行了一些硬盘检测,并没有发现错误,于是没工夫继续深究,直接开启了系统重装大法。
重装系统后,我天真地认为大概率问题已经不存在了,于是先给主机安装了显卡驱动,然后把主机交给使用者,结果使用者反馈,问题依旧。
怪哉,两块新硬盘同时有问题的概率应该不大,操作系统也重装过了,不是操作系统的问题,剩下的只能是内存了,于是我给主机更换了内存,再次测试发现,问题消失。再次把主机内存替换回来,问题又出现了。现在基本可以判定,就是内存导致了文件传输损坏。
在问题3中,我们最终确认是内存硬件问题导致了文件传输损坏。同时,主机C也出现了主机A同样的问题:
原本能够正常运行的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.
而这两台主机的共同点在于,原本nvidia-smi执行正常,之后关闭主机。然后主机A是增加了内存,而主机C是更换了内存。再之后启动主机,两台主机均出现了nvidia-smi命令执行失败的现象,期间并没有执行系统升级或者其他软件升级。
这就是说,GPU主机的内存调整会导致显卡驱动失效。再次测试发现,给主机更新内存后,主机BIOS会检测到内存变化,系统启动时会出现一个短暂的提示:
- Devices Changed (CPU or Memory) or CMOS have been Cleared. Please enter Setup to configure your system.
-
- Press F1 to run setup.
- Press F2 to load default values and continue.

该提示会自动跳过,也就是说,bios在检测到内存变化后,如果用户没有仔细查看提示,bios就会自动执行bios配置重置操作,然后进入系统。
正是这个bios配置重置操作,导致了GPU主机的nvidia显卡驱动失效。
在bios的默认设置中,有一个叫做【secure boot/安全启动】的选项。
该选项的默认配置为【enable/启用】,在这种情况下,nvidia显卡驱动在系统启动时不会被加载,从而导致nvidia-smi命令失效。
设置【secure boot/安全启动】为【disable/禁用】之后,一切恢复正常。