OS X El Capitan의 Rootless 정책과 Disk Utility에 대하여

이전 글에서 OS X El Capitan Upgrade 후 발생한 문제들에 대해 얘기했는데, 이전 OS X 버전의 Recovery 파티션 두 개를 지워 보려고 하다가 생긴 문제들에 대해서 주로 Disk Utility 사용자 관점에서 정리해 본다. 기본적으로 Disk Utility를 가지고 Recovery 파티션을 지울 수 없었기 때문이다. 이전 글에서도 잠깐 언급했듯이 OS X El Capitan의 새로운 보안 정책인 Rootless(또는 SIP; System Integrity Protection) 때문에 Disk Utility에도 제약이 가해질 수 밖에 없으리란 것은 어느 정도 이해할 수 있지만 본연의 디스크 관리 기능을 제대로 할 수 없다는 것에 대해 왕짜증난다.

Rootless 보안 정책은, 간단히는 root 권한으로도 System의 중요한 설정이나 폴더/파일 들을 건드리지 못한다고 이해하면 되지만, 세부적으로는 매우 복잡한 것 같다. 3rd Party 시스템 관련 앱 개발 회사나 개발자들, 그리고 OS X 서버 사용자들에게는 꽤 부담을 줄 듯하다. 일단, 구글링을 통해 알게된 몇 가지만 정리한다.

Rootless 또는 SIP에 대하여...

Rootless는 com.apple.rootless라는 확장 파일 속성으로 관리하는 것 같고, NVRAM, 프로세스, 폴더, 파일 레벨에서도 통제할 수 있는 듯 하다. 일단, 파일시스템 Protection이 걸려 있는 폴더 들은 /System, /bin, /sbin, /usr(단, /usr/local은 제외) 등 이다. 이 폴더들은 root도 write 권한이 없다. SIP를 관리하는 새로운 Utility가 csrutil이라는 놈이다. OS X Recovery 파티션으로 부팅했을 때에만 SIP를 해제 또는 사용하도록 설정할 수 있다. 다만, 현재 SIP 설정 상태는 언제든지 아래와 같이 터미널에서 확인 할 수 있다.

$ csrutil status

Recovery 파티션으로 부팅해서 Rootless를 해제하고자 한다면 disable, 다시 설정하고자 한다면 enable, 초기 상태(enabled)로 reset하고자 할 때는 clean 옵션을 아래의 예와 같이 주면 된다.

$ csrutil disable

이렇게 Rootless 설정을 바꾸면 재부팅해야 효력이 발생한다고 경고 메시지가 뜬다.

위의 예와 같이 Rootless를 해제하고 OS X로 부팅해서 상태를 확인하면 아래와 같이 뜬다.

$ csrutil status

System Integrity Protection status: disabled.

Configuration:
  Apple Internal: disabled
  Kext Signing: disabled
  Filesystem Protections: disabled
  Debugging Restrictions: disabled
  DTrace Restrictions: disabled
  NVRAM Protections: disabled

위의 각 disabled 된 놈들을 개별적으로 활성화할 수도 있는데, 잘 모르고 사용하면 위험하니까 모르는게 낫겠다 싶다.

Disk Utility의 문제 들

우선, Disk Utility UI가 완전히 바뀌었는데 뭐 Apple 입장에서는 나름 사용자가 쉽게 사용할 수 있도록 바꾸었단다. 파티션을 Pie Chart 모양으로 보여 주는데 보기는 좋으나 마우스 클릭할 공간이 줄어 들었다. GPT 파티션이 기본적으로 128개까지 파티션을 사용할 수 있는데 파티션 수를 20개 이상 사용하는 사용자가 있다면 왕짜증 곱배기가 될 것이다.

기능적으로도 아예 삭제된 기능들이 있는데, Rootless를 도입하면서 삭제된 권한 복구(permissions repair) 기능 외에도, DVD나 RAID 지원 기능이 아예 사라졌다. 사라진 기능들로 인한 불만도 가득하더라.

내가 Disk Utility를 사용하면서 왕짜증나는 문제 들은 또 다른 것들이다. 그것은 본연의 디스크 관리를 할 수 있는 방법이 없다는 것이다.

기본적으로, 전체 파티션을 볼 수 있는 방법이 없다. 물론, 내가 El Capitan에 아직 적응이 안돼서 못찾은 것일 수도 있지만 기존의 방법들이 무용지물이다. 즉, 아래의 터미널 명령으로 Disk Utiltity에서 Debug 메뉴가 생겨서 Hidden Partition까지도 볼 수 있었는데 El Capitan에서는 UI가 바뀌면서 사라진 듯 하다. 기본적으로 보이지 않는 파티션은 ESP(EFI System Partition)와 OS X Recovery Partition이다.

$ defaults write com.apple.DiskUtility DUDebugMenuEnabled 1

위의 화면에서 오른 쪽 Bar Chart를 보면 다른 OS 파티션들이 같이 포함되어 있다. 얼핏 보면 모든 파티션이 다 보이는 듯 하지만 ESP나 Recovery Partition은 아예 없다. 위 쪽의 Partition 명령을 Click하면 Pie Chart가 나타나는데 여기서도 당연히 나타나지 않는다. 참고로, 두 번째와 세 번째 untitled로 표시된 650MB 파티션 두 개는 이전 버전의 OS X Recovery Partiton인데 Mac 부팅시에 안보이도록 gdisk로 파티션 type을 임의로 설정한 것이다. El Capitan의 Recovery Partition이 Mac OS X 파티션 다음에 보여야 하는데 안보이고 맨 첫번째의 ESP 파티션도 안보인다. gdisk에서 Mac OS X 파티션 type은 Apple HFS/HFS+(AF00)이고, OS X Recovery 파티션 type은 Apple boot(AB00)이다. 실제로 3개의 복구 파티션 tyoe code를 gdisk에서 AB00으로 바꾸면 새로운 Disk Utility에서는 3개 파티션이 모두 사라진다. 대신 3개 버전의 OS X Recovery 모드로 각각 부팅할 수는 있다.

