((K) 우분투 12.04, 커널 3.2.0-38-일반, fstype ext3)
나는 최근에 다른 OS를 부팅할 때 최대 절전 모드를 사용하여 기본 OS의 상태를 저장하는 "좋은 아이디어"를 발견했습니다. 나는 지난 몇 주 동안 아무 문제 없이 이 일을 해왔습니다. 저번에 운이 다 떨어졌어요...
최대 절전 모드에서 메인 OS를 다시 시작하고 하루 종일 사용한 다음(파일을 저장할 수 없다는 등 몇 가지 경고 신호를 놓쳤음) 루트 파일 시스템이 읽기 전용으로 마운트되었음을 깨달았습니다. 재설치를 시도했지만 성공하지 못했습니다. fsck를 실행했습니다. 그런 다음 재부팅했습니다. 대부분의 일이 정상으로 돌아온 것 같지만(저장되지 않은 작업(으음/별거 아님) 및 Firefox 문제 제외) 분명히 반복하고 싶지는 않습니다. Dmesg 및 /var/log/ 로그는 무슨 일이 일어나고 있는지에 대해 (내 생각에는) 명확한 정보를 제공하지 않습니다. fsck의 출력을 저장할 생각은 없었습니다.
상황을 좀 이상하게 만들기 위해 실제로 메인 OS(및 스왑/최대 절전 모드 파티션) 드라이브를 물리적으로 제거했습니다. 제가 사용하고 있는 보조 운영 체제는 "실시간" 운영 체제입니다. 따라서 보조 파티션은 문제가 있는 파티션(또는 최대 절전 모드 이미지)에 직접 액세스할 수 없습니다.
따라서 주요 질문은 이것이 원인이 무엇인지입니다.
// // //
편집하다:명확히 하자면, 위의 내용은 질문이고 다음은 단지 내 추측일 뿐입니다. 의견에 따르면 RTC 문제는 붉은 청어일 수 있습니다. 이는 단지 추측일 뿐입니다.
무슨 일이 일어났는지에 대한 최선의 추측은 아마도 라이브 OS가 내 시스템 시계를 변경한 다음 내 메인/루트 ext3 fs를 엉망으로 만들어서(.. 타임스탬프 때문에?) 오류가 발생하여 ro로 다시 마운트하게 되었다는 것입니다. (루트 파티션은 일반적으로 "errors=remount-ro" 옵션을 사용하여 마운트됩니다). 즉, 사용자 수준에서는 데스크탑 시계에 오류/변경 사항이 없습니다. 나는 "문제가 있는 이력서" 직후에 더 정확한(또는 근본적인) 확인을 기대하지 않았습니다. 그래도 이것이 두 번째 수준에서 무언가를 깨뜨리기 위해 내가 생각할 수 있는 유일한 방법입니다메인에 접근할 수 없습니다.
fsck를 실행한지 꽤 된 것 같은데 왜 나타나는지 모르겠습니다. 하지만 내 생각엔 그것은 아마도 "크로스 드라이브 마법"을 포함하지 않는 설명일 것이고, 내 최대 절전 모드 폭식과는 아무 관련도 없는 설명일 것입니다.
따라서 주요 질문은 이것이 원인이 무엇인지입니다.
기타 질문(해당하는 경우): RTC가 합리적인가요? BIOS에서 RTC와 관련된 옵션("쓰기 방지"?)을 볼 수 있다고 확신합니다. 이것이 표준/일관적인 것입니까? (또는 일부 시스템은 RTC 조작으로부터 보호하지 못합니까?)
고려해야 할 다른 비휘발성 스토리지는 무엇입니까(있는 경우)?
(특히 마지막 질문은 별도의 질문이 필요할 수도 있다고 생각합니다.)