[카테고리:] Linux

[Ubuntu] Bkouen MiniPC에 우분투 22.04 설치 후 발생했던 문제들 해결

다솜돌이 1 Comment

Bkouen Mini PC에 Ubuntu 22.04.01 server edition에 ubuntu-desktop을 설치한 이후 발생하는 문제들을 해결한 기록이다.

PCIe Bus 에러 발생 처리

아래의 ACPI Error가 난다. 그 후 이더넷 포트에 네트워크 케이블을 연결해두면 로그가 계속 찍히면서 콘솔을 사용할 수 없게 된다.


Feb 25 20:03:27 nas-ubuntu kernel: [    0.383989] pcieport 0000:00:1c.0: DPC: error containment capabilities: Int Msg #0, RPExt+ PoisonedTLP+ SwTrigger+ RP PIO Log 4, DL_ActiveErr+
Feb 25 20:03:27 nas-ubuntu kernel: [    0.384278] pcieport 0000:00:1c.1: PME: Signaling with IRQ 123
Feb 25 20:03:27 nas-ubuntu kernel: [    0.384343] pcieport 0000:00:1c.1: AER: enabled with IRQ 123
Feb 25 20:03:27 nas-ubuntu kernel: [    0.384387] pcieport 0000:00:1c.1: DPC: enabled with IRQ 123
Feb 25 20:03:27 nas-ubuntu kernel: [    0.384390] pcieport 0000:00:1c.1: DPC: error containment capabilities: Int Msg #0, RPExt+ PoisonedTLP+ SwTrigger+ RP PIO Log 4, DL_ActiveErr+
Feb 25 20:03:27 nas-ubuntu kernel: [    0.384652] pcieport 0000:00:1c.4: PME: Signaling with IRQ 124
Feb 25 20:03:27 nas-ubuntu kernel: [    0.384711] pcieport 0000:00:1c.4: AER: enabled with IRQ 124
Feb 25 20:03:27 nas-ubuntu kernel: [    0.384753] pcieport 0000:00:1c.4: DPC: enabled with IRQ 124
Feb 25 20:03:27 nas-ubuntu kernel: [    0.384756] pcieport 0000:00:1c.4: DPC: error containment capabilities: Int Msg #0, RPExt+ PoisonedTLP+ SwTrigger+ RP PIO Log 4, DL_ActiveErr+

...

Feb 25 20:03:27 nas-ubuntu kernel: [    0.385872] ACPI BIOS Error (bug): Could not resolve symbol [\\_SB.PR00._CPC], AE_NOT_FOUND (20210730/psargs-330)
Feb 25 20:03:27 nas-ubuntu kernel: [    0.385883]
Feb 25 20:03:27 nas-ubuntu kernel: [    0.385885] No Local Variables are initialized for Method [_CPC]
Feb 25 20:03:27 nas-ubuntu kernel: [    0.385887]
Feb 25 20:03:27 nas-ubuntu kernel: [    0.385889] No Arguments are initialized for method [_CPC]
Feb 25 20:03:27 nas-ubuntu kernel: [    0.385891]
Feb 25 20:03:27 nas-ubuntu kernel: [    0.385893] ACPI Error: Aborting method \\_SB.PR01._CPC due to previous error (AE_NOT_FOUND) (20210730/psparse-529)
Feb 25 20:03:27 nas-ubuntu kernel: [    0.385945] ACPI BIOS Error (bug): Could not resolve symbol [\\_SB.PR00._CPC], AE_NOT_FOUND (20210730/psargs-330)
Feb 25 20:03:27 nas-ubuntu kernel: [    0.385952]
Feb 25 20:03:27 nas-ubuntu kernel: [    0.385953] No Local Variables are initialized for Method [_CPC]
Feb 25 20:03:27 nas-ubuntu kernel: [    0.385955]
Feb 25 20:03:27 nas-ubuntu kernel: [    0.385956] No Arguments are initialized for method [_CPC]
Feb 25 20:03:27 nas-ubuntu kernel: [    0.385958]
Feb 25 20:03:27 nas-ubuntu kernel: [    0.385960] ACPI Error: Aborting method \\_SB.PR02._CPC due to previous error (AE_NOT_FOUND) (20210730/psparse-529)
Feb 25 20:03:27 nas-ubuntu kernel: [    0.386007] ACPI BIOS Error (bug): Could not resolve symbol [\\_SB.PR00._CPC], AE_NOT_FOUND (20210730/psargs-330)
Feb 25 20:03:27 nas-ubuntu kernel: [    0.386013]
Feb 25 20:03:27 nas-ubuntu kernel: [    0.386015] No Local Variables are initialized for Method [_CPC]
Feb 25 20:03:27 nas-ubuntu kernel: [    0.386016]
Feb 25 20:03:27 nas-ubuntu kernel: [    0.386018] No Arguments are initialized for method [_CPC]
Feb 25 20:03:27 nas-ubuntu kernel: [    0.386019]
Feb 25 20:03:27 nas-ubuntu kernel: [    0.386021] ACPI Error: Aborting method \\_SB.PR03._CPC due to previous error (AE_NOT_FOUND) (20210730/psparse-529)
Feb 25 20:03:27 nas-ubuntu kernel: [    0.386410] ACPI: \\_TZ_.TZ00: Invalid active0 threshold