그리고, 더 큰 문제는 파티션을 삭제하려면 왼쪽의 Tree 메뉴를 사용해야 하는데 여기에는 기본 OS X 파티션과 Windows 파티션 밖에 보이지 않는다. 리눅스 파티션을 Disk Utility로 지우지 못할 이유가 무엇일까? 이것도 강화된 보안 정책의 일환인가? Windows는 만만해서 파티션을 지울 수 있는 건가? 또한, ESP와 OS X Recovery Partition은 Disk Utility에서 아예 안보이니까 당연히 삭제는 물론이고 아무 것도 할 수 없다.

또 한 가지 문제는 불필요한 Recovery Partition을 삭제하면서 알게된 문제인데 위의 Hidden Partition이 보이지 않음으로 인해 파생되는 문제이다. OS X Upgrade시에 Mac OS X 파티션을 끝에서부터 650MB 정도를 잘라서  Recovery Partition을 새로 추가한다. 나처럼 Mac OS X 파티션이 넉넉하고 3번 Upgrade했다면 3개의 Recovery Partition이 추가된다. 가장 최근에 추가된 놈이 Mac OS X 파티션 바로 옆에 위치하게 된다. 나머지 두 개는 지워도 되는 놈인데 Mac OS X 파티션과 합칠 수는 없다. 중간에 최신 Recovery 파티션이 위치하고 있기 때문이다. 방법은 모든 Recovery 파티션을 삭제하고 새로 최신 Recovery 파티션을 생성해야 하는데 El Capitan에서 가능한지는 더 조사해 보아야 한다. 아무튼, 문제점을 설명하려고 좀 장황해 졌는데, 우분투에서 gdisk를 이용해서 두 개의 Recovery 파티션을 삭제하고 다시 OS X에서 Disk Utility의 Partition 메뉴에서 [-]로 두 개의 빈 파티션을 삭제해 보았다. 중간에 최신의 Recovery 파티션이 El Capitan의 Disk Utility에서 보이지 않음으로 인해 Mac OS X 파티션에 두 개의 파티션이 제대로 합쳐진 것(merge)처럼 보인다. 실제로는 두 개의 파티션이 최신 Recovery 파티션에 합쳐져 있었다.

이 밖에도, OS X Upgrade 시에 OS X 데이터 파티션의 파일 시스템 타입이 hfs인데도 인식하지 못하고 Microsoft Basic Partition으로 바꿔 버린 것과, Rootless를 한번 해제하기 전에는 Disk Utility에서 보여주는 전체 파티션이 Recovery Mode로 부팅했을 때와 OS X로 부팅했을 때 차이가 생겼던 문제도 있었다.

맺음말

OS X El Capitan의 Disk Utility는 여러가지 기능이 삭제되어 불편할 뿐만 아니라, 본연의 디스크 관리 기능을 모두 수행할 수도 없고, 사용자가 의도한 대로 동작하지 않을 수도 있다는 점을 알아 둘 필요가 있겠다.

El Capitan에서 강화된 보안 정책인 Rootless에 대해서도, OS X 고급 사용자나  관리자 입장에서는 어차피 Recovery Mode에서는 모든 root 권한을 여전히 사용할 수 있다는 점에서, 근본적으로 필요한 것이었는지 의구심이 든다. 보안 강화라는 명목으로 3rd Party들을 Apple이 통제하려는 의도일 수도 있다는 생각이 든다.

Apple이 System Integrity에는 그렇게 신경을 쓰면서 Application Integrity에는 소홀해진 느낌~!!!

OS X El Capitan 설치 후 Ubuntu Grub 복구

새로운 OS가 나오면 무작정 설치하는 안좋은 습관이 있다. 이로 인해 발생하는 문제들도 참 다양하다. 남들보다 먼저 문제를 겪으면 구글링해도 답을 찾기 어려운 경우가 많다. 아무튼 Mac OS X El Capitan Upgrade가 떴길래 걍 설치했다. 우분투로 부팅이 안되는 경우는 이번이 처음은 아니다.

El Capitan Upgrade 후 발생한 문제들

<Option> Key를 눌렀을때 Grub으로 부팅할 수 있도록 해 놓은 것이 작동 안하는 것은 그러려니 한다. 그런데, 하드디스크의 Grub은 물론이고, 전에 만들어 놓은 우분투 설치 USB로도 부팅이 안된다. Windows 10과 새로운 OS X 10.11로만 부팅이 된다. 또, 한가지 문제가 더 생겼는데 OS X 데이터 파티션이 안잡힌다. OS X의 터미널에서 파티션을 확인해 보니 파티션들은 잘 있다.

$ diskutil list

그런데, 가만히 보니 OS X Recovery 파티션이 하나 더 생겼다. 이전 복구 파티션들을 안지웠더니 Recovery 파티션만 3개가 되었다. 문제는 리눅스 파티션이 뒤쪽에 있기 때문에 복구 파티션 하나가 새로 생김으로 인해 파티션 번호가 하나씩 밀려 버린다는 것이다. 당장 예상되는 문제가 Grub 메뉴엔트리의 파티션 번호가 달라지기 때문에 Grub이 당연히 동작하지 않으리란 것이다. 예전에는 리눅스의 /etc/fstab에서도 파티션 번호를 사용했었는데 요즘은 각 디바이스 파티션의 UUID를 사용하기 때문에 리눅스 파일시스템이 mount 되지 않는 문제는 없다.

