[LFS3]첫 번째 트러블 슈팅과 Linux API Headers 빌드

1. LFS는 호락호락하지 않다.

Binutils와 GCC Pass 1이라는 큰 산을 넘었다고 생각했는데, 예상치 못한 곳에서 발목을 잡혔습니다.

갑자기 사라진 sources폴더, 그리고 권한 오류까지. 문제가 생겼을때 이를 어떻게 분석하고 해결했는지 
오늘은 그 첫 번째 삽질과 해결 기록에 대해 작성해 보겠습니다.

 

2. 트러블 슈팅 #1: 사라진 $LFS/sources와 자동 마운트

GCC 빌드 후, Ubuntu를 다시 켰을 때, 작업하던 소스 폴더들이 보이지 않는 당황스러운 상황을 마주했습니다.

환경 변수가 꺼졌나? 싶어서 확인을 해봤는데, echo $LFS를 하면 /mnt/lfs가 정상적으로 출력되는것을 확인하고, 환경변수의 문제는 아니구나 판단을 내렸스브니다.

 

원인을 다시 분석해봤는데, 환경 변수가 아니기 때문에 마운트 상태를 확인해 보았습니다.

lsblk라는 명령어를 타이핑해보면 /dev/sdb1이 마운트 포인트가 /mnt/lfs라고 떠있어야하는데, 떠있지 않고있기때문에 

다시 마운트를 해야했습니다.

 

lfs유저의 권한으로는 Host 관리 작업(마운트,디렉토리 생성)를 진행할 수 없으니, root로 돌아와 작업 해보았습니다.

 

sudo mount -v -t ext4 /dev/sdb1 $LFS #로 다시 마운트를 하고,

 

ls -al /mnt/lfs/sources를 확인해보니, 정상적으로 인식하는것을 확인할 수 있었습니다. 

 

또한, 앞으로 마운트를 자동으로 하게끔 작업해보겠습니다.

리눅스에는 부팅될 떄 자동으로 특정 장치를 연결해 주는 /etc/fstab 이라는 설정 파일이 있습니다.

이 파일을 이용해 부팅시 자동으로 디스크를 마운트하게 만들어보겠습니다.

하지만 이 파일은 잘못 건드리면 부팅이 안 될 수도 있는 민감한 녀석이기 때문에, 아주 조심스럽게 작업해야합니다.

 

1. 파티션의 고유 식별자(UUID)를 확인해봅시다.

장치 이름(/dev/sdb1)은 하드디스크 연결 순서에 따라 바뀔 수 있지만, UUID는 절대로 변하지 않는 고유 번호입니다.
안전을 위해서 이것을 사용할 것 입니다.

sudo blkid /dev/sdb1

결과에 나오는 UUID="...-..."부분을 따로 복사해 둡시다.

 

2. /etc/fstab 파일 수정하기

이제 시스템 설정 파일에 "부팅할 때 이 UUID를 가진 디스크를 /mnt/lfs 에 연결해줘"라고 명령어를 적어줄겁니다.

안전을 위해 백업부터 해둡시다.

sudo cp -v /etc/fstab /etc/fstab.bak

 

나노 편집기를 이용해서 파일을 열어봅시다.

sudo nano /etc/fstab

 

맨 아랫줄에 내용 추가 해줍시다.

UUID=여기에-복사한-UUID-넣기  /mnt/lfs  ext4  defaults  0     2

 

UUID를 이용했기 떄문에 나중에 디스크 순서가 바뀌어도 꼬일 염려가 없는 아주 정석적인 방법입니다. 

다만 맨끝의 숫자의경우
첫번째 숫자는 0 : 덤프(백업) 여부인데, 보통 LFS 파티션은 0으로 둡니다.
두번쨰 숫자는 2 : 부팅 시 디스크 체크(fsck) 순서입니다. 루트 파티션( / ) 이 1번이므로, LFS파티션은 2번으로 두는게 정석이기 때문에 2번으로 설정했습니다.

마지막으로 저장 후 확인하겠습니다.

# 1. 일단 마운트를 해제합니다.
sudo umount /mnt/lfs

# 2. fstab 설정대로 마운트를 시도합니다.
sudo mount -a

# 3. 연결이 잘 됐는지 확인합니다.
ls -l /mnt/lfs/sources

 

3. 트러블 슈팅 #2 : 퍼미션 문제와 권한의 벽 

Linux API Headers를 설치하려던 중 cp 명령어에서 권한 거부 오류가 발생했습니다.

 

cp -rv usr/include $LFS/usr 실행 시 Permission Denied가 출력되었습니다.

초기 LFS환경을 구축할 때 root 계정으로 생성했기 때문에, 현재 빌드를 수행하는 lfs 유저는 해당 폴더에 파일을 쓸 권한이 없는 상태입니다.
따라서, 임시 시스템 빌드 과정에서 필요한 디렉토리의 주인을 lfs 유저로 변경하여 문제를 해결했습니다. 
root로 로그인을 한 뒤, 아래 명령어를 통해 소유권을 이전해 주었습니다.

chown -Rv lfs $LFS/usr

 

 

4. 시스템의 신경망 : Linux API Headers (5.4.)

모든 트러블 슈팅을 마치고 드디어 Linux API Headers를 설치했습니다.

 

 이 단계는 커널의 기능을 일반 프로그램이 이해할 수 있도록 '인터페이스(사전)'를 제공하는 과정입니다.
다음에 빌드할 C 라이브러리(Glibc)가 커널과 대화하기 위해 반드시 필요한 신경망과 같습니다.

 

주요 빌드 과정은 아래와 같습니다.

tar -xvf linux-*.tar.xz
cd linux-*

# 1. 커널 소스 트리 초기화 (혹시 모를 찌꺼기 제거)
make mrproper

# 2. 사용자 공간용 헤더 추출
make headers

# 3. 설치에 불필요한 파일들(주로 .install, ..check 파일 등) 삭제
find usr/include -type f ! -name '*.h' -delete

# 4. 추출된 헤더를 LFS 시스템 경로로 복사
cp -rv usr/include $LFS/usr

위에 과정까지 문제없이 해결이 되었다면, 뒷정리까지 깔끔하게 해줍시다.
LFS 빌드에서 가장 중요한 미덕은 '쓴 물건은 바로 치우는 것' 입니다.

cd $LFS/sources
rm -rf linux-*

 

 

5. 결론 : 이제 시스템의 심장으로

 우여곡절 끝에 기초 공사와 신경망 설치를 마쳤습니다. 트러블 슈팅을 통해 리눅스의 마운트 시스템과 유저 권한 구조를 더 깊게 이해할 수 있었습니다. 다음 편에서는 드디어 리눅스 시스템의 심장이자 모든 프로그램의 근육이 될 Glibc(GNU C Library) 빌드에 도전합니다. 이번에도 Multilib 설정이라는 만만치 않은 과정이 기다리고 있지만, 한 걸음씩 나아가 보겠습니다. 감사합니다.!