Troubleshooting PCIe Bus Error severity Corrected on Ubuntu and Linux Mint

네트워크 케이블을 빼두고, 위 링크의 첫번째 해결책(Handling PCIe Bus Error messages if you can boot in to your Linux system)을 사용한다. Disable MSI 해결 방법의 경우 부팅이 안됐다.

# cp /etc/default/grub ~/grub.back
$ sudo vi /etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT 에 pci=noaer 을 추가.

GRUB_CMDLINE_LINUX_DEFAULT="pci=noaer"

아래 명령으로 grub을 업데이트한다.

$ sudo update-grub

위의 방법(”pci=noaer”)은 그냥 ‘Advanced Error Reporting’ 을 disable하는 것이다.

아래 내용도 참고하자. BIOS가 책임져야 하므로 커널 문제는 아니라고 한다. 위의 해결책을 적용해도 커널 로그에 에러는 여전히 찍힌다.

[Solved] ACPI errors during boot – Linux Mint Forums

sssd 설정

아래와 같은 sssd 실패 메시지가 보인다.

에러 메시지는 다음과 같다.

[DEPEND] Dependency failed for SSSD NSS Service responder socket.
[DEPEND] Dependency failed for SSSD AutoFS Service responder socket.
[DEPEND] Dependency failed for SSSD PAC Service responder socket.
[DEPEND] Dependency failed for SSSD PAM Service responder private socket.
[DEPEND] Dependency failed for SSSD PAM Service responder socket.
[DEPEND] Dependency failed for SSSD SSM Service responder socket.
[DEPEND] Dependency failed for SSSD Sudo Service responder socket.

sssd.conf 설정 파일을 /etc/sssd/ 아래에 넣자

$ sudo cp /usr/lib/x86_64-linux-gnu/sssd/conf/sssd.conf /etc/sssd/
$ sudo chmod 600 /etc/sssd/sssd.conf 
$ sudo systemctl enable sssd
$ sudo systemctl status sssd
$ sudo systemctl start sssd
$ sudo systemctl status sssd

reboot 나 halt 불가 해결

대기 모드 진입했다 다시 사용했다 하면 갑자기 GUI 진입 후 shell 에서 입력 출력 에러가 나오고, reboot나 halt도 안먹는다. 이런 에러가 나온다.

[!!!!!!] Failed to execute shutdown binary.

[22.04][EHL] can not shutdown and reboot

위 링크의 해결책을 사용했다.

sudo vi /etc/modprobe.d/blacklist.conf

아래 줄을 추가한다.

blacklist pinctrl_elkhartlake

이후 아래 명령을 실행한다.

sudo update-initramfs -u

그리고 재부팅.

[Ubuntu] cron-apt로 패키지 자동 업데이트 하기