구세주 rEFInd Boot Manager

아무튼 이 모든 문제를 해결하기 위해서는 어떻게든 우분투로 부팅할 수 있어야 한다. OS X를 새로 Upgrade하면 보통은 rEFInd를 새로 설치해 주면 우분투로 부팅할 수 있다. 그런데, El Capitan에서는 Rootless Mode 라는 새로운 보안 정책이 추가되면서 rEFInd를 설치해도 부트 엔트리에 rEFInd가 추가되지 않는 듯 하다. Rootless Mode라는 것이 얼핏 구글링 한 바로는 root 권한으로도 맘대로 시스템 파일들을 건드리지 못하도록 한단다. OS X Recovery 파티션으로 부팅해서 해제하면 된다는데 아직 모르는 게 많아서 꺼려진다. 쉬운 방법을 선택하기로 했다. rEFInd를 기본 boot loader로 만들어 버리는 것이다.

참고로, rEFInd는 OS가 부팅하기 이전에 부팅하므로 OS dependency가 없다. 어떤 OS 환경이든지 binary 파일들이 같다는 얘기다. 다만, rEFInd 0.8.4 미만 버전의 경우 OS X에서 설치하면 기본 설치 위치가 OS X 파티션이었는데 이후의 버전들은 OS에 상관없이 ESP(EFI System Partition) 파티션에 설치된다. OS X Yosemite 이후 OS X 파티션에서는 rEFInd로 부팅할 수 없단다. 또 한가지 참고할 사항은  rEFInd를 만든 이가 바로 gdisk의 저자라는 것이다.

아래와 같이 ESP를 마운트 한 후, 기본 boot loader인 bootx64.efi 파일을 refind_x64.efi로써 대체한다. 당연히 rEFInd가 설치되어 있어야 한다.

$ sudo mkdir /mnt
$ sudo mount -t msdos /dev/disk0s1 /mnt
$ cd /mnt/EFI/Boot
$ cp -f ../refind/refind_x64.efi ./bootx64.efi

이제 OS X를 재부팅 한 후 <Option> Key를 누르고 있으면 EFI 부트 엔트리가 보이는데 이 놈을 선택하면 rEFInd가 뜨고 다시 부트 엔트리들이 나타난다. 여기서 grubx64.efi를 선택해 봐야 파티션 넘버가 달라져서 우분투로 부팅할 수 없다. rEFInd는 계속 Upgrade되고 있는데 최신 버전에서는 리눅스 커널로 바로 부팅할 수가 있다. 커널로 부팅하려면 rEFInd 부트 엔트리 중에서 다시 rEFInd를 선택하면 된다. 이렇게 두 번 선택하는 이유는 처음에는 기본 부트로더가 된 rEFInd로 부팅한 것이지만 설정 파일(refind.conf)을 읽지 못하기 때문에 ESP 파티션의 boot loader들만 보여주기 때문이다.

최근에 사용했던 리눅스 커널을 선택하니 우분투로 깔끔하게 부팅이 된다.

Ubuntu에서 Grub 복구

우분투로 정상 부팅했으니 아래의 명령만으로도 Grub이 복구될 줄 알았다.

$ sudo update-grub
$ sudo reboot

위의 명령으로 최소한 /boot/grub/grub.cfg의 부트 엔트리들에 있는 파티션 넘버는 교정이 된다. 그런데, 우분투로 부팅이 안된다. 아래와 같이 오류 발생...

Error: unknown filesystem.
grub rescue>

----------------------------------------------------------------------------------------------------------------
참고: grub rescue> 모드에서 우분투로 부팅하기

아래와 같이 grub rescue 모드에서 우분투의 boot 파티션을 알아 낼 수 있다.

grub rescue> ls
(hd0) (hd1) (hd1,gpt1) (hd1,gpt2) ......

grub rescue> ls (hd1,gpt9)/
/boot ......

위와 같이 /boot 폴더가 보이는 파티션이 리눅스 boot 파티션이다. 이제 아래와 같이 하면 Grub으로 부팅할 수 있다.

grub rescue> set prefix='(hd1,gpt9)/boot/grub'
grub rescue> insmod normal
grub rescue> normal
----------------------------------------------------------------------------------------------------------------

이렇게 해서 Grub으로 부팅한 후,

$ sudo apt-get install --reinstall grub-efi
$ sudo update-grub
$ sudo reboot

다시 부팅했으나 역시 매한가지다. grub rescue>....

grub-efi 패키지를 재설치해도 해결이 안되는 걸 보니 혹시 무슨 cache 파일같은 찌꺼기 때문일지도 모른다는 생각이 들어서 우분투로 재부팅한 후,

$ sudo apt-get install grub

하니, grub-efi 패키지를 지우고 db를 갱신하겠냐고 물어본다. 패키지만 설치된 상태에서 Ctrl-c로 빠져 나왔다. 그리고 다시 grub-efi 패키지 설치...

$ sudo apt-get install grub-efi
$ sudo reboot

이렇게 하니까 예전의 우분투 Grub으로 완전히 복구되었다.

