'fstab'에 해당되는 글 2건

  1. 2014.05.25 Windows7 설치후 리눅스에서 ExFat인식 문제 해결방법 (2)
  2. 2012.05.25 삭제된 파일 파일 복구기 (4)

Windows7 설치후 리눅스에서 ExFat인식 문제 해결방법

외장하드에 Windows7을 설치 (http://snoopybox.co.kr/1362)를 한 이후에 이상증세가 나타나서 포스팅.


(결론부터 말해서, 이 이상 증상이 뭔가 하면.. 일반디스크(외장 디스크 말고요)의 exfat이 리눅스에서 마운트가 안된다는 사실입니다.


윈도우에서 직접 exfat의 드라이브가 페이지를 사용하지 않도록 설정 해야 합니다. 그래야 리눅스에서 exfat을 사용할수 있어요.)


다음은 삽질기-


systemd에서 에러먹고 이머전시 모드로 넘어가길래, 처음에는 '이놈의 아치리눅스 또 이짓거리 시작하는구나' 싶었는데 패키지 문제인줄 알았답니다.


여튼 보라는데로 로그를 봤는데 "/bin/plymouth not found" 비슷한 오류를 내면서 뻗어버리길래, 실제로 해당 경로에 그 파일이 없는겁니다...


그래서 이 패키지를 설치하면 되겠거니... 했지만 설마해서 구글링을 좀 해보니까,


"ㄴㄴ 그 메세지는 상관없음. 마운트에 문제가 있으면 그럼. 그러니깐 님 /etc/fstab이나 까보셈" 이라는 bbs 답변이 올라온것을 찾아내고,


fstab을 찾아서 이것저것 막아가며 리부트 몇번 해 보니까 exfat만 마운트 안하게 해놓으니깐 또 잘 돌아가네여. 그래서 여기서 촉이 왔죠.


"아 내가 방금 깐 윈도우가 원인이구나"


그리고 리눅스에서 혹시모르니까 수동으로 마운트 해봤는데, 그래도 실패. 대신 뜻있는 에러 메세지를 얻었네요.


에러메세지가 정확이 무엇인지는 기억나지 않습니다만, 대충 "pagefile.sys크기가 0이 아니네? 에러. 나 파업할거야." 뭐 이런 내용이였지요.


그래서 윈도우로 부팅한다음, (숨김파일을 해제해야 보입니다... 나쁜 윈도우...) exfat드라이브를 확인해 보니, pagefile.sys가 딱!


그래서


'제어판 → 시스템 및 보안 → 시스템 → 고급시스템 설정' '시스템속성' 에서 '고급'탭 선택


'성능'의 '설정'버튼을 눌러서 '성능옵션'을 띄운다음 '고급'탭의 '가상메모리'의 변경 버튼을 누릅니다.


만약, "모든 드라이브에 대한 페이징 파일 크기 자동 관리'가 체크되었다면 해제하고,


바로 아래의 리스트에서 ExFat 드라이브를 선택한후, "페이징 파일 없음"을 선택하고 옆에 "설정"을 꼭 눌러 주세요. 그리고 확인.


(그냥 바로 확인 버튼을 누르면 적용되지 않습니다! "설정"을 누르고 확인을 눌러야 해요! 주의!! )


그다음 재부팅해서 리눅스로 들어간다음 일단 ctrl+d눌러서 쉘로 빠져서 $systemctl default 해주면 이제 에러를 안보여주는 systemd를 볼수 있어요.



ps; 근데 windows8은 이런 증상 작동 안하드만. windows7은 이러네여. 신기해라... 여튼 리눅스 유저로써는 참으로 짜증나는 짓거리임에 틀림없어요 이거...



신고
trackback 0 Comment 2

삭제된 파일 파일 복구기

이틀전에 명령어를 잘못쳐서(...) 파일 몇십개가 날라간 이유로. 간단한?  자세한 복구기를 남겨둡니다.


혹시 나중에나마, 누군가 ext에서 파일복구를 할 사람이 있을떄, 조금이라도 참고가 가능하게요.


자 그럼 시작 하겠습니다.


1, 맨탈 붕괴의 시작, 잘못된 명령어 수행


들어가기 전에,,, 제 alias는 이렇게 설정되어 있었습니다...

alias rm='~/bin/script/remove.sh'

alias rrm='/bin/rm -r'


문제는 이 명령을 /tmp에서 써야하는데, 홈에서 써버렸어...

rrm ./*


그래서 홈디렉토리의 파일의 일부가 날아갔습니다...


실수로 삭제 방지한다고 alias까지 만들어놨는데 왜 전 그거 안쓰고 그냥 지웠을까요


etc디렉토리는 복구가 되어있어서 다행이였는데,


문제는 작성한 스크립트를 잔뜩 박아둔 bin디렉토리의 스크립트의 대부분이 날라갔다는 사실입니다 ㅠㅠ..


그 뒤로는.... 다들 그러시겠습니다만, 맨붕....


2, 복구 part1 - 급한대로 일단 막고...아치에서 복구 시도!

 

이후에 실수로 한번 재부팅을 해버렸습니다 ㅠ..


그래서 그런지 이후에 debugfs로 복구하려니까 안되더군요... 삭제파일 리스트가 안떠!!!

(그전에 ext4는  debugfs로 복구하기 어렵다는 말도 들은거 같아서 조금이라도 위안이 되었죠!!!)


바로 복구를 했어야 하는데... 뭐 안타깝지만. 


fstab에서 홈 디렉토리를 마운트 못하게 수정하고

 # /dev/sda3                       /home                   ext4    defaults                    0           2


늦기전에 dd로 일단 홈파티션을 이미지를 떴습니다.

(root로 dd를 쓸때는 항상 조심합니다... 복구하려다 있는것도 다 털릴수 있음...)

#dd if=/dev/sda3 of=/data/exData/2012_05_Home.img bs=100M  #저 같은경우는 sda3니까 이렇게 했습니다. 조심!


휴 이미지 용량만 30기가네요 에휴....


혹시 테이블에 정보가 남아있을지도 모르니까... 시도는 해보죠! extundelete로 복구 시도,

#pacman -S extundelete


간략히 사용법을 적어두자면, 다음과 같습니다.

#extundelete 'target device' option

(예>

#extundelete /dev/sda3 --restore-all

#extundelete /dev/sda3 --restore-file /lowid/.bashrc # path는 '/'기준이 아니라, 대상장치의 절대경로 입니다!

#extundelete /dev/sda3 --restore-directory /lowid/bin )


--restore-ino : 아이노드로 찾습니다... 고급옵션(?)입니다... 저같은 경우 복잡해서 그냥 관뒀음.

--resotre-all  : 장치 전체에서 파일을 복구해 냅니다. 당근 시간이 오래 걸립니다.

--resotre-file 'path' : 파일경로를 정확하게 알고 계신경우라면, 이 방법이 제일 낫겠죠?

--resotre-directory 'path'  : 역시나 이 방법이 가장 무난하긴 합니다. 큰 디렉토리만 아니라면요.


뻔한 이야기지만, 더 자세한건 man페이지를 보세요... 뭐 어지간한 경우, 위 옵션으로 아마 해결이 가능하겠지만.


아치에서 해보니까, --resotore-all은 복구가 하나도 안되고,

 

뒤에 --resotre-file, --resotore-directory로 하니깐 libext2인가.. 갸가 segmentaion fault먹고 죽어버렸어요 ㅠㅠ..


에잇 망했다... 이러고 일단 다른툴을 찾아서 해 보기로 했습니다.

 

이번엔 photorec을 이용해 보죠.

(설치법이야 구태여 적을 필요 없겠죠? 배포판 마다 다르기도 하고, 아치에서 하는건 쉽기도 하니까)


얘도 사용하기 쉽습니다.. 걍 엔터 엔터 하면 되요...


그래도 모르니까. 일단 스크린샷 첨부해서 설명하죠

처음에 딱 하고 뜨는 화면입니다. 원하는 "디스크"를 선택해 주세요...



자! 이제 해당 디스크의 "파티션"을 보여줍니다. 복구를 원하는 파티션을 선택 해 주세요!

sdXY 형식이 아니기 때문에 불편하긴 하지만... 순서와 용량으로 대충 어림짐작(...)이 가능합니다.


선택한 "디스크"의 "파티션"을 선택해 줍니다.

저야 ext4니까  "ext2/ext3"를 선택하겠습니다. 뭐 어지간한 리눅스에는 다 ext파티션이니까...



이제 복구 타입을 설정할때 입니다. "전체다" 복구하려면 "whole" 그게 아니라 선택적 복구를 하려면 "Free"를 선택합니다.

...라고 하는게 정석이긴 한데, 전 ext4라서 그런가... free를 눌러도 그냥 전체다 복구 하더라고요...


복구된 파일이 저장될 위치를 지정해 줍니다. 용량여유가 있는 경로를 선택하시길 추천합니다.

(제가 30긱 하드를 복구했는데... 복구된 파일 전체 크기가 한 2긱되던거 같습니다.)

 

이후, 복구되는 과정이 시작됩니다.

 

photorec는 일단 복구하는 파일의 결과를 실시간으로 보여주는게 마음에 들더군요. *.txt 몇개, *.torrent 몇개... 이런식 입니다.

ps; 중간에 파일 디스크 타입? 파티션 타입? 인가... 설정하라고 나올떄도 있는데, 이때는 중간에 Linux를 선택 하시면 될겁니다.


음... 복구 다 하고 나서, 복구완료된 파일을 보았는데...

 

제가 필요한건 "수천개 중에" "1개" 복구가 되더군요 아놔...


(지운지 오래된 파일들만 왕창 복구해 내네요;; 쓸데없는 torrent파일, 야짤, 로그파일 이딴거나...)

결과적으로 그런거죠 "실패했다"


그리고 이어지는 2차 멘붕.


3, 아까 segmentaion fault가 원인일거야! 아치에서 안되면 우분투에서 해보자!!!


옜날 생각도 났겠다... 오랬만에 붕투체험도 해볼겸해서, 12.04(05인가;;) 시디를 굽고 라이브CD로 함들어가 봤습니다.


이야 ODD라 그런지, 원래 무거운건지... 속도 무지하게 느리군요..버버버버벜 아 이거 내 타입 아냐!!


그런 우여곡절을 겪은 이후, 바탕화면에 입성!!!

이미지 출저: http://commons.wikimedia.org/wiki/Image:Ubuntu_12.04.png?uselang=ko


아 근데 이거 "유니티"인가 적응 진짜 안되네요? 적어도 제가 쓰기에는 진짜 불편한 인터페이스...


아무리 생각해도 이런건 아니에요.. 컴퓨터가 무슨 아이패드나 넷북도 아니고...


터미널은 어디 쳐박혔는지 찾을수도 없고!!! 시냅틱도 어디 쳐박혀 있는지 찾을수 없고!!!


(알고보니 터미널은 오른쪽 가젯(?)의 "우분투마크"를 클릭해서 "검색"해서 실행해야 하더군요


야! 아무리 그래도 터미널은 사용하기 쉽게 해 놔야하는거 아니냐!!! *nix의 생명은 터미널이란 말이다!!!! )


시냅틱도 찾고찾다 안되서 저기 오른쪽 가젯의 "쇼핑백" 클릭해서 시냅틱 깔았습니다... 이후에 exundelete, photorec도 설치완료.


서문이 너무 길었네요.. 이제 복구 시작...


저같은경우 extundelete로 복구시도를 다시 해봤는데 결과는 마찬가지더군요. 혹시해서 아까 --restore-directory 옵션으로


시도도 해봤는데, segmentation fault 먹지 않는다는 사실만 제외하면 똑같았습니다.. 네.. 복구가 안되었다는거죠.. 하나도...


photorec의 경우 복구하다가 시스템이 맛탱이가 가버렸습니다.. 뭐 별수 있습니까? 걍제종료 해야지...


후... 뭔가요 이번 파트는... 그냥 우분투 체험하러 들어돈것 밖에 안되는듯.. 결론은 모두 실패.


3차 멘붕.


4, 수동복구...


아까 이미지 뜬파일을 통해서 수동으로 복구를 시도해 보았습니다.


혹시해서 winhex로 이미지 뜬걸 열고... 문자열을 검색...

 

 

당연하지만, 삭제된 파일이지만 검색은 되죠...네... 어짜피 위에 테이블(?)만 지워진 상태고 블록은 그대로 일테니...


근데 더 신기한건, 검색된 문자열(plain text)의 앞뒤가 명확하다는겁니다 !!!!!


100%로 맞아 떨어지지는 않았지만, 파일의 시작,끝이 거의 구분이 간다는 거죠. 

 


 

와 진짜로 신난다! 가능성이 있어! 


그리고 옛 기억(?)을 더듬어서 30긱 이미지에서 일일이 문자열을 검색하기 시작...


나옵니다! 나와! 파일이 파일이~!!! 그래서 일일이 검색하고, 파일 앞뒤를 찾고, 범위를 선택해서 드래그 해서 복원을 했습니다..


일부 파일의 경우 디스크 전체에 한번 밖에 없는경우고 있었지만, 이런경우는 별로 없었고 (....)


파일하나(꼭 그 파일에서만 있음직할만, 즉 진짜 디스크에서 딱 1개 들어가 있다고 확신을 할만한... 그런 문자열 선택...

 

물론 파일이 수십개라 다 정확한 문자열을 정하기 좀 힘듭니다.)검색하면, 대상파일과 비슷한

 

(정확하게 말하면, 제가 대상파일을 편집할때 backup본 만들어 놨던)파일이 수두룩 하게 검색이 됩니다.


보통 10개이상~20개 정도였고, . 특히 편집을 자주한 파일을 보면, 덤프한 파일이 50개가 넘어갔어요.


그래도 별 수 있습니까.... 그 50개 덤프뜬 파일 다시 분석해서 가장 "최근인듯한" 파일 골르는 수밖에...


보통 용량순으로 고르면 되더군요.. 가장 최신인 파일일수록 예외처리를 많이 해 놨을테니까...


(물론 아닌경우도 있어서 캐고생 했습죠 데헷...)


그렇게 하루종일 검색, 덤프, 선택, 과정을 거쳐 복원을 완료 했습니다.


이후 멘탈도 다시 불완전하게 나마 복원이 되었습니다 (...)


일단 복원을 시키긴 했는데, 모든 스크립트가 제대로 작동하는진 좀더 지켜봐야 할거 같네요...


마지막으로 요약하자면.. 수동 복구가 가능했던 이유는...

1. 내가 작성한 파일이라서 내부가 어떻게 되어있는지 대충 알고 있었음.

2, 스크립트 파일이라서 plain text였다.

3, 파일 크기가 거의다 10k 내외였다.

4, 3번때문인지, ext의 특성인진 몰라도, 파일의 단편화가 일어나지 않았다.

(뭐 확실히 FAT,NTFS였다면 클러스터 크기가 작아서 복구가 불가능했을지도요?)

5, 구별이 쉽게 파일의 앞,뒤가 '00'으로 구별되어 있었다.


입니다... 여러분도 삽질 조심하세요 ㅠㅠ.. 나처럼 이러지 말고...




ps; 티스토리, 파이어폭스 콤비가 포스팅 또 날려먹었네요.. 와 신난다!

한 30줄 정도 썼었는데 제길... 자동저장도 안되있네.. 씁...


ps2; 와 또 날려먹었다!!! 이번엔 뒷부분 한 10줄 날아감.. 아 대체 왜이럴까요? 뭐가 문제일까?

 

ps3; 은근히 포스팅 작성하는데 시간 오래걸리네요.. 윈도랑 왔다갔다 하면서 작성해서 그런가;;;

신고
trackback 0 Comment 4
prev 1 next


티스토리 툴바