다솜돌이 Leave a comment

2024.11.27. Update: 아래 내용 말고 https://blog.dasomoli.org/ubuntu-%ec%9e%90%eb%8f%99-%ec%97%85%eb%8d%b0%ec%9d%b4%ed%8a%b8-%ec%84%a4%ec%a0%95/ 을 사용해보자.

cron-apt를 설치하면 오전 4시에 알아서 패키지 업데이트를 해준다.

sudo apt-get install cron-apt

/etc/cron.d/cron-apt 파일 안에서 시간 설정을 바꿀 수 있다. 나는 오전 5시로 바꿨다.

root@bamtol:/etc/cron.d# cat /etc/cron.d/cron-apt
#
# Regular cron jobs for the cron-apt package
#
# Every night at 5 o'clock.
0 5	* * *	root	test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt
# Every hour.
# 0 *	* * *	root	test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt /etc/cron-apt/config2
# Every five minutes.
# */5 *	* * *	root	test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt /etc/cron-apt/config2

참고: https://help.ubuntu.com/community/AutoWeeklyUpdateHowTo

dd로 disk 전체 백업하기

다솜돌이 Leave a comment 
$ sudo apt-get install ntfs-3g
$ sudo fdisk -l
$ sudo mkdir /mnt/sdb5 && sudo mount.ntfs-3g /dev/sdb5 /mnt/sdb5
$ sudo dd if=/dev/sdc of=/mnt/sdb5/IMAGE_NAME_HERE.img bs=64K status=progress

미니 PC를 하나 샀다. SATA M.2 SSD 안에 Windows 10 Pro 정품이 깔려 있다. 이미지로 만들어서 백업하고 우분투 깔아야겠다.

[Docker] docker in docker의 Permission denied 문제

다솜돌이 Leave a comment

도커 컨테이너 안에서 도커를 사용하는 방법은 Host의 /var/run/docker.sock를 컨테이너에서 bind mount하면 된다. 쉽게 설명해 docker run 할 때 아래처럼 -v /var/run/docker.sock:/var/run/docker.sock 옵션을 주면 된다는 뜻이다. 물론 컨테이너 안에는 도커가 설치되어 있어야 한다. 

docker run -it --name ubuntu -v /var/run/docker.sock:/var/run/docker.sock ubuntu:20.04

이렇게 하면 도커 컨테이너 안에서 /var/run/docker.sock의 소유자가 root:docker 로 생기는데 이때의 그룹 id는 호스트의 그룹 id 값을 따르게 된다. 내 맥에서는 docker 그룹의 gid가 134이고, ubuntu 컨테이너의 docker 그룹의 gid는 1000이다.

$ cat /etc/group | grep docker # Host에서..
docker:x:134:dasomoli

컨테이너 안에서 /var/run/docker.sock를 살펴보면 아래처럼 소유자가 root:134 이다.

root@ce1351052f58:/# ls -l /var/run/docker.sock
srw-rw---- 1 root 134 0 Dec 21 13:19 /var/run/docker.sock

그러나 컨테이너 내에서 도커 설치 후 docker 그룹의 gid는 호스트의 gid인 134가 아닌 컨테이너 내부 환경에서 주어진다. 아래에서는 999이다.

root@ce1351052f58:/# cat /etc/group | grep docker
docker:x:999:

따라서 컨테이너 내부에서 root가 아닌 일반 유저로 도커를 사용하려고 하면 아래처럼 Permission denied 에러가 발생하게 된다.

$ id
uid=1000(dasomoli) gid=1000(dasomoli) groups=1000(dasomoli)

$ docker ps -a
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/json?all=1": dial unix /var/run/docker.sock: connect: permission denied