그런데, 돌이켜 보면 이전에 정리했던 UEFI Grub 복구 절차만 충실히 따라 했어도 복구되었을지 모른다는 생각이 든다. 위의 내용과 비교해서 빠진 부분이 grub-install 명령 실행 부분인데 이 명령을 사용하지 않았던 이유는 "efibootmgr -v" 명령으로 확인시 우분투 boot entry가 멀쩡히 살아 있었기 때문이다. grub-efi 패키지를 새로 설치하면 grub-install 명령이 자동으로 수행된다. grub-install 명령이 NVRAM에 우분투 boot entry를 등록해 주는 일 외에 파티션 변경에 따른 설정을 추가로 해줄 수도 있기 때문이다.

OS X 데이터 파티션 복구

이제 우분투가 정상이 되었으니 나머지 문제들은 쉽게 처리할 수 있다. OS X 데이터 파티션은 gdisk에서 확인해 보니 Microsoft Basic Data(0700) 파티션으로 파티션 코드가 설정되어 있었다. 이 놈은 Apple HFS/HFS+(AF00) 이었던 놈이다. 코드를 바꿔주고 OS X로 재부팅했더니 데이터 파티션이 제대로 복구되었다.

gdisk에 대한 다른 글 들에서 언급한 바 있지만 서로 다른 OS의 파티션 Tool들을 혼용해서 사용할 경우에는 반드시 gdisk로 파티션 테이블에 변화가 생겼는지 확인해 볼 필요가 있다. Recovery 파티션을 OS X Upgrade시 추가하면서 파티션에 변화가 생긴 것인데 OS X 파티션 조차 몰라 보다니... :-(

각종 부팅 설정 원상 복구

일단 rEFInd도 최신 버전으로 재설치했고, Mac 부팅시 <Option> Key를 눌렀을 때 Grub이 뜨도록 다시 설정하였다. 그리고 부팅 순서도 우분투 Grub으로 먼저 부팅하도록 efibootmgr로 재설정 하였다.

남은 일

우분투 설치 USB로 왜 부팅이 안되는지 알아 볼 필요가 있고, 불필요한 OS X Recovery 파티션도 제거해야 겠다.

(2015/10/06 Update)

우분투 설치 USB로 부팅이 안됐던 이유는 USB에서 gdisk로 Hybrid MBR 파티션을 만들면서 EFI Protective Partition(0xEE)의 위치를 맨 앞이 아니라, 맨 뒤로 바꿨기 때문이었다. 이 상태에서는 Hybrid MBR 파티션 들 중 첫번째 FAT 파일시스템을 ESP로 인식해 버리더라. 이전 우분투 설치 USB 만들기 방법에 문제가 있었던 것은 아니었다.

Grub이 이상해졌네...

그런데, 우분투 15.04 설치 후 Grub이 몇번 update 됐는데 그 때문인지 아니면 El Capitan Upgrade 후에 뭔가 바뀐 것인지 잘 모르겠는데, /dev/sda인 하드디스크를 Grub에서 hd0가 아니라 hd1으로 인식하고 있더라... USB를 꽂은 채로 Grub 부팅시 다시 확인해 보면 USB는 hd0로 인식하고, 하드디스크는 hd2로 인식한다. 그런데, /boot/grub/grub.cfg 파일의 부트 메뉴엔트리에는 하드디스크 hint가 hd0로 되어 있어도 UUID를 먼저 참고하기 때문에 하드디스크로 부팅하는데 문제가 생기지는 않는다. 다만, 하드디스크의 우분투 설치 iso파일로 부팅할 때는 grub.cfg에서 hd0가 hd1으로 바뀌어야만 부팅이 된다. 이 때는 hint가 아니고 정확한 위치를 지정하고 있기 때문이다.

아무튼, Grub이 update 되면서 벌레가 생긴 것인지, 아니면 첫번째 하드디스크를 hd0에서 hd1으로 하기로 한건지, 또는 OS X El Capitan 때문에 발생한 문제인지는 확실하지 않다.

Ubuntu VirtualBox Guest 복구

Virtual Box 4.3.18로 우분투 14.10 게스트 가상 머신을 EFI 모드 + btrfs 파일시스템으로 설치했는데 설치 후 부팅이 안되는 문제가 있었다. 우분투 14.10의 문제인지 버추얼 박스 문제인지는 확실하지 않다. 마침 어제 Virtual Box 4.3.20 update가 떠서 홈페이지 ChangeLog를 봤더니 EFI 수정사항이 있단다. 업그레이드하고 나서 그간 방치했던 우분투 14.10 게스트를 다시 돌려 봤으나 역시 안돌아 간다.

Virtual Box 4.3.20 Upgrade...

그런데, EFI 모드 + btrfs 파일시스템인 우분투 14.04 게스트 가상 머신은 호스트를 우분투 14.10으로 Clean Inastall 하고 나서도 잘 돌아가던 놈이다. Virtual Box Guest를 upgrade하려고 이놈을 부팅했더니 로그인 후 먹통이다. 콘솔 모드로는 로그인이 가능해서 Guest Additions를 설치하려고 했으나 [Device] > [Insert Guest Additions CD Image...] 메뉴를 사용하면 이미 mount 되어 있어서 mount가 안된다고 경고 창만 뜬다. 일단, 콘솔에서 강제로 아래와 같이 설치했다.

$ sudo mount /dev/cdrom /mnt
$ cd /mnt
$ sudo ./VBoxLinuxAdditions.run

$ sudo reboot

Virtual Box Guest에 발생한 문제들

재부팅하고 나니 문제가 더 심각해 져 있었다. EFI System Partition이 마운트가 안돼서 Skip하던지 Manual로 마운트 해 보란다. 놀랍게도 Skip을 하니까 부팅은 된다. 화면 크기 조정도 안되고 투명창 효과도 사라진 걸 보니 Guest Additions가 잘못 설치됐을 거란 생각이 들어 다시 설치하려고 iso 파일을 마운트하려고 했더니 황당한 오류가 발생...

$ sudo mount /dev/cdrom /media/cdrom

mount: unknown filesystem type 'iso9660'

EFI System Partiton을 마운트 하면 아래와 같은 오류 메시지가 나온다.

$ mount -t vfat /dev/sda1 /mnt

mount: wrong fs type, bad option, bad superblock on /dev/sda1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

$ dmesg | tail

[ 1605.267871] FAT-fs (sda1): IO charset iso8859-1 not found

또 다른 문제도 발생했는데 패키지 관리 시스템까지 망가진 것이다. apt-get install -f 하란다.

$ sudo apt-get install -f

....... 
E: Internal Error, No file name for libc6
W: Could not perform immediate configuration on 'multiarch-support:x86_64'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2)
E: Sub-process /usr/bin/dpkg returned an error code (1)

