하드 리셋 후에 Fedora 27 x64가 부팅되지 않습니다. 보여주다:
Failed to mount POSIX Message Queue File System,
Failed to start Remount and Kernel File Systems,
Failed to mount Kernel Debug File System,
Failed to mount Huge Pages File System [3]
이러한 실패 뒤에는 다른 많은 실패가 뒤따랐습니다. 바라보다https://photos.app.goo.gl/qBUxT40zA2MTLTwO2
이 모든 경우에
Failed at step EXEC spawning /usr/bin/mount: Permission denied
사유로 제시됩니다. 어떻게 그래? 자체 파일 시스템을 인식하지 못합니까?
코어가 3개 있습니다.
vmlinuz-4.14.16-300.fc27.x86_64
vmlinuz-4.15.13-300.fc27.x86_64
vmlinuz-4.15.14-300.fc27.x86_64
어느 것을 시작하려고 해도 같은 일이 발생합니다.
지금까지 나는 다음을 가지고 있습니다 :
- fsck를 사용하여 파일 시스템 무결성을 확인하십시오. 모든 파티션이 깨끗합니다.
- SMART에서 보고한 디스크 상태를 확인하고 단기 및 장기 테스트를 수행합니다. 디스크가 완전히 건강합니다.
- initramfs를 다시 빌드합니다. Boot, proc, sys, dev, chroot 및 sudo dracut은 /mnt에 설치됩니다.
조언을 따르고:
실행
fsck -f on /dev/mapper/fedora-home하고 다음을 얻습니다.tree extents for i-node 524820 (on level 2) could be narrower. Fix?<y>Y
이 문제를 해결하도록 허용하십시오.
/dev/mapper/fedora-root에도 동일하게 적용됩니다. /dev/sda1(부팅 파티션)이 깨끗함을 확인합니다. 데이터 파일의 추가 파티션에 대해 동일한 유형의 추가 오류가 발견되었습니다.
rpm -V --all | grep -v " [cg] "다음과 같이 반환됩니다.
.M....... /run/libgpod
..5....T. /var/lib/selinux/targeted/active/commit_num
.......T. /var/lib/selinux/targeted/active/file_contexts
.......T. /var/lib/selinux/targeted/active/homedir_template
S.5....T. /var/lib/selinux/targeted/active/policy.kern
.M.....T. /var/lib/selinux/targeted/active/seusers
.M.....T. /var/lib/selinux/targeted/active/users_extra
.M....... /var/run/pluto
not exists /var/run/abrt
.M....... /var/log/audit
not exists /usr/lib/systemd/system-preset/85-display-manager.preset
S.5....T. /usr/share/icons/Crux/icon-theme.cache
S.5....T. /usr/share/icons/Mist/icon-theme.cacherpm -V "$(rpm -q --whatprovides /usr/bin/mount)" .M....G.. g /var/log/lastlogfixfiles check /usrlibsemanage.semanage_make_sandbox: Error removing old sandbox directory /var/lib/selinux/targeted/tmp. (Read only file system). genhomedircon: Could not begin transaction: Read only file system
아래와 유사한 여러 줄 중에서:
Would relabel /usr/src/handbrake/trunk/build/contrib/lib from unconfined_u:object_r:usr_t:s0 to unconfined_u:object_r:lib_t:s0Would relabel /usr/sbin/mount.nilfs2 from unconfined_u:object_r:bin_t:s0 to unconfined_u:object_r:mount_exec_t:s0
Would relabel /usr/sbin/umount.nilfs2 from unconfined_u:object_r:bin_t:s0 to unconfined_u:object_r:mount_exec_t:s0
Would relabel /usr/sbin/mkfs.nilfs2 from unconfined_u:object_r:bin_t:s0 to unconfined_u:object_r:fsadm_exec_t:s0RAM이 제대로 작동하는 것으로 나타났습니다. memtest86은 3.5번의 패스와 8시간 이상의 테스트 시간 동안 버그를 발견하지 못했습니다.
9. SELinux를 비활성화하고(/etc/selinux/config에서 SELinux=disabled) 재부팅합니다. 시스템이 오류 없이 시작됩니다!이는 문제가 SELinux 정책에 있음을 증명합니다. 나는 먼저 어떤 방식으로든 변경된 6가지 주요 SELinux 정책을 확인해야 한다고 생각합니다(5페이지 참조). 문제는 이것을 어떻게 현명하게 수행하느냐이다.
SELinux 구성 파일 및 file_contexts에 대한 로컬 수정 사항을 확인하십시오.
semanage module -C -l Module name Priority Language semanage fcontext -C -l fcontext SELinux type Context /usr/bin/mount all files system_u:object_r:samba_share_t:s0 /usr/share/dnfdaemon/dnfdaemon-system all files system_u:object_r:rpm_exec_t:s0 /var/run/media/przemek/extra(/.*)? all files system_u:object_r:samba_share_t:s0 /var/www/html/photo all files system_u:object_r:httpd_sys_rw_content_t:s0 /var/www/html/photo/_cache all files system_u:object_r:httpd_sys_rw_content_t:s0 /var/www/html/photo/config all files system_u:object_r:httpd_sys_rw_content_t:s0 /var/www/html/photo/content all files system_u:object_r:httpd_sys_rw_content_t:s0 /var/www/html/photo/content/folders.json all files system_u:object_r:httpd_sys_rw_content_t:s0 /var/www/html/photo/iv-config/language all files system_u:object_r:httpd_sys_rw_content_t:s0
흥미로운 점은 /usr/bin/mount에 대한 fcontext가 변경되었다는 것입니다.
시스템은 간단한 홈서버(www, 메일 등)로 24시간 운영됩니다. 가끔(몇 주에 한 번 정도) 완전히 얼어붙는 경우도 있습니다. HDD가 계속 쓰고 있습니다(반복적으로 들리지만 소리가 불규칙합니다). 키보드, 마우스 또는 원격 SSH 액세스에 응답하지 않습니다. 밤새도록 여러 번 시도했지만 복구되지 않아 이런 일이 발생할 때마다 강제로 재설정해야 했습니다. 이번에는 기다리지 않고 몇 분 후에 하드 리셋했습니다. 아쉽게도 그 이후로는 시작되지 않았습니다.
시스템이 정지되기 약 1분 전에 특정 스크립트가 응답하지 않는다는 Firefox 메시지 상자가 나타났던 것을 기억합니다. 내 선택이 기억나지 않습니다(죽여주세요/잠깐만요).
하드웨어: Hitachi HTS725032A9A364 2.5" HDD 및 4GB LPDDR3 RAM(기본 시계)을 갖춘 Gigabyte GB-BACE-3160 Brix PC.
자세한 내용은[여기]
답변1
부팅 프로세스 중에 rootfs, 홈, 메시지 큐 및 커널 파일 시스템 마운트 권한이 거부되는 원인은 무엇입니까?
[...]
이 모든 경우에
Failed at step EXEC spawning /usr/bin/mount: Permission denied사유로 제시됩니다. 어떻게 그래? 자체 파일 시스템을 인식하지 못합니까?
이러한 파일 시스템을 마운트할 수 없는 이유는 실제로 mount권한 거부 오류로 인해 프로그램을 실행할 수 없기 때문입니다. 당신이 발견한 로그 메시지는 다음과 같습니다. mount직접 실행해 보면 동일한 오류가 표시될 것으로 예상됩니다 .
디스크의 시스템 손상과 매우 흡사합니다.
일반적으로 말하면 정지된 시스템은 만족스럽지 않을 것입니다. 이는 완전히 예상치 못한 결과는 아닙니다. 하드웨어 문제, 커널 버그 또는 커널이 현재 해결 방법을 모르는 하드웨어 버그가 있을 수 있습니다.
RAM에 결함이 있으면 이상한 일이 발생할 수 있고 교체 비용이 상대적으로 저렴하므로 한 번 살펴볼 가치가 있습니다. 예를 들어 RAM을 테스트하는 데 사용할 수 있습니다 memtest86+. 제안해 주신 @thecarpy에게 감사드립니다.
Linux에서 일부 새롭지만 널리 사용되는 하드웨어를 처리하는 데 문제가 있는 경우 다른 사람이 최신 버전의 Linux에서 문제를 해결했을 수도 있습니다. 하드웨어가 한동안 사용되었거나 다른 Linux 사용자가 사용하지 않는 경우 수정하기 어려울 수 있습니다.
나도 이와 같은 시스템을 사용해 본 적이 있으며 비슷한 문제의 영향을 받았습니다.이것- 이는 매우 낮은 전력의 Intel CPU에서 발생하는 문제인 것 같습니다.[1][2]- Celeron J3160과 같은 J 시리즈가 좀 더 강력한 것 같아서 같은 문제인지는 잘 모르겠습니다.
그러나 이것을 완전히 무시하고 이와 같은 "불가능한" 메시지의 직접적인 원인이 무엇인지 알 수 있는 방법이 궁금하다면 제가 제안할 수 있는 두 가지 다른 기술이 있습니다. (그런 다음 이미 사용하고 있는 기술 중 하나를 선택하거나 적어도 우리에게 설명하는 방식을 선택하십시오.)
rpm -V "$(rpm -q --whatprovides /usr/bin/mount)"원래 패키지 체크섬을 확인하는 데 더 일반적으로 사용할 수 있습니다rpm -V --all. 출력에서 " c "가 포함된 줄은 일반적으로 무시해야 합니다. 이러한 줄은 변경이 허용된 구성 파일을 나타내기 때문입니다. --all을 사용하면 이러한 항목을 많이 볼 수 있습니다. 또한 "g"라는 줄은 무시하십시오. 이는 일부 로그 파일을 포함하여 파일을 동적으로 "생성"한다는 의미입니다. 따라서 를 사용하는 것이 좋습니다 . 처음부터 패키지를 확인하는rpm -V --all | grep -v " [cg] "첫 번째 방법을 시도해 보는 것이 좋습니다 .mounthttp://ftp.rpm.org/max-rpm/s1-rpm-verify-output.html- Fedora를 사용하고 있다는 점을 고려하면 두 번째로 확인해야 할 "권한 거부" 상황은 SELinux 속성의 손상입니다.
fixfiles예를 들어 이 프로그램은fixfiles check. Fedora 개발자조차도 실제로 SELinux를 올바르게 사용하는 방법을 모르기 때문에 이는 놀라울 정도로 관련 없는 출력을 제공할 수도 있습니다. 이 명령에 대한 유용한 조언을 찾기가 더 어렵다고 생각합니다.fixfiles check /usr이것이 최소한 /usr/bin/mount에서 발생하는 특정 오류를 다루는 동시에 더 광범위한 손상을 찾고 가장 시끄러운 오탐을 방지할 수 있기를 바랍니다.
지금까지 나는 다음을 가지고 있습니다 :
- SMART에서 보고한 디스크 상태를 확인하고 단기 및 장기 테스트를 수행합니다. 디스크가 완전히 건강합니다.
예, SMART 건강을 테스트하는 것은 항상 좋습니다. 디스크 손상이 의심되는 경우 이러한 테스트 중 하나를 실행하는 것이 좋습니다(Long이 가장 좋다고 생각합니다).
- fsck를 사용하여 파일 시스템 무결성을 확인하십시오. 모든 파티션이 깨끗합니다.
좋은 생각이지만 한 가지 문제가 있습니다. 하드웨어 오류가 발생할 수 있는 경우 파일 시스템 무결성을 확인했음을 지정하려면 를 실행했음을 지정해야 합니다 fsck -f.
(저널 파일 시스템(예: ext4)의 "더티" 상태가 지워졌 fsck거나 커널이 단순히 로그를 재생했을 수 있습니다. 이 경우 fsck없이 실행하면 -f추가 작업 없이 파일 시스템이 "클린"으로 표시되었다고 간단히 보고됩니다 . 점검.)
또한 ext4를 루트 파일 시스템으로 사용하고 있음을 지정해야 합니다(이 경우라고 가정). btrfs 또는 XFS를 사용하는 경우 기존 명령으로는 fsck아무 것도 수행할 수 없습니다.
(이 경우 파일 시스템별 명령이 더 도움이 될 수도 있고 그렇지 않을 수도 있습니다. 기본적으로 ext2 파일 시스템 제품군은 원래 로깅보다 앞서서 fsck철저한 무결성 검사 파일 시스템을 수행할 수 있도록 설계된 시스템이 개발되었습니다. 기타 파일 시스템은 서로 다른 역사를 가지고 있습니다.
btrfs 및 ZFS는 자체적으로 오류를 감지하도록 설계된 "체크섬 파일 시스템"입니다. 이 시점에서 "정리" 실행을 고려하는 것이 합리적입니다. 그러면 해당 시점에 생성된 체크섬과 비교하여 파일 시스템에 기록된 데이터를 명시적으로 확인합니다. (성능상의 이유로 제외된 특정 유형의 파일은 여기에 포함되지 않습니다.)
예를 들어 디스크로 전송하는 동안 데이터가 손상된 경우 Clean은 이를 감지하지만 SMART 테스트는 감지하지 않습니다. )
답변2
문제는 파일에 대한 잘못된 파일 컨텍스트로 인해 발생합니다 /usr/bin/mount: samba_share_t.
파일 컨텍스트 변경은 하드 리셋으로 인한 일부 버그로 인해 발생한 것이 아니라 SELinux 경고 브라우저의 첫 번째 제안을 따르기로 한 부주의한 결정 때문입니다. 아래 스크린샷을 참조하세요.
첫 번째 제안은 smbd가 getattr에 액세스할 수 있도록 /usr/bin/mount파일 컨텍스트를 변경하는 것입니다.samba_share_t
해결책은 다음과 같습니다.
- 잘못된 파일 컨텍스트를 제거하려면 기본값을 복원하고 파일 레이블을 다시 지정하세요.
[root@atlas ~]# ls -Z /usr/bin/mount system_u:object_r:samba_share_t:s0 /usr/bin/mount [root@atlas ~]# semanage fcontext -d /usr/bin/mount [root@atlas ~]# restorecon -v /usr/bin/mount Relabeled /usr/bin/mount from system_u:object_r:samba_share_t:s0 to system_u:object_r:mount_exec_t:s0 [root@atlas ~]# ls -Z /usr/bin/mount system_u:object_r:mount_exec_t:s0 /usr/bin/mount - 시스템을 다시 시작하십시오.
이는 비상 콘솔에서 수행할 수 있지만 콘솔을 사용하여 SELinux를 허용 모드로 전환하고 시스템을 부팅한 다음 위에서 설명한 대로 파일 컨텍스트를 변경했습니다.
수정된 SELinux 파일 컨텍스트(첫 번째 게시물의 10페이지 참조)를 검사했을 때 마운트된 컨텍스트가 의심스러운 것으로 나타났습니다. 이 시점에서 나는 문제가 시작되기 직전에 마운트 파일 컨텍스트를 변경하라는 SELinux 경고 브라우저의 첫 번째 제안을 실수로 따랐다는 것을 깨달았습니다. 시스템을 복구하고 다시 시작한 후에도 동일한 조언이 표시되므로 아래 스크린샷을 첨부하겠습니다.
SELinux가 문제의 원인일 수 있음을 지적하고 도움을 준 @sourcejedi에게 감사드립니다!