yum 업그레이드는 "가장 빠른 미러 확인" 직후 프롬프트를 반환합니다.

yum 업그레이드는 "가장 빠른 미러 확인" 직후 프롬프트를 반환합니다.

서버에서 yum 업그레이드를 실행하려고 하는데 아무 것도 수행되지 않습니다.

[myusername@server-1 ~]$ sudo yum upgrade
Loaded plugins: fastestmirror
Setting up Upgrade Process
Determining fastest mirrors
[myusername@server-1 ~]$ █

가장 빠른 미러 플러그인을 끄려고 했더니 이런 결과가 나왔습니다...

[myusername@server-1 ~]$ sudo yum upgrade
Freeing read locks for locker 0xXXXX: XXXXX/XXXXXXXXXXXXXXX
Freeing read locks for locker 0xXXXX: XXXXX/XXXXXXXXXXXXXXX
Setting up Upgrade Process
base                                                                 | 3.7 kB     00:00

(만약을 대비해 실제 숫자를 X로 바꾸세요)

다시 시작해 보았습니다. 다시 시작한 후에도 동일한 문제가 발생합니다.

서버에는 충분한 여유 메모리와 여유 디스크 공간이 있습니다.

랙 공간 서버입니다.

편집하다: 자세한 플래그를 사용할 때 출력...

[myusername@server-1 yum.repos.d]$ sudo yum upgrade -v
Freeing read locks for locker 0xXXXX: XXXXX/XXXXXXXXXXXXXXX
Freeing read locks for locker 0xXXXX: XXXXX/XXXXXXXXXXXXXXX
Loading "fastestmirror" plugin
Config time: 0.010
Yum Version: 3.2.29
rpmdb time: 0.000
Setting up Upgrade Process
Updating Everything
Building updates object
Setting up Package Sacks
Determining fastest mirrors
[myusername@server-1 yum.repos.d]$

답변1

"su"를 실행하여 더 많은 정보를 얻었습니다.

불법적인 지시

그러다가 이걸 구글링했어요. 이 페이지를 찾았습니다——https://www.centos.org/forums/viewtopic.php?t=58002

이 명령을 실행하십시오 -

NSS_DISABLE_HW_GCM=1 yum upgrade

그리고 업데이트 프로세스가 작동합니다.

그 링크에서...

실제 문제는 cpuinfo에 AES가 있다고 표시되어 있지만 시스템이 이를 사용하려고 하면 지원되지 않는다는 사실이 발견되어 불법 명령 충돌이 발생한다는 것입니다. 예를 들어, aes-ni가 있는 호스트에서 이 게스트를 시작한 다음 aes-ni가 없는 호스트로 마이그레이션했습니까? 아니면 게스트에게 보고된 프로세서 유형을 어떻게든 무시하시겠습니까?

환경 변수 "NSS_DISABLE_HW_GCM=1"을 설정하여 이 문제를 일시적으로 해결할 수 있습니다.

예를 들어 다음을 실행하는 경우: NSS_DISABLE_HW_GCM=1 yum search some_package ...

관련 정보