음... 망가져도 이렇게 우분투가 망가지는 걸 본건 처음이다. 기왕 망가진거 우분투 설치 iso 로 부팅해서 복구해 보기로 했다.

우분투 설치 iso로 우분투 게스트 부팅 후 복구

버추얼 박스 Storage에 우분투 14.04.1 iso 이미지를 CD에 지정하고 재부팅한 후 터미널을 띄워서 Grub을 우선 복구했다. 참고로 /dev/sda2가 우분투가 설치된 btrfs 파일시스템이고, /dev/sda1이 EFI System Partition이다.

$ sudo -i

$ mount -o subvol=@ /dev/sda2 /mnt
$ mount -o subvol=@home /dev/sda2 /mnt/home
$ for i in /sys /proc /run /dev; do mount --bind "$i" "/mnt$i"; done

$ chroot /mnt
$ mount /dev/sda1 /boot/efi
$ grub-install /dev/sda
$ update-grub

그 다음은 패키지 관리 시스템을 복구했다. 먼저, 시스템 전체가 망가진것인지 확인하기 위해서 아래 명령이 정상인지 확인한다.

$ /bin/date

결과가 다행히 정상이다. 즉, 패키지 데이터베이스만 깨진 것이다. 패키지 status backup 파일 중 괜찮아 보이는 놈을 사용하기로 했다.

$ mv /var/backups/dpkg/dpkg.status.2.gz /var/lib/dpkg/
$ cd /var/lib/dpkg
$ mv status org-status
$ gunzip ./dpkg.status.2.gz
$ mv dpkg.status.2 status

$ reboot

여기 까지 하고 나서 재부팅해서 apt-get update 했더니 반응이 없다. 저장소 서버를 교체해 줄 필요가 있어 보였다. 소프트웨어 저장소 서버를 KAIST FTP에서 Main 서버로 교체했다.

$ apt-get update
$ apt-get upgrade

교체 후 위 두 명령이 제대로 동작한다. 소프트웨어 upgrade가 동작하는 것을 보니 패키지 관리 시스템은 복구가 된 것이 분명하다.

문제는 앞서의 mount 오류가 여전히 발생하고 있다는 것이다. 그런데 upgrade 목록에서 새 Kernel이 마침 올라와 있어서 혹시나 하고 Kernel을 Uprade 한 후 재부팅 했더니 mount 문제도 해결됐다.

그리고 나서, Virtual Box Guest Additions도 다시 설치하고 재부팅하니 모든 것이 정상으로 돌아왔다.

복구 소감

어디서 부터 문제가 시작된 것인지는 너무 당황하고도 급하게 복구하느라 정확히 알 수 없지만 Virtual Box Upgrade를 앞으로는 좀더 신중하게 할 필요가 있겠다.

우분투 14.10이 EFI 모드에서 안돌아 가는 문제가 해결됐는지는 Virtual Box 14.10 저장소 버전이 나온 후 다시 시도해 볼 필요가 있겠다. EFI 문제인지 EFI + btrfs 파일시스템 문제인지도 확실하지 않다.

Dell 복구 파티션을 이용한 Windows 7 복구

Windows 8.1로 Upgrade 했던 Dell PC가 있는데 Windows 7으로 다운그레이드 해 달라는 가족의 압력에 구글링을 통해 복구에 성공했다. 다시 복구할 일이 생길지 모르니 잊어 버리기 전에 정리한다.

imagex.exe 프로그램 준비

Windows AIK iso 이미지를 내려 받아서 설치하면(Windows 8.1에서) imagex.exe 프로그램이 있는데, 64-bit PC이므로 amd64 폴더에 있는 것을 사용한다. USB나 D: 드라이브에 복사해 놓는다. 다행히 항상 OS와 Data 파티션을 분리해 놓고 있어서 OS 재설치시 Data Backup이 따로 필요하지 않은 게 다행이다.

Windows 7 설치 USB로 부팅해서 Recovery Partition의 이미지 복원

혹시나 Windows 8 파일과 뒤섞이지 않도록 USB로 부팅한 뒤 C: 드라이브를 포맷해 버렸다. <Shift>+<F10>키를 눌러 명령창(Command Prompt)을 연다. USB로 부팅하면 명령창에서는 드라이브 문자가 뒤죽박죽이다. 명령창을 열었을 때 기본 드라이브가 X:, Dell Recovery Partition은 C:, Windows 8이 설치됐던 파티션은 E:, Data 파티션은 D:로 할당되어 있었다.

