업데이트 도중 시스템을 강제 종료했을 때 이 문제가 발생했습니다. 그 후에는 grub의 부팅 매개변수를 "ro"에서 "rw"로 변경해야만 부팅할 수 있었습니다. 그런 다음 부팅할 때마다 fsck를 실행하면 다음과 같은 출력이 표시됩니다.
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
파일 시스템을 복구하려면 어떻게 해야 합니까?
답변1
UEFI가 있는 시스템이 있을 수 있으며 오류 메시지는 ESP(EFI 시스템 파티션)의 FAT32 파일 시스템에 있는 "더티 비트"와 관련이 있습니다. 이 파티션은 일반적으로 로 마운트되지만 일부 배포판에서는 커널 및/또는 부트로더가 실제로 업데이트되지 않는 한 /boot/efi이를 다른 위치(아마도)에 마운트하거나 완전히 마운트 해제합니다./boot
더티 비트 fsck.vfat(FAT32 파일 시스템에서도 사용됨)를 재설정하면 확실히 효과가 있습니다. 그러나 일부 버전에는 변경 사항을 파일 시스템에 실제로 기록하는 옵션이 필요합니다. fsck.vfat특정 버전에 적용되는 자세한 내용은 매뉴얼 페이지를 확인하세요 .
간단히 ESP 파일 시스템을 마운트 해제하고 확인할 수 있습니다. 설치 중에 FAT32 파일 시스템을 확인하지 마십시오. 그렇지 않으면 파일 시스템에 액세스할 때 커널의 파일 시스템 드라이버가 "더티 비트"를 다시 덮어씁니다.
시작 매개변수를 에서 로 변경하면 ro시스템 rw의 또 다른 문제가 숨겨질 수 있습니다. 확인할 다른 파일 시스템이 있을 수 있습니다. 어쩌면 루트 파일 시스템일까요?
시작 프로세스가 중단되고 텍스트 모드 명령 프롬프트가 표시되는 경우정확하게일반 유틸리티가 아직 쓰기를 허용하지 않는 루트 파티션에서 파일 시스템 검사를 실행할 수 있습니다. 이는 다른 미디어에서 시스템을 먼저 부팅하지 않고 루트 파티션에서 파일 시스템 검사를 실행하는 유일한 방법인 경우가 많습니다.
루트 파일 시스템에서 검사를 실행하고 파일 시스템을 변경한 경우 검사가 완료되자마자 재부팅해야 합니다. 커널에는 변경 전에 읽은 일부 블록이 여전히 메모리에 캐시되어 있을 수 있으며 루트 파일 시스템이 재부팅 없이 쓰기 가능한 것으로 다시 마운트되면 해당 블록(및 그 안의 오류)이 즉시 제거될 수 있습니다. 디스크에 다시 쓸 수 있습니다.
답변2
RHEL 7의 경우 다음을 수행했습니다.
디스크를 나열합니다.
df -h
또는
lsblk
복구할 디스크를 마운트 해제하려면(아래 예에서는 /dev/sda1):
umount /dev/sda1
더티 비트를 지우고 디스크를 복구하려면:
fsck /dev/sda1 -a -w
참고: 위 명령은 fsck.vfat이며, fat에 적합합니다. 파일 시스템에 따라 다른 버전의 fsck가 실행되고 다른 매개변수가 필요할 수 있는 것 같습니다. fsck.vfat에서 -a는 자동 복구를 위한 것이고 -w는 변경 사항을 즉시 쓰기 위한 것입니다.
디스크를 다시 마운트합니다.
mount /dev/sda1
시스템을 다시 시작합니다.
systemctl reboot
그렇지 않으면
reboot