下載了CentOS 7的內核，準備編譯一下，結果每次make都提示需要升級編譯器，於是我編譯安裝了一個gcc 10，安裝在了
/home/virtual/SoftwareLibrary中，結果重啓後，系統就涼了，啓動過程停在Host SMBus controller not enabled這句話
停在Host SMBus controller not enabled其實並不代表系統涼涼，按Ctrl+Alt+F2就可以切換到控制檯模式。
登陸系統後，嘗試ping命令，發現網絡無問題，於是嘗試啓動ssh服務：
systemctl restart sshd
發現失敗了，提示我用journalctl -xe查看日誌。
在日誌裏發現了大量的失敗：
Jun 17 22:23:45 localhost.localdomain sh[1151]: /usr/bin/abrt-dump-oops: error while loading shared libraries: libgcc_s.so.1: failed to map segment from shared object: Permission denied
Jun 17 22:23:45 localhost.localdomain sh[1151]: abrt-watch-log: Warning, '/usr/bin/abrt-dump-oops' did not process its input
Jun 17 22:23:45 localhost.localdomain setroubleshoot[1614]: SELinux is preventing /usr/bin/abrt-dump-xorg from execute access on the file /home/virtual/SoftwareLibrary/lib64/libgcc_s.so.1. For complete SELinux messages run: sealert -l 6e60010a-b78e-4de5-b3ec-126f46e60558
Jun 17 22:23:45 localhost.localdomain python[1614]: SELinux is preventing /usr/bin/abrt-dump-xorg from execute access on the file /home/virtual/SoftwareLibrary/lib64/libgcc_s.so.1.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that abrt-dump-xorg should be allowed execute access on the libgcc_s.so.1 file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'abrt-dump-xorg' --raw | audit2allow -M my-abrtdumpxorg
# semodule -i my-abrtdumpxorg.pp
Jun 17 22:23:47 localhost.localdomain sh[1151]: /usr/bin/abrt-dump-oops: error while loading shared libraries: libgcc_s.so.1: failed to map segment from shared object: Permission denied
Jun 17 22:23:47 localhost.localdomain sh[1151]: abrt-watch-log: Warning, '/usr/bin/abrt-dump-oops' did not process its input
Jun 17 22:23:47 localhost.localdomain setroubleshoot[1614]: SELinux is preventing /usr/bin/abrt-dump-xorg from execute access on the file /home/virtual/SoftwareLibrary/lib64/libgcc_s.so.1. For complete SELinux messages run: sealert -l 6e60010a-b78e-4de5-b3ec-126f46e60558
Jun 17 22:23:47 localhost.localdomain python[1614]: SELinux is preventing /usr/bin/abrt-dump-xorg from execute access on the file /home/virtual/SoftwareLibrary/lib64/libgcc_s.so.1.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that abrt-dump-xorg should be allowed execute access on the libgcc_s.so.1 file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'abrt-dump-xorg' --raw | audit2allow -M my-abrtdumpxorg
# semodule -i my-abrtdumpxorg.pp
Jun 17 22:23:49 localhost.localdomain sh[1151]: /usr/bin/abrt-dump-oops: error while loading shared libraries: libgcc_s.so.1: failed to map segment from shared object: Permission denied
Jun 17 22:23:49 localhost.localdomain sh[1151]: abrt-watch-log: Warning, '/usr/bin/abrt-dump-oops' did not process its input
Jun 17 22:23:49 localhost.localdomain setroubleshoot[1614]: SELinux is preventing /usr/bin/abrt-dump-xorg from execute access on the file /home/virtual/SoftwareLibrary/lib64/libgcc_s.so.1. For complete SELinux messages run: sealert -l 6e60010a-b78e-4de5-b3ec-126f46e60558
Jun 17 22:23:49 localhost.localdomain python[1614]: SELinux is preventing /usr/bin/abrt-dump-xorg from execute access on the file /home/virtual/SoftwareLibrary/lib64/libgcc_s.so.1.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that abrt-dump-xorg should be allowed execute access on the libgcc_s.so.1 file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'abrt-dump-xorg' --raw | audit2allow -M my-abrtdumpxorg
# semodule -i my-abrtdumpxorg.pp
Jun 17 22:23:50 localhost.localdomain sudo[3429]: pam_unix(sudo:session): session closed for user root
Jun 17 22:23:50 localhost.localdomain setroubleshoot[1614]: SELinux is preventing /usr/bin/abrt-dump-xorg from execute access on the file /home/virtual/SoftwareLibrary/lib64/libgcc_s.so.1. For complete SELinux messages run: sealert -l 6e60010a-b78e-4de5-b3ec-126f46e60558
Jun 17 22:23:50 localhost.localdomain python[1614]: SELinux is preventing /usr/bin/abrt-dump-xorg from execute access on the file /home/virtual/SoftwareLibrary/lib64/libgcc_s.so.1.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that abrt-dump-xorg should be allowed execute access on the libgcc_s.so.1 file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'abrt-dump-xorg' --raw | audit2allow -M my-abrtdumpxorg
# semodule -i my-abrtdumpxorg.pp
仔細研究，關鍵的一行是
SELinux is preventing /usr/bin/abrt-dump-xorg from execute access on the file /home/virtual/SoftwareLibrary/lib64/libgcc_s.so.1.
這不正好是我的gcc安裝路徑麼？看來是系統啓動的時候加載的模塊在我的路徑中，無法訪問。
我用chmod將相關路徑設爲744，給了讀權限，卻還是失敗，很疑惑。
於是我去/etc/ld.so.conf.d/中，將搜索路徑/home/virtual/SoftwareLibrary/lib64/去掉，ldconfig後，再次systemctl restart sshd就成功了。看來gcc要安裝在一個所有人都能訪問的目錄？