Dell Recovery Partiton은 파일들이 숨겨져 있어서 "dir /a" 명령으로 폴더를 볼 수 있다. 아래와 같이 한 후 재부팅하면 복구된 Windows 7으로 부팅할 수 있다.

C:\> dir /a 
C:\> cd dell\image
C:\> d:imagex.exe /apply FACTORY.WIM 1 E: /ref FACTORY1.WIM /ref FACTORY2.WIM

위에서 Dell의 복구 이미지 파일이 3개이고, E: 드라이브로 Windows 7을 복구한다는 의미이다.

처음에는 구글링 결과 아래와 같이 해도 되는 줄 알았는데 100%까지 복원이 끝난 후 오류가 발생하였기 때문에 위와 같이 했더니 잘 되더라.

C:\> d:imagex.exe /apply FACTORY.WIM 1 E:

참고로, 이미지 파일의 내용을 보고 싶다면 아래와 같이 하면 된다. imagex 명령의 옵션에 숫자 1이 항상 따라 붙는데 이미지 파일 번호이다.

C:\> d:imagex.exe /dir FACTORY.WIM 1

기타 참고 사항

Windows 7에서는 부팅 후 <F8>키로 부팅 옵션을 선택할 수 있는데 Windows 8+에서는 <F8>키가 작동하지 않는다. Windows 8에서 복구 모드로 진입하려면 <Shift> 키를 누른 상태에서 전원 재시동 버튼을 클릭하면 된다.


참고 사이트

http://bolsiroo.tistory.com/253
http://technet.microsoft.com/en-us/library/cc748966(v=ws.10).aspx

Ubuntu BIOS 및 UEFI Grub 복구

(2015/11/21 최종 수정)

최근에 OS X El Capitan이나 Windows 10 (Build 10586.11)으로 Upgrade를 해 보니 OS 별로 Upgrade 할 때마다 자체 복구 파티션을 OS 파티션 끝에 추가하면서 파티션 수가 자동으로 늘어나는 일이 자주 생긴다. 이러면 우분투 파티션 번호가 밀려 버려서 Grub으로 부팅이 안되고 grub rescue> 모드로 진입해 버린다. 물론, 복구 파티션이 추가되는 경우는 OS 파티션을 매우 넉넉하게 잡았을 경우에만 발생하므로 모든 사용자가 경험하게 되는 일은 아니다.

아무튼 grub rescue> 모드로 진입시에 Grub을 복구하는 방법을 추가한다. 우분투 설치 USB를 사용할 필요가 없으니 아래의 방법들을 사용하기 전에 먼저 사용해 볼만한 방법이다.

Grub rescue> 모드를 이용한 Grub 복구 방법

아래와 같이 grub rescue 모드에서 우분투의 boot 파티션을 알아 낼 수 있다.

grub rescue> ls
(hd0) (hd1) (hd1,gpt1) (hd1,gpt2) ......

grub rescue> ls (hd1,gpt10)/
/boot ......

위와 같이 /boot 폴더가 보이는 파티션이 리눅스 boot 파티션이다. 이제 아래와 같이 하면 Grub으로 부팅할 수 있다.

grub rescue> set prefix=(hd1,gpt10)/boot/grub
grub rescue> insmod normal
grub rescue> normal

이제 우분투 Grub으로 정상 부팅하게 된다. 우분투로 부팅 후, 첫번째 하드디스크에 우분투가 설치되어 있다는 가정하에 아래 두개의 명령으로 Grub이 복구된다.

$ sudo grub-install /dev/sda

$ sudo update-grub

위의 첫번째 명령은 UEFI 방식이든 BIOS 방식이든 Grub이 사용자들에게 일관된 명령을 사용하도록 유도하려는 목적인 듯하다. 실제로는 UEFI와 BIOS 모드의 grub은 서로 다른 패키지이고, 세부 명령 파라메터도 아래의 UEFI 모드에서의 grub-install 명령이 매우 복잡한 것에서 알 수 있듯이 명령 자체가 다르게 수행된다.

grub rescue> 모드로 진입하든 못하든, 일반적으로 우분투 Grub을 복구하는 방법은 여전히 아래의 글을 참고하면 된다.

(2015/8/1 수정)

우분투에서 Grub2 복구 방법에 대한 글들은 많지만 최근의 UEFI 환경을 반영하지 못해 사용자 들이 혼란을 겪는 경우가 많다. 우분투에서는 booting 문제에 대한 모든 것을 boot-repair로 해결하도록 유도하는 듯 하나 이것이 만병통치약은 아니다. boot-repair의 작업 내용은 다소 불투명하고 사용자가 옵션을 어떻게 주느냐에 따라서도 결과가 달라지기 때문이다.

이 글에서는 BIOS 모드와 UEFI 모드로 우분투가 설치된 경우에 대해 OS가 어떤 방식으로 설치됐는지 확인하고 각각의 경우 Grub을 어떻게 복구하는지 알아 본다. 기본적으로, 우분투로 부팅할 수 있어야 하므로 Ubuntu UEFI 모드 설치 USB 만들기 방법으로 만든 USB를 사용한다. 이 USB는 UEFI와 BIOS 방식으로 부팅해서 우분투 live 기능을 사용할 수 있기 때문이다.

참고로, 최근의 Windows 8+이 설치된 PC 들은 UEFI 모드로 OS가 설치됐을 가능성이 높고, 그 전의 PC들은 BIOS 모드로 OS가 설치됐을 가능성이 높다. Multi-OS 환경에서는 두 가지 방식을 혼용해서 사용하기가 어렵다. 즉, Windows가 UEFI 모드로 설치됐으면 우분투도 UEFI 모드로 설치된 것이라고 봐도 좋다. 하지만, 사용자 PC 설정에 따라서 Windows 8+도 BIOS 모드로 설치될 수 있다는 점을 간과해선 안된다.