이 문제의 해결 방법으로 사람들이 이야기하는 방법은 chown으로 컨테이너 내부에서 owner를 root:docker 로 바꾸고 사용하는 방법, 또는 chmod로 아예 a+rw 를 주는 방법을 이야기하는데, chown으로 owner를 바꾸면 컨테이너 외부의 호스트 파일의 소유자 정보도 바뀌는 문제가 있다. 위의 docker의 gid가 컨테이너에서는 999, 호스트에서는 134인 경우에 컨테이너에서 chown root:docker를 해보면 호스트에서 gid가 999인 그룹에 속한 파일로 나온다. 즉, 호스트의 도커 실행 환경에 문제가 생긴다.

$ ls -l /var/run/docker.sock
srw-rw---- 1 root systemd-coredump 0 12월 21 22:19 /var/run/docker.sock # docker가 아니고 systemd-coredump 그룹 소유로 바뀌었다!!

$ cat /etc/group | grep systemd-coredump
systemd-coredump:x:999:

따라서 이 방법보다는 둘 모두의 docker 그룹의 gid를 맞춰주는 방법이 더 낫다. 컨테이너 안에서 groupmod로 다음을 실행한다. 아래에서 134는 호스트에서의 docker 그룹의 gid이다.

root@ce1351052f58:/# groupmod -g 134 docker

root@ce1351052f58:/# chown root:docker /var/run/docker.sock # 컨테이너가 실행 중이었다면 owner를 바꾼다.

root@ce1351052f58:/# ls -l /var/run/docker.sock
srw-rw---- 1 root docker 0 Dec 21 22:19 /var/run/docker.sock

호스트에서도 확인해보자.

$ ls -l /var/run/docker.sock
srw-rw---- 1 root docker 0 12월 21 22:19 /var/run/docker.sock

도커 이미지를 빌드할 때 Dockerfile 내에서 아예 먼저 해준다면, 실행 시에 따로 해주지 않아도 된다.

# Dockerfile 안의 내용
ARG HOST_DOCKER_GID="134"

RUN groupmod -g ${HOST_DOCKER_GID} docker

위의 Dockerfile로 도커 이미지를 빌드할 때는 다음과 같은 방식으로 넘겨도 된다.

$ docker build --build-arg HOST_DOCKER_GID=$(stat -c "%g" /var/run/docker.sock) -t ubuntu20.04

위에서 사용한 호스트에서 docker 그룹의 gid를 얻는 방법은 “[Linux/Mac] group id 얻기” 글을 참조한다. 호스트와 컨테이너 둘 간의 gid 충돌은 유의하자.

[Linux/Mac] group id 얻기

다솜돌이 Leave a comment

그룹 이름으로부터 GID 얻기

$ getent group <GROUP_NAME> | cut -d: -f3

예를 들어, docker 그룹의 gid를 얻고 싶다면

$ getent group docker | cut -d: -f3

파일의 소유 그룹의 GID 얻기

어느 파일의 소유 그룹의 gid를 얻고 싶다면.

$ stat -c "%g" <FILE_NAME>

예를 들어, /var/run/docker.sock의 소유자가 root:docker일 때 docker의 gid를 얻고 싶다면

$ stat -c "%g" /var/run/docker.sock

[Ubuntu] 20.04에서 Jenkins 설치하기

다솜돌이 Leave a comment

1. java 설치되어 있는지 확인(java -version) 후 없으면 open-jdk 설치

sudo apt-get install openjdk-8-jdk

2. repository 키 추가

wget -q -O - https://pkg.jenkins.io/debian-stable/jenkins.io.key | sudo apt-key add -

3. sources.list 에 추가

sudo sh -c 'echo deb http://pkg.jenkins.io/debian-stable binary/ > /etc/apt/sources.list.d/jenkins.list'

4. jenkins를 apt-get 으로 설치

sudo apt-get update && apt-get install jenkins

5. Jenkins 시작

sudo systemctl start jenkins

6. 혹시 방화벽 있으면 열기

sudo ufw allow 8080

7. http://IP:8080 으로 Jenkins 최초 접속. Administrator password는 아래에서 얻는다.

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

그 다음은 그냥 쭉쭉 진행! 생략…

참고: https://www.digitalocean.com/community/tutorials/how-to-install-jenkins-on-ubuntu-20-04

