RHES7.7을 실행하는 호스트 중 하나에 아래와 같은 문제가 있습니다.
cat /etc/redhat-release
Red Hat Enterprise Linux Server 버전 7.7(Maipo) RHES7.7을 실행하는 두 개의 호스트가 있습니다. 그 중 한 명은 재부팅 후 이 문제에 직면했습니다. 메세지를 보내다
authorisation is not available check polkit running
이는 기본적으로 네트워크 서비스 등이 실행되고 있지 않음을 의미합니다. 따라서 콘솔을 통해서만 호스트에 액세스할 수 있습니다. 유지관리 비밀번호와 데이터 등을 입력한 후 로그인할 수 있습니다. systemctl restart polkit을 사용하여 polkit을 시작하려고 했지만 위 메시지와 함께 실패하고 다시 시작되었습니다. 어떤 제안이라도 보내주셔서 감사합니다.
추신: 이것을 실행하면 journalctl -u polkit"항목 없음"이 표시됩니다!
감사해요
고쳐 쓰다
내가 받은 오류는 다음과 같습니다.
감사합니다. 요청한 출력을 찾아주세요. 죄송합니다. 콘솔을 통해서만 호스트에 액세스할 수 있습니다.
답변1
이것은 authorisation is not available check polkit running빨간 청어입니다. 시스템이 비상 모드로 전환되어 최소한의 시스템 서비스만 실행되는 것 같습니다. 이 상태에서는 polkit.service비활성이 정상이며 예상됩니다.
나열된 첫 번째 오류 메시지는 커널에서 나온 것입니다.
nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 122124
오픈 소스 NVidia GPU 드라이버인 Nouveau 정보. 해당 드라이버나 NVidia의 독점(비공개 소스) 드라이버를 사용해 보셨나요? 콘솔에는 어떤 그래픽 하드웨어가 있습니까?
이 메시지가 현재 문제와 관련이 없을 수도 있습니다(또는 아래 참조). 특정 하드웨어 및 현재 드라이버 지원 상태에 따른 "소음"일 수도 있습니다.
두 번째 메시지는 다음에서 옵니다 systemd-udevd.
Error running install command for rtl_pci
이는 마치 모듈이 로드되는 것을 막는 것처럼 스스로 발생하는 것입니다 install rtl_pci /bin/false. 부작용으로 오류 메시지가 발생합니다./etc/modprobe.d/local-blacklist.confrtl_pci
오류 메시지를 제거하려면 를 로 /bin/false바꾸 십시오 . 이렇게 하면 모듈 제거가 오류가 아님을 시스템에 알릴 수 있습니다.local-blacklist.conf/bin/true
세 번째 메시지는 시스템이 비상 모드로 전환되는 이유일 수 있습니다. systemd16진수 이스케이프를 디코딩한 후 다음과 같이 표시 됩니다 .
Timed out waiting for device dev-disk-by-label-\/apps.device.
/dev/disk/by-label/\/apps이는 , 즉 레이블이 있는 파일 시스템 을 나타냅니다 /apps. 귀하에 따르면 /etc/fstabext4 유형의 파일 시스템이어야 하며 에 마운트되어야 합니다 /apps.
에 나열된 다른 모든 파일 시스템은 /etc/fstab성공적으로 마운트되었습니다 /apps. 출력에 따르면 해당 파일 시스템 lsblk은 찾을 수만 있는 것으로 나타납니다 /dev/sdd. 마운트 해제된 ext4 파일 시스템을 포함할 수 있는 다른 장치는 없습니다.
그런데 그에 따르면 lsblk디스크에는 파티션이 없습니다. 전체 디스크를 단일 파일 시스템으로 초기화하셨나요? 그렇지 않은 경우 디스크의 파티션 테이블이 손상/덮어쓰기되었거나 디스크에 결함이 있을 수 있습니다.
systemctl status apps.mount및/또는 journalctl -u apps.mount설치 시도 중에 발생한 문제에 대한 추가 정보를 제공할 수도 있습니다.
다른 초기화 시스템을 사용하는 이전 RHEL 버전과 달리 systemdRHEL 기반 RHEL 7.x는 파일 시스템에 또는 마운트 옵션이 없으면 나열된 파일 시스템 중 하나라도 마운트할 수 없는 경우 비상 모드로 전환됩니다. 따라서 마운트 실패는 시스템이 비상 모드로 전환되는 가장 큰 이유입니다./etc/fstabnoautonofail/apps
일시적으로 마지막 줄을 주석 처리 /etc/fstab하고 재부팅하여 시스템을 보다 정상적인 상태로 만들 수 있습니다. 이렇게 하면 추가 진단 및 복구가 더 쉬워집니다.
/dev/sdd먼저 상태를 확인하여 문제 해결을 시작할 수 있습니다 smartctl -x /dev/sdd. 디스크 오류를 나타내는 경우 새 디스크를 주문하고 가급적이면 /apps양호한 백업에서 복원할 계획을 세워야 할 때입니다. 그러나 smartctl디스크에 오류가 발생했음을 나타내지 않는다면 이것이 전부가 아닐 수도 있습니다. 디스크에 smartctl항상 감지할 수 없는 방식으로 오류가 발생할 수 있습니다.
(좋은 백업이 없고 그 안에 있는 데이터의 /apps가치가 크다면 이제 전문 데이터 복구 서비스를 사용할지 아니면 직접 데이터를 복구할지 결정해야 할 때입니다.)
/dev/sdd파티션 테이블이 있어야 한다는 것을 알고 있다면 testdisk이를 복구하는 데 좋은 도구가 될 수 있습니다.
yum install epel-release
yum update
yum install testdisk
testdisk /dev/sdd
/dev/sdd전체 디스크가 단일 ext4 파일 시스템으로 초기화되었다고 확신하는 경우 다음을 시도해 볼 수 있습니다.
e2fsck -C0 /dev/sdd
도구가 질문하기 시작하면(자동으로 안정적으로 해결할 수 없는 문제가 있음을 나타냄) 검사를 중단하고 먼저 디스크 이미지를 만들어야 합니다.
노트:이 명령가설당신이 가리키는 장치~해야 한다ext2/ext3/ext4 파일 시스템을 포함하고 이에 따라 작동합니다. 유효한 슈퍼 블록을 찾을 수 없다면 디스크의 시작 부분이 손상되었거나 덮어쓰기되었거나 파일 시스템이 단순히 디스크의 시작 부분에서 시작되지 않았기 때문일 수 있습니다.
확실하지 않거나 디스크에 하드웨어 오류 증상이 나타나는 경우 가장 먼저 해야 할 일은 최대한 빨리 오류가 발생한 디스크를 이미지화하는 것입니다.ddrescue또는 유사한 도구. 또한 잠재적으로 오류가 발생한 디스크의 이미지를 저장하려면 적절한 크기의 또 다른 디스크가 필요합니다.