2025.05.08

TIL(TODAY I LEARN)

---

• 오늘한 내용 : 환경설정 - Window ubuntu 18.04 세팅

• WEEK 09 : 정글 끝까지(PintOS) - Threads

---

PintOS 환경 세팅

9주차 PintOS가 시작되었다. 핀토스 환경을 세팅하기 위해서는 우분투 버전 18.04를 사용해야 한다고 한다.

늘 하던대로, 우리의 정글 코치님들께서 도커파일 을 준비해주셨다.

git clone --depth=1 https://github.com/krafton-jungle/pintos_lab_docker.git

깃 클론 딸깍

vscode 딸깍

에러가 발생한다.

왜 이러냐?

박지성 군의 벨로그 우선 읽고 와보자

GPT야 도와줘!

이 에러 메시지는 컨테이너 안의 기본 C 라이브러리(GLIBC) 버전이 VS Code Remote Server가 요구하는 2.28 이상이 아니라서 발생한 것입니다. Ubuntu 18.04 기본 glibc는 2.27이고, DevContainer 확장판(vscode-server)은 최소 2.28을 필요로 해요.

그렇다. 핀토스 환경은 25년 환경이 받아들일 수 없는 옛날 환경이다.

그럼 어떡해야하냐?

해결방안

1. vscode의 버전을 1.85(구버전)으로 다운그레이드 한다
   • 그럼 GLIBC 2.27 하위 버전도 지원한다
2. dev container를 통한 vs code 서버와의 연결을 포기한다
   • 우리는 vscode 확장 프로그램인 dev container 확장을 사용하고 있다.
   • 도커 컨테이너는 정상적으로 띄워지는데 dev contiainer를 통한 vscode 서버 연결이 안되는 것!
   • 도커 컨테이너는 컨테이너 대로 띄우고 로컬에서 작업 후 컴파일만 컨테이너 내부에서 하자!

내가 확장프로그램이 된다.

나는 2번 방법을 채택했다. 내 vscode는 소중하니까.

디렉토리 구조부터 바꾸어 보자

• 정글 제공 디렉토리 구조

pintos_lab_docker/
├── .devcontainer/
│   ├── devcontainer.json      # VSCode에서 컨테이너 환경 설정
│   └── Dockerfile             # pintos 개발 환경 도커 이미지 정의
│
├── pintos-kaist-lab
│   ├── threads                # 9주차 threads 프로젝트 폴더
│   ├── userprog               # 10-11주차 user program 프로젝트 폴더
│   └── vm                     # 12-13주차 virtual memory 프로젝트 폴더
│
└── README.md                  # 현재 문서

• 새로운 디렉토리 구조
  • 우린 devcontainer 확장을 안 쓸거니까 .devcontainer 폴더안의 Dockerfile 만 밖으로 빼주었다.

빌드

1. 이미지 빌드

   Dockerfile이 있는 폴더(여기서는 C:\Krafton_Jungle\pintos_lab_docker)로 이동한 뒤, CMD에서:

   cd C:\Krafton_Jungle\pintos_lab_docker
   docker build -t pintos-dev .
   

   이 명령이 성공하면 로컬에 pintos-dev:latest 이미지가 생성됩니다.

2. 컨테이너 실행

   이제 다시 CMD에 다음을 입력하세요:

   docker run -it ^
     --name pintos-build ^
     -v "%cd%:/workspaces/pintos_lab_docker" ^
     -w /workspaces/pintos_lab_docker/pintos-kaist ^
     pintos-dev ^
     bash

   • -name pintos-build 로 컨테이너 이름을 지정했습니다.
   • t pintos-dev . 로 방금 빌드한 이미지를 가리키니까, pull 시도 없이 바로 실행됩니다.

이제 bash 프롬프트가 뜨고, /workspaces/pintos-kaist 안에서 make·make qemu 등을 실행하실 수 있을 거예요.

추가) cmd 에서 셸로 컨테이너 들어가기

이미 컨테이너를 만든 상태(처음 말고 두번째부터)라면 커맨드창(cmd) 기준 아래 명령어를 입력해 들어가면 된다. attach 하지마

docker exec -it pintos-build bash

GPT 선생님의 친절한 설명이 있으셨다.

1. 도커 이미지 빌드
2. 컨테이너 실행

크게 이 순서로 진행 된다. 여기서 우리가 알아야 할 점이 컨테이너는 새로운 os 사용하는 것이다.

컨테이너를 그냥 실행 하게 되면 깔끔한 상태라는 것이다.

그래서 우리는 로컬에서 작업한 환경이 컨테이너 내부에서도 연동? 동기화? 되게 해야한다.