Ubuntu에서 UEFI vs. BIOS 모드 확인 방법

사용자가 확실히 우분투를 어떤 방식으로 설치했는지 알고 있다면 이 과정은 건너 뛰어도 된다.

우분투 설치 USB로 부팅해서 우분투가 설치된 /boot 파티션을 아래와 같이 마운트 한다. 우분투 설치시 /boot 파티션을 따로 지정하지 않으면 우분투가 설치된 파티션(= root partition)에 /boot 폴더가 있다. 우분투가 설치된 파티션을 잘 모르면 아래의 명령으로 확인할 수 있다.

$ sudo parted /dev/sda print

여기서는 3번 파티션, 즉, /dev/sda3에 우분투가 설치됐다고 가정한다.

$ sudo mkdir /mnt
$ sudo mount /dev/sda3 /mnt

이제 우분투에 설치된 Grub이 BIOS Grub(grub-pc 패키지)인지 EFI Grub(grub-efi 패키지)인지 확인한다.

$ ls -CF /mnt/boot/grub

만약, 실행 결과 i386-pc/ 폴더가 보이면 BIOS 모드로 우분투가 설치된 것이고, x86_64-efi/ 폴더가 보이면 UEFI 모드로 설치된 것이다. 두 가지가 모두 있다면 문제가 있는 것인데 그럴 가능성은 거의 없다. 단, 위의 USB에는 두 폴더가 다 있다.

그런데, 여기서 현재 USB로 부팅한 방식이 UEFI인지 BIOS 방식인지도 점검해볼 필요가 있다. 즉, Double Check 하자는 것이다.

$ ls -CF /sys/firmware

만약, 위의 실행 결과 efi/ 폴더가 없으면 USB는 BIOS 모드로 부팅한 것이고 efi/ 폴더가 보이면 UEFI 모드로 부팅한 것이다.

UEFI PC인 경우 두 가지 점검 결과가 동일해야 한다. Apple Mac PC의 경우에는 반드시 일치하지 않을 수도 있으나 부팅을 어떤 방식으로 했는지 부팅 시에 알 수 있어서 큰 문제가 없다.

아무튼, 현재 점검하고자 하는 것은 디스크에 설치된 우분투가 어떤 방식으로 설치됐는가 하는 것이므로 이를 바탕으로 Grub 복구 방식이 달라짐에 유의해야 한다.

BIOS 모드로 설치된 Ubuntu Grub 복구 방법

USB가 BIOS 모드로 부팅됐음을 확인하고, /dev/sda3에 우분투가 설치됐다고 가정하여,

$ sudo umount /mnt
$ sudo mount /dev/sda3 /mnt

$ for i in /sys /proc /run /dev; do sudo mount --bind "$i" "/mnt$i"; done
$ sudo chroot /mnt
$ sudo grub-install /dev/sda
$ sudo update-grub

UEFI 모드로 설치된 Ubuntu Grub 복구 방법

아래 두가지 방법 중 하나를 선택하면 된다.

1. Windows로 부팅 후 복구 방법

Windows 설치 후 Grub 메뉴로 진입할 수 없다면 Windows로 재부팅한 후, 관리자 권한으로 아래의 명령을 실행해야 한다.

bcdedit /set {bootmgr} path \EFI\ubuntu\shimx64.efi

재부팅 후 Grub에서 우분투로 부팅하여 아래의 명령만으로 EFI Grub이 복구될 수 있다.

$ sudo update-grub

2. Ubuntu 설치 USB로 복구 방법

우분투 설치 iso 이미지로 USB를 만들어 UEFI 모드로 부팅하면 최근의 15.04 버전까지도 grub-efi 패키지가 메모리의 우분투(USB로 부팅하면 RAM에 설치된 우분투가 기동됨)에 설치되지 않는다. grub-pc 패키지만 설치된다. 다만, grub-efi 패키지는 탑재되어 있어서 하드디스크에 우분투를 설치하면 grub-efi 패키지도 설치된다.

따라서, UEFI 모드로 USB로 부팅하고 나서 grub-efi 패키지를 메모리에 설치해야 한다. 아래와 같이하면 혹시 grub-efi 패키지가 설치되어 있더라도 패키지를 재설치해 주니까 안전하게 설치할 수 있다. 또한, 메모리에만 설치하는 것이므로 USB로 새로 부팅후 grub을 복구할 때마다 매번 설치해야 한다. 네트워크이 연결되어 있다고 가정하여,

$ sudo apt-get install --reinstall grub-efi

UEFI 모드 USB로 부팅됐음을 확인하고, UEFI 모드에서는 /dev/sda1이 ESP 파티션이며, /dev/sda3에 우분투가 설치됐다고 가정하여,

$ sudo umount /mnt
$ sudo mount /dev/sda3 /mnt
$ sudo mount -t vfat /dev/sda1 /mnt/boot/efi

$ sudo modprobe dm-mod
$ sudo grub-install --target=x86_64-efi --efi-directory=/mnt/boot/efi --bootloader-id=ubuntu --boot-directory=/mnt/boot --recheck --debug

재부팅 후 Grub 메뉴에 Windows가 보이지 않는다면 우분투로 재 부팅후,

$ sudo update-grub

참고 사항

