symbol 'grub_calloc' not found

imtaejong·2020년 7월 31일
0
post-thumbnail

최근 우분투 GRUB이 업그레이드가 되었다.
그런데 특정 하드웨어에서는 심볼릭 링크가 엉뚱하게 생성되는 이슈가 생겼고 그것을 해결하는 과정이다
(그 특정 하드웨어에 내 하드웨어가 포함되어버린거임.....................)

이 과정의 원문 링크
https://www.reddit.com/r/Ubuntu/comments/i0vlf0/repair_grub_boot_error_symbol_grub_calloc_not

원문에서 시키는 대로 하면 잘 될줄 알았으나 역시나 한번에 되면 오히려 불안한 법..
나는 이 방법대로 하니 잘 안됐다..

RAID, LVM 유저의 경우와 명령어를 치는 방법 등 많은 부분이 생략 된 채로 안내가 되 있어서 다시 내가 해결한 방법을 다시 기록한다.


문제발생 과정

우분투에서 아래 명령어를 실행한 이후 에러가 발생했다.

sudo apt-get update
sudo apt-get upgrade
sudo reboot

명령어 아래와 같은 에러가 발생했다.
GUI 환경에서 아래와 같은 업그레이드 팝업 창을 통해 진행 한 경우도 마찬가지로 발생했을 것이다.

해결과정

우선 우분투 환경으로 접속 할 수 있어야 한다.
그래서 USB에 Ubuntu 20.04를 설치해서 이 USB로 부팅을 진행했다.
(우분투 버전은 상관 없다)

이후 USB 부팅을 하면 우분투를 설치 없이 바로 실행 할 수 있다.
GUI 환경 기준 Try Ubuntu라는 버튼을 누르면 된다.

USB 부팅해놓은 상태이므로 재부팅하면 모든 설정을 처음부터 다시 해야한다.

이후 터미널에 접속해서 자신의 부팅 디스크가 무엇인지부터 확인한다.

$ sudo fdisk -l


Disk /dev/loop0: 956 KiB, 978944 bytes, 1912 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

...

Disk /dev/sdb: 119.2 GiB, 128035676160 bytes, 250069680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x23ad3ffa

Device     Boot Start       End   Sectors   Size Id Type
/dev/sdb1  *     2048 250066943 250064896 119.2G  7 HPFS/NTFS/exFAT


Disk /dev/sdc: 119.2 GiB, 128035676160 bytes, 250069680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x490f0f61

Device     Boot   Start       End   Sectors   Size Id Type
/dev/sdc1  *       2048    999423    997376   487M 83 Linux
/dev/sdc2       1001470 250068991 249067522 118.8G  5 Extended
/dev/sdc5       1001472 250068991 249067520 118.8G 8e Linux LVM


Disk /dev/mapper/ubuntu--vg-root: 110.8 GiB, 118992404480 bytes, 232407040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/ubuntu--vg-swap_1: 7.9 GiB, 8501854208 bytes, 16605184 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

내 경우는 /dev/mapper/ubuntu--vg-root 디스크의 부팅 환경을 복구해야 했다.
따라서 다음과 같은 작업이 필요하다

1. USB 환경의 터미널에 디렉터리를 임시로 만든다 (이름/경로 상관없다)
2. 임시로 만든 디렉터리에 /dev/mapper/ubuntu--vg-root 디스크를 바인드 (마운트) 시킨다.
3. 이후 바인드 된 임시 디렉터리를 발판 삼아서 /dev/mapper/ubuntu--vg-root 환경의 터미널로 접속한다.
4. 접속한 터미널에서 GRUB 환경을 다시 잡아준다.
5. 재부팅


/dev/mapper/ubuntu--vg-root 경로의 디스크를
내가 임시로 만든 디렉터리에 마운트 (바인드) 시키는 작업을 해야 한다.

임시 디렉터리 생성

# USB에서 접속한 TERMINAL 환경에서 실행

sudo -i
mkdir /media/mapper

복구해야 하는 디스크를 디렉터리에 바인드 시킨다

# USB에서 접속한 TERMINAL

# 복구 대상 디스크와 임시 디렉터리 마운트
mount /dev/mapper/ubuntu--vg-root /media/mapper

# 복구 대상 디스크에 설정되어 있는 터미널로 접속하기 위해 최소 파일을 바인드 시킨다.
mount --bind /dev		/media/mapper/dev
mount --bind /dev/pts	/media/mapper/dev/pts
mount --bind /proc		/media/mapper/proc
mount --bind /sys		/media/mapper/sys

복구 대상 디스크의 터미널로 접속

# USB에서 접속한 TERMINAL

# 아래 명령어를 치면 복구 대상 디스크의 터미널로 접속하게 된다.
chroot /media/mapper

접속한 터미널에서 GRUB 환경을 다시 잡아준다.

# (중요) 여기서부터 복구 대상 디스크의 터미널이다. 루트 환경으로 로그인해주자
sudo -i

# 복구 대상 디스크 GRUB 환경을 다시 설정한다
grub-install /dev/mapper/ubuntu--vg-root

# 다시 설정 된 GRUB을 Write 한다
update-grub

나는 이 이후에 2가지 방법을 더 제시한다.

1. dpkg-reconfigure를 이용해서 grub-pc를 재설정한다

sudo dpkg-reconfigure grub-pc

위 명령어를 치면 아래 창이 나온다 (안나오는 경우는 이미 재설정이 된 경우)
따로 건드릴 건 없고 그냥 엔터 치면 된다.

그 다음으로 이 화면도 그냥 엔터치면 된다

그러면 부팅 환경을 다시 쭈우우욱 잡을 것이다.

2. boot-repair 프로그램을 이용한다

이 프로그램은 GRUB 환경을 감지해서 자동으로 재설정해주는 프로그램이다.
설치 방법은 아래와 같다.

sudo add-apt-repository ppa:yannubuntu/boot-repair
sudo apt-get update
sudo apt-get install boot-repair
sudo boot-repair

이후 프로그램이 실행되면 RAID 환경이냐고 물어보는 팝업 창이 뜨는데, 본인은 LVM 환경을 사용중이라 혹시 몰라서 YES 눌러서 진행했는데, 문제 없이 잘 진행 됐다.
아래와 같은 창이 뜨면 Recommended repair를 눌러서 진행하자


모든게 끝났다면 sudo reboot 을 통해 겸허히 기다리도록 하자....

0개의 댓글