[Linux] KVM의 Bridge mode network 사용 시 네트워크 사용 불가 문제

다솜돌이 Leave a comment

KVM 사용 시 Bridge mode로 GuestOS에 네트워크 셋팅을 해도 동작을 안하는 경우가 있다. 게이트웨이나 DNS로 ping조차 안가는데, docker 와 함께 사용 시 문제가 발생한다.

docker가 iptables 의 FORWARD chain의 정책을 DROP으로 해버리기 때문이다.

oot@justiny-desktop:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy DROP)
target     prot opt source               destination         
DOCKER-USER  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain DOCKER (1 references)
target     prot opt source               destination         

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination         
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            
RETURN     all  --  anywhere             anywhere            

Chain DOCKER-ISOLATION-STAGE-2 (1 references)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere            
RETURN     all  --  anywhere             anywhere            

Chain DOCKER-USER (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere

다음처럼 해주면 잘된다.

# iptables -A FORWARD -i br0 -o br0 -j ACCEPT

[Linux][bash] git branch를 prompt에 넣기

다솜돌이 Leave a comment

~/.bashrc 에 다음을 추가.

parse_git_branch() {
     git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/'
}
export PS1="\u@\h \[\033[32m\]\w\[\033[33m\]\$(parse_git_branch)\[\033[00m\] $ "
#  PS1="${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[33m\]\$(parse_git_branch)\[\033[00m\]$ "

[Windows+Linux] WSL 사용 시 참고

다솜돌이 Leave a comment

Ubuntu 20.04 내의 파일 저장 경로

WSL 1

%localappdata%\Packages\CanonicalGroupLimited.Ubuntu20.04onWindows어쩌고저쩌고\LocalState\rootfs\

예를 들어, C:\Users\dasom\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu20.04onWindows_79rhkp1fndgsc\LocalState\rootfs

WSL 2

\\wsl$ 를 입력하면 배포판이 보인다.

\\wsl$\Ubuntu-20.04

GUI

Xming 같은 Xserver를 사용해서 WSL로 설치한 Ubuntu 등에서 GUI 를 사용할 수 있다.

WSL 1을 WSL 2로 변환하기

WSL로 설치한 항목은 다음으로 확인 가능하다.

wsl -l -v

여기서 WSL Version이 1인 것을 다음과 같이 2로 바꿀 수 있다. 예제로 Ubuntu-20.04 를 바꾸고 싶다면 다음과 같이 하면 된다.

wsl --set-version Ubuntu-20.04 2

실행 시 기본 유저 바꾸기

명령 프롬프트에서 다음을 실행한다.

ubuntu config --default-user new_dasomoli

참고

아래 글이 매우 정리가 잘 되어 있다.

[go] Ubuntu 에서 go 여러버전 사용하기

다솜돌이 Leave a comment

Ubuntu 리눅스에서 go의 여러 버전을 심볼릭 링크로 사용할 때 update-alternatives로 셋팅해서 사용하자.

# update-alternatives --install /usr/local/go go /usr/local/go1.17.2 1
update-alternatives: using /usr/local/go1.17.2 to provide /usr/local/go (go) in auto mode

# update-alternatives --install /usr/local/go go /usr/local/go1.16.8 2
update-alternatives: using /usr/local/go1.16.8 to provide /usr/local/go (go) in auto mode

# update-alternatives --install /usr/local/go go /usr/local/go1.14.15 3
update-alternatives: using /usr/local/go1.14.15 to provide /usr/local/go (go) in auto mode

# update-alternatives --config go
대체 항목 go에 대해 (/usr/local/go 제공) 3개 선택이 있습니다.

  선택       경로                우선순� 상태
------------------------------------------------------------
* 0            /usr/local/go1.14.15   3         자동 모드
  1            /usr/local/go1.14.15   3         수동 모드
  2            /usr/local/go1.16.8    2         수동 모드
  3            /usr/local/go1.17.2    1         수동 모드

현재 선택[*]을 유지하려면 <엔터>를 누르고, 아니면 선택 번호를 입력하시오:
#