현재 기동된 우분투에 grub-efi 패키지가 설치되어 있는지는 아래와 같이 확인할 수 있다.

$ ls -CF /usr/lib/grub

실행 결과 x86_64-efi/ 폴더가 보이면 grub-efi 패키지가 설치되어 있는 것이다. 이는 우분투 설치 iso이미지로 만든 USB로 UEFI 모드로 부팅 후 메모리의 우분투에 grub-efi 패키지가 설치되어 있는지 확인하기 위해서 필요하다. 또한, grub-install 명령이 제대로 동작하기 위해서 반드시 필요하다.

Ubuntu 복구 모드(recovery mode) 활용

우분투 복구 모드로 진입해야 하는 경우가 드물게 생긴다. 주로, NVIDIA 드라이버를 설치 또는 제거하거나 File System의 일부가 깨져서 fsck를 돌려야 할 경우이다. 복구 모드는 부팅 후 Grub 메뉴에서 Advanced Ubuntu Options에서 Recovery Mode를 선택하여 진입한다.

여기서는, 복구 모드에서 하드 디스크에 쓰기가 가능하도록 하는 방법과 그 후 콘솔에서 WIFI를 사용하는 방법, 그리고 NVIDIA 드라이버를 설치 및 제거 하는 방법들을 정리한다.

하드 디스크 쓰기

우분투 복구 모드로 부팅하면 메뉴가 뜨는데 root command prompt를 선택한다. 그 후 다음 명령만으로 쓰기가 가능해 진다.

$ mount -o rw,remount /

그런데, root partition 외에 다른 파티션도 사용할 필요가 있다면 해당 파티션을 추가로 마운트 한다. 원래는 mount -a 명령으로 /etc/fstab에 등록된 모든 파티션이 마운트 되는데 우분투 14.04에서는 안되더라. 필요한 파티션을 각각 마운트 해주면 된다.

$ mount /home

복구 모드에서 WIFI 사용하기

가끔 복구 모드에서 네트워크를 사용해야 할 때가 생긴다. 그런데, WIFI my_SSID와 my_password를 무선 공유기에 알려 주어야 하므로 해당 설정 파일을 수동으로 만들어 둘 필요가 있다.

$ wpa_passphrase my_SSID my_password > ./wpa_supplicant.conf

위의 파일을 vi나 nano 등의 편집기를 사용하여 아래의 내용과 같이 수정해 준다.

$ cat  ./wpa_supplicant.conf

ctrl_interface=DIR=/run/wpa_supplicant
update_config=1
fast_reauth=1
# ap_scan may be: 0, 1, 2
ap_scan=1
network={
    ssid="my_SSID"
    #psk="my_password"
    psk=ba4467448e288e60d085fd5b50282d6d59cfd08
}

이제 WIFI daemon을 실행 한다.

$ wpa_supplicant -B -i wlan0 -c ./wpa_supplicant.conf
$ dhclient wlan0 &

WIFI에 접속이 됐는지 확인하려면,

$ sleep 3
$ route -n
$ nslookup google.com

NVIDIA 드라이버 설치하기

NVIDIA 홈페이지에서 내려 받은 드라이버를 설치하기에 앞서 오픈소스 드라이버인 nouveau 모듈이 부팅시에 로딩되지 않도록 해야 한다. /etc/modprobe.d/blacklist.conf 파일에 아래의 한 줄을 추가해 준다.

blacklist nouveau

설치는 아래와 같이 내려 받은 파일을 실행하여 따라가면 된다. 이 과정에서 64-bit 우분투인 경우에 라도 나중에 WINE 등을 설치할 경우를 대비해 32-bit 라이브러리도 설치해 두는 게 좋다.

$ sh NVIDIA-Linux-x86_64-340.24.run
$ sudo reboot

NVIDIA 드라이버 제거 및 다시 nouveau 드라이버 복구하기

NVIDIA 드라이버 설치 후 부팅했는데 정상동작하지 않아서 다시 nouveau 드라이버로 우분투를 구동하기 위해서 다음 과정이 필요하다. 참고로, NVIDIA 드라이버는 버전에 따라 자신의 PC와 잘 맞는게 있고 그렇지 않은게 있다. 다시 복구 모드로 부팅하여 아래와 같이 제거한다.

먼저, 앞서 추가했던 /etc/modprobe.d/blacklist.conf 파일에서 blacklist nouveau를 삭제하고,

$ sh NVIDIA-Linux-x86_64-340.24.run --uninstall
$ sudo reboot

다시, 부팅 후 로그인은 되는데 바탕화면만 나오고 아무것도 할 수 없을 경우에는 <Control>+<Alt>+<F2>를 눌러 콘솔 모드로 로그인한다. 로그인 후,

$ sudo service lightdm stop
$ sudo apt-get install --reinstall xserver-xorg-core libgl1-mesa-glx
$ sudo service lightdm start

위와 같이 OpenGL 드라이버를 다시 설치하고 나서 <Alt>+<F7> 키를 누르면 X-Window로 로그인 할 수 있다.

우분투 OpenGL 관련 라이브러리 업데이트 후 NVIDIA 문제 해결

Proprietary NVIDIA 드라이버 사용시 Ubuntu Daily Update 후 재부팅하면 로그인은 되는데 바탕화면만 나오고 아무것도 할 수 없는 문제가 또 생긴다. 이는 OpenGL 라이브러리 또는 xserver-xorg-core 패키지가 업데이트 될때 NVIDIA 라이브러리를 덮어 쓰기 때문에 발생하는 문제이다. NVIDIA 드라이버를 다시 설치해 주면 문제가 해결된다.