Index
2026-09-08 — Engineering

Colab install.sh 실패 원인 불투명 문제 해결

AI899 | 사용자 2차 Colab 시도에서 CalledProcessError 한 줄만 받은 것을 계기로 진행한 로깅·안내 문구 트러블슈팅

TL;DR

2
재현 검증 통과 항목
40줄
실패 시 노출 로그
PASS
apt 분기 재검증 (Ubuntu 24.04)
3
사용자 시도 라운드

1 배경 / 목적

어제 Colab 지원 포팅에서 만든 경량 에셋 팩을 사용자가 실제 Colab 에서 돌리다가 install.sh 가 실패했는데, 받은 메시지는 CalledProcessError ... returned non-zero exit status 1 한 줄뿐이었다.

진짜 문제는 설치 실패 자체가 아니라 설계 결함이었다. colab_setup.py 가 subprocess.run([...], check=True) 로 install.sh 를 실행하는데, 자식 프로세스의 stdout 은 커널의 파일 디스크립터로 나가서 %%vla 셀 출력에 안 잡힌다. install.sh 자체는 단계별 로그를 잘 찍고 있었는데 그게 전부 버려지고 있었다.

2 작업 내용

2-1. 스트리밍 로깅 (핵심 수정)

colab_setup.py: _run() 신규 Popen(stdout=PIPE, stderr=STDOUT) 으로 실행 → 한 줄씩 읽어 즉시 출력 + $VLA_ENV/install.log 에 동시 기록 → 반환코드 != 0 이면: 로그 마지막 40줄 + 로그 경로를 SystemExit 메시지에 담아 던짐 → install_kernel.sh 호출도 동일 함수로 교체 (try-except 로 감싸는 게 아니라 반환코드를 검사하는 방식 — 에러를 숨기지 않는다)

2-2. 원인 후보 좁히기

트레이스백 경로가 /usr/lib/python3.13/subprocess.py 인 것을 보고 최근 Colab 이 Python 3.13 / Ubuntu 24.04 계열로 바뀐 것으로 판단. tmp/test_install_apt_path.sh 의 베이스 이미지를 ubuntu:24.04 로 바꿔 재실행 → apt 분기(libEGL/libGL/libavcodec 설치, EGL ICD 생성)는 다시 PASS. 1단계는 범인이 아님을 확인.

사용자의 Drive 사본이 경량 팩 이전의 옛 버전(VLA_SLIM_ASSETS 미적용)이라는 것도 출력 문구(The first run downloads about 30 GB)로 확인 — 재현을 위해 폴더 재업로드가 필요했다.

2-3. 3차 시도에서 드러난 문구 버그

재실행하니 install.sh 가 끝까지 갔다 (앞선 실패는 일시적 오류, install.sh 가 멱등이라 재실행으로 통과). 그런데 마지막 "Next:" 안내 블록이 로컬 전용(jupyter lab 실행 + 커널 선택)인데 Colab 에도 그대로 찍혀 사용자가 "코랩버전인데 이거 맞나?" 라고 혼란스러워했다.

install.sh: 끝 블록을 `if [ "${VLA_NEXT_STEPS:-1}" = "1" ]` 로 감싸 조건부 출력 colab_setup.py: VLA_NEXT_STEPS=0 지정 후 Colab 용 안내를 직접 출력 (import vla_colab; vla_colab.connect() + 설치 로그 경로)

2-4. 재업로드 전 검증 — 손댄 뒤 한 번도 안 돌린 코드 두 곳

"지금 버전으로 다시 받아서 올리면 문제 없나?" 라는 질문에 답하기 전에 실제로 돌려 확인했다.

2-5. Drive 마운트 실패 안내 개선

사용자: MessageError: Error: credential propagation was unsuccessful. 마운트 실패는 무시 불가 — 이후 셀이 FileNotFoundError 로 바로 죽는다. 마운트 셀 위에 일시적 실패라는 것 + 복구 방법(세션 재시작, 팝업/쿠키 허용) + Drive 없이 가는 우회 경로(files.upload() 로 zip 업로드) 안내 3줄 추가.

2-6. 이스케이프 버그 — compile() 검사가 실제로 막은 사고

위 안내 문자열의 \n·\" 이스케이프가 빌더의 비-raw 삼중따옴표를 지나며 한 겹 벗겨져 셀 코드가 SyntaxError: unterminated string literal 이 됐다. make_colab_nb.py 가 생성 직후 모든 code 셀을 compile() 하도록 되어 있었던 덕에 노트북이 나가기 전에 잡혔다. TEXTS["*"]["setup"] 을 raw 문자열(r''')로 바꿔 해결.

3 결과 (수치)

실측 대역폭 — 병목은 다운로드가 아니었다

항목크기속도시간
textures538 MB78 MB/s6 s
fixtures472 MB88 MB/s5 s
objaverse2.12 GB104 MB/s20 s
generative_textures593 MB62 MB/s9 s
pi05 체크포인트7 GB—76 s
데이터셋1.8 GB—29 s
Colab 의 대역폭 자체는 좋았다. 30~50분의 대부분은 다운로드가 아니라 "Extracting..." 압축 해제와 uv sync — 경량 팩(수만 개 → 수천 개 파일)의 방향이 맞았다는 근거.

검증 결과

항목결과
apt 분기 (ubuntu:24.04 재검증)PASS — libEGL/libGL/libavcodec 설치 + EGL ICD 생성 확인
install.sh [3/6] 경량 분기 (컨테이너, 실제 HF 팩)PASS — 5,056 파일 / 1,286 MB, 필수 경로 존재, 재실행 시 스킵 확인
_run() 성공/실패 경로PASS — 둘 다
Next 블록 조건부 출력기본값=출력, VLA_NEXT_STEPS=0=출력 없음 확인

4 Takeaway

의미

로그가 안 보이면 사용자는 원인을 추측만 하게 되고, 디버깅 사이클이 왕복 커뮤니케이션으로 늘어진다. 스트리밍 로깅은 이번 한 번이 아니라 앞으로의 모든 install 실패에 재사용 가능한 인프라가 됐다. 또한 배포 전 자동 compile() 검사가 실제로 배포 사고(SyntaxError) 하나를 막아냈다 — 생성 파이프라인에 검증을 넣어두는 것의 가치가 이번에 실증됐다.

5 Next Steps

미해결 한계

Drive 마운트 실패는 Colab 쪽 일시적 이슈로 이 환경에서 재현 불가 — 세션 재시작/쿠키 허용 안내만 가능하다. 지속되면 files.upload() 우회 경로를 안내할 수밖에 없다.

다음 작업

재업로드된 폴더(경량 팩 v2 + 이번 로깅/문구 수정 포함)로 사용자가 새 Colab 런타임에서 다시 완주 테스트. T4(sm_75) bf16 동작 여부는 여전히 미검증.