업그레이드 후 패키지가 정상작동하지 않는다면? (Using arch BTW)
Arch linux, rolling relase, 그리고 bleeding edge
아치 리눅스를 쓰다보면 그럴 때가 있다.
분명 어제까지 잘 작동했는데, 이놈이 갑자기 업그레이드하고나니 안되네?
나도 지난 2주 동안 이런 문제를 두 번이나 마주쳤었다.
flameshot이 업그레이드 되면서 듀얼 모니터 스크린샷이 작동하지 않는다.nvidia driver가 업그레이드 되고서 nvidia-container-toolkit이 정상 동작하지 않는다.
이건 아치 리눅스가 rolling release, 그러니까 bleeding edge이기 때문에 발생한다. 항상 최신 패키지들을 다운받아서 사용하기 때문에, 기존에 사용하던 다른 패키지들과 호환성이 완벽하지 않은 상태가 가끔 발생하는 것이다. 혹은 최신 패키지 자체가 버그를 내포한 경우이기도 하다. (Rolling release가 아닌 debian 계열의 배포판들은 이런 문제를 마주칠 일이 거의 없다.)
그러면, 이런 상황에 우리는 어떻게 대처해야 할까? 내가 지난 2주 간 이 상황을 헤쳐나간 경험에 기반하여 그 대처 방법을 설명해볼까 한다.
어떤 대처 방법이 있을까?
우리는 이런 상황에 몇 가지 대처 방법을 생각해볼 수 있다.
- 안정성이 담보되어야하는 서버나 pc라면, debian 계열 등을 사용한다.
- 문제가 발생한 패키지의 공식 github에 가서 issue에 해당 버그를 보고하고 대처법을 문의하거나, 남들이 올린 issue에서 답을 찾는다.
- arch의 아카이브된 repo를 사용하여 문제가 발생하기 전 시점으로 rollback하여 임시로 사용한다.
본 포스트에서는 1번은 제외한다. 2번부터 먼저 살펴보도록 하자.
2번 방식: 문제가 발생한 패키지의 공식 github issue 살펴보기
우리가 겪고있는 문제는 우리만 발견하진 않았을 것이다. 더욱 linux에 친숙한 고급 사용자들이 존재하며, 그들은 이미 github issue에서 이에 대해 많은 논의를 진행했을 가능성이 크다.
앞서 말한 nvidia docker container 문제를 예로 한번 살펴보자.
나는 이 문제가 발생한 직후 다음의 사이트들을 돌며 비슷한 문제를 겪는 사람들이 올린 글이 없나 확인했다.
역시 많은 이들이 동일한 증상을 호소하고 있었고, 수많은 고수들이 이미 그 해결책을 제시하고 있었다. 이를 찬찬히 읽다보면 오류의 원인과 해결책을 발견하게 된다.
- 원인: nvidia driver가 업그레이드되면서 nvidia-container-toolkit의 legacy 방식으로는 gpu 자원에 대한 접근이 안되서 문제가 발생한 것. (결국 호환성 문제였다.)
- 해결책: 두 가지를 발견할 수 있었다.
- docker를 사용하되, legacy 대신 CDI를 사용하도록 강제하기
- podman을 쓰면 아무 문제 없이 동작하니, podman으로 넘어가기
나는 이 방법 중에서 2번 방식을 통해서 문제를 해결하기로 결정하고, 실제 문제를 해결했다. 지금은 아무 문제없이 동작하고 있다. 어떤가? 이렇게 조금만 조사하면 우리는 무엇이든 해결할 수 있는 시대에 살고 있다.
그럼, 이 방식으로도 답을 못찾았을 때 쓸 수 있는 임시 방편에 대해 알아보자.
3번 방식: Archive된 repo를 통해 문제 발생 시점 이전으로 rollback 하기
앞서본 2번 방식은 나 말고 누군가가 이미 문제를 인식했을 때 가능하다. 그러나, 혹시 내가 이 문제를 처음 발견한 사람이라면 어떨까?
그러면 아직 아무도 문제를 제기하지 않았고, 당연히 해결책도 찾아내지 못한 상태일 수 있다. 그러나, 내가 이를 스스로 해결할 수 있는 고수가 아니라면 어쩌지? 그때 우린 일단 후퇴하는 방식을 채택하면 된다.
아치 리눅스에서는 아주 고맙게도 매일매일의 패키지 리스트를 아카이빙하고 있다. 그래서 특정 문제가 발생하기 전 시점에 archive된 repo 주소를 source로 사용함으로써 문제가 발생하기 전 시점으로 돌아갈 수 있다. (정확히는 다운그레이드)
다시 nvidia 문제를 예시로 생각해보자. 내가 업그레이드한 시점이 8월 14일 정도였던 것 같다. 그러니까 그 시점보다 며칠 전 시점인 8월 10일 정도면 이 문제가 발생하기 않았을 것 같다고 추론했다. (더 이른 시점이어야 될 수도 있다.)
일단 8월 10일자 archive repo를 사용한다고 해보자. 해당 날짜의 archive repo 주소는 다음과 같다.
Server=https://archive.archlinux.org/repos/2025/08/10/$repo/os/$arch자 그럼, 우리가 원래 사용하던 source repo 주소를 이걸로 바꿔주면 된다.
source repo는 /etc/pacman.d/mirrorlist에 있다.
다음의 명령어를 통해, 기존의 파일을 backup해두고 위 주소를 담은 새로운 mirrorlist를 만들어준다. (sudo를 사용하니 명령어를 잘 검토하고 실행하자.)
# 기존 mirrorlist를 mirrorlist.backup으로 백업
sudo mv /etc/pacman.d/mirrorlist /etc/pacman.d/mirrorlist.backup# archive repo 주소가 포함된 새로운 mirrorlist 생성
echo "Server = https://archive.archlinux.org/repos/2025/08/10/\$repo/os/\$arch" | sudo tee /etc/pacman.d/mirrorlist그러면, 기존 mirrolist는 백업되었고, archive repo 주소가 담긴 새로운 mirrorlist 파일이 생성되었다.
이제 다음 명령어로, 새로운 mirrorlist에 맞춰 강제 downgrade 해주자.(과거 repo를 쓰니까 일종의 롤백)
sudo pacman -Syyuu그러면 안되던 nvidia-container-toolkit이 정상 작동한다. (덤으로 flameshot도 정상적으로 동작한다.) 문제가 발생하기 전 버전으로 다운그레이드 되었기 때문이다.
이 방식으로 일단 작동은 하게 만들 수 있었다.
그러나, 이 방식은 임시방편이란 것을 명심해야 한다.
지금처럼 과거 repo로 고정해둔 상태에서는 sudo pacman -Syu를 해도 최신버전으로 업그레이드가 되지 않는다.
그래서 이는 2번 방식으로 궁극적으로 해결하기 전까지만 사용해야 한다.
궁극적인 해결책을 찾았다면, 다음의 명령어들을 순차적으로 실행하여 원래 상태로 돌아가주자. (sudo를 사용하므로 잘 검토하고 실행해주자)
# 임시로 생성한 mirrorlist 제거
sudo rm /etc/pacman.d/mirrorlist# 원래 mirrorlist 복구
sudo mv /etc/pacman.d/mirrorlist.backup /etc/pacman.d/mirrorlist# 최신 상태로 update & upgrade
sudo pacman -Syu그리고, 찾은 해결책에 따라 근본적으로 문제를 해결해주면 된다.