아이패드 방전

아이패드를 한창 쓰다가 출/퇴근에 정신없어서 거의 안쓰다가, 다시 쓰려고 하니 방전으로 켜지지 않는다.
부팅을 하려고 하면 방전 이미지만 출력되고, 일단 충전이 되야 부팅이 되겠구나 했는데, 하루종일 충전을 해놨지만 부팅이 되지 않았다.
결국 정상 부팅에는 성공했는데, 별거는 아니지만 증상과 필자의 해결 방법을 기록으로 남겨 놓는다.

증상

부팅이 안됨

부팅이 되지 않는다. 강제 재부팅 방법(음량 up, 음량 down 순서대로 누르고 전원 버튼 20초 누르고 있기)도 어디에서 봤는데 누르고 있어도 부팅은 되지 않는다.

고속 충전 불가

고속 중전이 아이패드에서 지원되서 빠르게 충전하기 위해서 고속 충전을 하루 종일 꽂아 놓았지만 당연히 다음날 부팅을 시도했지만 부팅이 되지 않는다. 전력 측정이 되는 충전기에서 충전을 붙여서 테스트를 해보았는데, 충전 전류량이 0W로 보인다.

방법

저속 충전

완전 방전시 아이패드에서 고속 충전이 되지 않는다(PD 충전).
5W 저속 충전기에 물려놓으면 5W가 충전되는 것을 확인하였다.

저속충전으로 2시간 이상 충전 필요

저속 충전으로 1시간 이상 충전을 시켰으면 충분했을 것 같아서 부팅을 시도했으나, 부팅을 시도했을 때에 아직도 충전 표시 화면만 나와서 아이패드가 고장이 났는 줄 알았다. 할 수 있는 것은 저속 충전 뿐이라 2시간 이상 충전을 해놓았더니 1%로 부팅이 되었다. 케이블을 뺐을 때에 바로 꺼지는거 봐서는 2시간 정도 충전을 했을 때에 간신히 부팅 정도 되게끔 충전이 된 것 같다(오래된 아이패드라서 배터리의 상태가 최상이 아니라서 그럴 수도 있다).

부팅 이후 고속 충전 가능

부팅 이후 어느정도 충전량이 확보가 되면, 고속 충전을 하기위한 프로토콜이 동작하는 것으로 보였다.
부팅 전에는 PD충전을 물리면 고속 충전이 안되었지만, 어느정도 충전량을 확보한 뒤에는 부팅상타에서는 다시 고속 충전을 순차적으로 올라가서 고속 충전이 되는 것을 확인했다.

Default 위치

${HOME}/.cache/huggingface

변경 방법

.py 코드 내 os env 변경

...
os.environ["HF_HOME"] = "/workspace/"
import torch
...

bashrc 반영

export HF_MOME=/workspace

오류 현상

아이폰 16을 샀고, 숫자를 입력하면 3~4 글자 까지는 정상적으로 작성되다가, 그 이상이 되면 특정 숫자를 반복하는 등의 문제가 생긴다.
특히 은행앱등에서도 잘못사용되면서 시껍한 적이 한두번이 아니라서, 숫자 패드를 빠르게 작성하다가, 지금은 숫자 하나 하나씩 세는데,
긴 숫자 배열을 입력할 때에는 이게 눈에 익지도 않고 짜증이 많이 난다.

오류 내용

iOS 18.1에서 이중언어 신규 기능이 생겼다. 필자도 항상 영어를 쓸 때에 귀찮았는데, 신기해 하면서 해당 키보드로 변경을 했다.
문제는 이 이중언어의 키보드에 오류가 있다는 것이다. 이것이 단순 String의 Pattern matching으로 동작하는 것이 아닌 학습된 소형 언어 모델을 사용하는 것 같다. 이 모델이 동작을 하며 키보드에서 무언가가 입력되었을 때에 자동 보정이 동작하면서 숫자가 잘못 입력되는 현상으로 보인다.