그래서 컨테이너를 실행할 때 우리의 pintos-kaist 폴더를 마운트 해줘서 컨테이너를 띄워줘야 한다.

-v, -w 옵션을 통해 DecContainer가 대신 해주던 작업들을 직접 해주는 것이다.

들어와진다!

제대로 동작되는지 확인해보자

$ cd pintos-kaist
$ source ./activate
$ cd threads
$ make check
# 뭔가 한참 compile하고 test 프로그램이 돈 후에 다음 message가 나오면 정상
20 of 27 tests failed.

딸깍

single.output' failed
make[1]: *** [tests/threads/alarm-single.output] Error 127
make[1]: Leaving directory '/workspaces/pintos_lab_docker/pintos-kaist/threads/build'
../Makefile.kernel:10: recipe for target 'check' failed
make: *** [check] Error 2

잘 되다가 이런 127에러가 뜬다

왜지?

source ./activate
bash: ./activate: line 6: syntax error near unexpected token fi'
'ash: ./activate: line 6: fi;

source ./activate 과정에서 무엇인가 이상하단다.

윈도우 ↔ 유닉스 줄바꿈 차이

• Windows: 각 줄 끝에 \r\n (CRLF, carriage‐return + line‐feed)
• Linux/macOS: 각 줄 끝에 \n (LF, line‐feed)만

Bash 스크립트(activate, utils/pintos 등)는 LF만 있는 줄 끝을 전제로 작성되어 있는데,

윈도우에서 Git으로 클론하거나 에디터로 저장할 때 CRLF가 섞여 들어가면

if [ "$BASH" != "" ]; then\r
    SOURCE="${BASH_SOURCE[0]}";\r
else\r       ← 여기에 붙은 `\r` 때문에
    SOURCE="$0";\r
fi;\r        ← `fi\r` 를 Bash가 ‘fi;’ 가 아니라 이상한 토큰으로 보고
             syntax error near unexpected token `fi’

처럼 \r 때문에 fi 또는 else 같은 키워드를 인식하지 못하고 “unexpected token” 에러가 나는 거예요.

그렇다고 합니다.

activate의 CRLF → LF 변환

스크립트가 Windows 개행(CRLF) 상태라면, 다음 중 하나로 바꿔 주시고 다시 소싱하세요:

sed로 직접 변환

# activate 스크립트에서 CR 제거
sed -i 's/\r$//' /workspaces/pintos_lab_docker/pintos-kaist/activate

# utils 폴더 아래 모든 스크립트에서 CR 제거
sed -i 's/\r$//' /workspaces/pintos_lab_docker/pintos-kaist/utils/*

source ./activate

이제 source ./activate 가 문제 없이 동작하면서 /utils 폴더의 pintos 스크립트들이 PATH에 올라가고, make check 가 정상적으로 실행될 거예요.

개행문자를 처리해주고 나니 되는 것 같다!

그럼 깃 클론하고 푸시/풀 할때마다 바꿔줘야하는가?

해결 요약

• Git 설정(core.autocrlf)을 input 또는 false로 바꾸거나,
• .gitattributes에 text eol=lf를 추가해두면
• 클론/체크아웃 시 자동으로 LF로 변환돼 이런 오류를 예방할 수 있습니다.

이제 “왜 커널 탓이 아니고 줄바꿈 문자 탓인지” 감이 오시겠죠? 😊

그렇다는데 여기까지 안해봐서 잘 모르겠다. 해보고 추가해보겠다

추가)

해결 방안

https://github.com/BaeJaejun/Pintos-Lab

//gitattributes
* text=auto eol=lf

새로운 깃 레포지토리를 만들어서 .gitattributes 설정을 해주었다.

그리고 이 레포지토리를 새로 클론해서 작업환경을 설정해주니 sed 와 같은 개행문자 처리를 해주지 않아도 가능했다.

이렇게하면 맥 / 윈도우 유저간 컨플릭트는 안생기지 않을까?

모두가 lf 설정으로 클론/커밋이 되게 된다.

결론

위 처럼 .gitattributes 설정을 한뒤 깃을 새로 클론하자

git clone https://github.com/YourUser/new-repo.git pintos_lab_docker

디렉토리 구조위에 잘 맞춰 넣어라!

컨테이너는 위의 설정 그대로 다시 사용하면 된다.

이렇게 새로 클론하면 위의 sed 설정을 해주지 않아도 된다.

• 왜 새로 클론 해야하는가?
  • 기존 정글 제공 도커 레포지토리를 받으면 CRLF가 이미 바뀐 상태니까 올라갈땐 괜찮아도 작업환경에서 LF가 아니니까 작업환경을 LF상태로 바꿔주려고 새로 클론했음