이중언어 키패드와 같은 경우에는 분명 이중언어 키패드를 쓰고 있다는 것을 알 수 있게 키패드의 특성이 눈으로 보인다. 다만 숫자 키패드는 이중언어 키패드와 상관이 없는 키패드이지만 이 이중언어 키패드의 영향을 받고 있다는 것이 놀랍고 아쉽다.

당분간은 이중언어 키보드를 사용하지 말자.

한국어 영어 각 단어와 언어의 특성이 있기 때문에 처음에 쓸 때에는 아주 잘 되는 것 처럼 보인다.
다만 한국어의 각 순서가 영어단어 혹은 영어 줄임말 조금이라도 Matching되면 한글로 사용이 안되고 이상한 영어 단어로 변경이 된다.
한/영 모드를 따로 쓸 때에는 오타가 날 지언정 해당 언어로 사용되기 때문에, 오타가 나면 해당 언어로 바꿔서 사용하면 되지만,
이것은 굳이 이중언어/한/영 세가지 키보드로 번갈아 가면서 그 단어를 치기 위해 또 키보드를 변경해야 한다.

특히 숫자가 자동완성 되는 것은 생각도 못했는데, 위에 언급했듯이 은행 어플 등에서 자동 완성이 될 경우, 실제로 위험하다.
난 11,500을 입금하려 했지만 1,115,500 이 입금되면, 이건 단순히 문자 작성 오류가 아니라 은행 이슈로 돈을 돌려받기 쉽지 않을 것이다.
이 오류는 너무 명백해서 금방 수정 패치가 될 것으로 보이지만(애플이 이런 단순한 QA도 되지 않고 릴리즈가 되다니 앱등이로써 충격이다), 이중언어 키보드의 편리함을 경험하기 위해 시작했다가, 이중언어 키보드를 안쓰는게 좋겠다 라는 경험만 가지게 된 것 같아서 무척이나 아쉽다.

Kernel 버전

커널버전은 항상 설치된 버전 중에서 최 상위 버전으로 항상 default로 선택 가능하게 되어 있다.
드라이버는 커널 버전에 정확한 숫자에 의존성을 가지고 있기 때문에 사용하는 드라이버가 특정 버전 커널에만 의존적이거나 지원이 된다면, 커널 버전이 올라갈 경우 해당 디바이스는 사용이 불가하기 때문에 가끔 특정 커널 버전에 고정을 해야 하는 경우가 있따.

Kernel 과거 버전 고정하기

현재 설치된 커널 버전 확인

$ sudo dpkg --list | egrep -i --color 'linux-image|linux-headers'

이 명령어로 앞에 ii 또는 ic 라고 나올 수 있는데 각 의미는 아래와 같다.

• ii : ‘It should be installed and it is installed’
• rc : ‘It’s removed/uninstalled but it’s configuration files are still there’
  당연하지만 이미 설치된 커널 버전 으로 고정이 가능하다.
  설치가 되지 않았을 경우에는 원하는 커널을 설치 후에 진행해야 한다.

명령어를 시행하면 아래의 형식으로 내용이 출력된다.

ii  linux-headers-6.5.0-18-generic             6.5.0-18.18~22.04.1                     amd64        Linux kernel headers for version 6.5.0 on 64 bit x86 SMP
ii  linux-headers-6.8.0-48-generic             6.8.0-48.48~22.04.1                     amd64        Linux kernel headers for version 6.8.0 on 64 bit x86 SMP
ii  linux-headers-generic-hwe-22.04            6.8.0-48.48~22.04.1                     amd64        Generic Linux kernel headers
ii  linux-image-6.5.0-18-generic               6.5.0-18.18~22.04.1                     amd64        Signed kernel image generic
ii  linux-image-6.8.0-48-generic               6.8.0-48.48~22.04.1                     amd64        Signed kernel image generic
ii  linux-image-generic-hwe-22.04              6.8.0-48.48~22.04.1                     amd64        Generic Linux kernel image

$menuentry_id_option

menuentry_id_option은 GRUB에서 설정에서 사용되는 옵션으로 각 부팅의 항목의 UUID로 사용된다. 이것은 GRUB Bootloader에서 여러개의 커널 항목에서 특정 항목에 사용되는 ID를 정의한다. 여기에 특정 커널의 UUID로 지정을 해줄 경우 Bootloader에서 해당 커널로 Boot sequence를 진행하게 된다.

$ grep submenu /boot/grub/grub.cfg 

명령어를 실행하면 아래와 같은 형식으로 출력된다.

submenu 'Advanced options for Ubuntu' $menuentry_id_option 'gnulinux-advanced-b7e9ad35-1a1f-45e3-9cfd-084a7ce27282' {

위의 출력 내용 중 gnulinux-advanced-b7e9ad35-1a1f-45e3-9cfd-084a7ce27282 내용을 아래에서 사용하니 저장해둔다.

Kernel 정보 확인

$ grep gnulinux /boot/grub/grub.cfg

커널에서 원하는 커널 정보를 확인한다.

menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-b7e9ad35-1a1f-45e3-9cfd-084a7ce27282' {
submenu 'Advanced options for Ubuntu' $menuentry_id_option 'gnulinux-advanced-b7e9ad35-1a1f-45e3-9cfd-084a7ce27282' {
  menuentry 'Ubuntu, with Linux 5.4.0-42-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.4.0-42-generic-advanced-b7e9ad35-1a1f-45e3-9cfd-084a7ce27282' {
  menuentry 'Ubuntu, with Linux 5.4.0-42-generic (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.4.0-42-generic-recovery-b7e9ad35-1a1f-45e3-9cfd-084a7ce27282' {
  menuentry 'Ubuntu, with Linux 5.4.0-39-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.4.0-39-generic-advanced-b7e9ad35-1a1f-45e3-9cfd-084a7ce27282' {
  menuentry 'Ubuntu, with Linux 5.4.0-39-generic (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.4.0-39-generic-recovery-b7e9ad35-1a1f-45e3-9cfd-084a7ce27282' {

만약에 위의 커널 정보 중에서 5.4.0-42-generic 을 사용하고 싶을 경우 gnulinux-5.4.0-42-generic-advanced-b7e9ad35-1a1f-45e3-9cfd-084a7ce27282을 사용하면 된다.

grub 설정

grub에 default에 대한 항목을 아래와 같이 설정해준다.

$ sudo vi /etc/default/grub

기본적으로 GRUB_DEFAULT=0으로 되어 있는데, 기본으로 가장 상위 버전으로 부팅이 되는 것으로 생각하면 된다.

GRUB_DEFAULT="gnulinux-advanced-b7e9ad35-1a1f-45e3-9cfd-084a7ce27282>gnulinux-5.4.0-42-generic-advanced-b7e9ad35-1a1f-45e3-9cfd-084a7ce27282"

아래와 같이 변경한 내용을 grub에 적용해준다.

$ sudo update-grub
$ reboot

부팅 이후에 원하는 버전으로 부팅이 되었는지 확인해보자

$ uname -a

fstab 수정시 옵션을 설정할 수 있는데 보통 구글링하면 defaults로 설정되어 있다.

여기서 default로 "s"를 빼고 작성시 리부팅할때 fstab 비정상 동작으로 boot sequence가 중단될 수 있다.

이럴 경우 ssh daemon이 정상적으로 뜨지 않아서 데이터 센터 등에 서버가 있을 경우 난감한 상황이 발생할 수 있다.

처음 작성할 때에 defaults가 아닌 nofail로 설정할 경우, 해당 설정이 정상적이지 않더라도 mount를 비활성화하고 boot sequence를 계속하게 할 수 있다.

차라리 그냥 다른 이유에서도 mount가 비정상 상황이 발생하더라도 nofail로 boot seqence를 계속하도록 수정하는게 중요할 것 같다.