Anything personal, something useful

씽크패드 요가 370에 슬랙웨어64 14.2 설치하기

요즘 출시되는 랩탑은 새로운 기술과 디바이스들을 장착하고 있는 경우가 많기 때문에 출시 간격이 상대적으로 긴 리눅스 배포판인 슬랙웨어의 경우 최신 하드웨어 지원이 잘 안 되는 경우가 종종 있다. 그래서 이 문서를 통해서 씽크패드 요가 370에 어떻게 슬랙웨어64 14.2를 설치했는지 정리해 본다.

1   기본적인 설치

슬랙웨어64 14.2 DVD를 넣고 부팅을 하니 프롬프트까지 문제없이 진행되었다. 지금까지와는 달리 BIOS가 아닌 UEFI로 부팅이 되기 때문에 초기 인터페이스가 조금 달랐다. LILO가 아닌 GRUB으로 커널을 로드했다. 뭐 그 다음은 똑같았다. 파티션을 나누고자 fdisk를 다음과 같이 실행했다.

fdisk /dev/nvme0n1

그런데 BIOS가 아닌 UEFI로 부팅하기 때문에 MBR 대신 EFI 파티션을 생성해야 했다. 그래서 gdisk를 실행했다.

gdisk /dev/nvme0n1

파티션을 다음과 같이 생성했다.

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          206847   100.0 MiB   EF00  EFI System
   2          206848        21178367   10.0 GiB    8200  Linux swap
   3        21178368       105064447   40.0 GiB    8300  Linux filesystem
   4       105064448       976773134   415.7 GiB   8300  Linux filesystem

처음으로 써 보는 SSD에 대해 공부를 해보니 복수의 섹터를 단위별로 쓰고 읽기 때문에 파티션이 시작되는 섹터를 잘 정렬해 줘야 최적의 성능이 나온다고 했다. 그러고 보니 gdisk는 기본적으로 2048 섹터 단위로 파티션을 자동생성해 줬다. 2048 섹터면 2048 sectors * 512 bytes / sector / 1024 / 1024 = 1 MiB 크기이다. 선택할 수 있는 가장 빠른 섹터가 34였기 때문에 34를 선택해 봤지만 자동으로 2048로 생성을 해 줬다. 그런데 모든 파티션을 생성한 다음 새로운 파티션을 하나 더 생성할 수 있는데 그때 비어 있는 34-2047 섹터를 쓸 수 있었다. 하지만 1 메가바이트짜리 파티션은 필요도 없고 정렬도 되지 않았기에 만들지는 않았다.

이렇게 파티션을 만들고 setup을 진행했다. 모든 패키지를 문제없이 설치한 다음 LILO는 설치를 못 하니 ELILO를 실행할 거라는 화면이 떠서 그렇게 하자고 하니까 ELILO 화면은 온 데 간 데 없고 마우스 세팅 화면이 떴다. 뭔가 잘못 되었다는 것을 직감했다.

2   eliloconfig의 NVMe 디바이스 인식 버그

역시 NVMe 디바이스 이름의 포맷을 제대로 처리하지 못 하는 버그가 있었다. 패키지를 다 설치한 다음 검색을 해보니 몇가지 방법이 있었다. 우선 부팅 ISO 이미지를 새롭게 만든 것을 쓰는 방법이 있었다. 편한 방법이지만 설치를 위해 USB 드라이브를 하나 희생해야만 한다. 다음으로는 수작업으로 ELILO를 설치하는 방법이 있었다. 후자의 방법이 손길이 좀 가지만 더 마음에 들었다. 이런 과정을 거치지 않고 그냥 부팅을 해버리면 이전에 설치했던 윈도의 EFI가 부팅을 시도하다가 윈도를 찾지 못 했다는 오류가 뜬다. 이 경우 다시 설치 DVD로 부팅해서 패키지 선택까지 가서 아무 패키지도 설치하지 않고 앞서 언급한 방법으로 ELILO를 제대로 설치해야 한다.

# EFI 파티션을 FAT32로 포맷
mkfs.vfat -F32 /dev/nvme0n1p1

# 올바른 디렉토리로 마운트
mkdir /mnt/boot/efi
mount /dev/nvme0n1p1 /mnt/boot/efi

# eliloconfig를 복사
cp /mnt/usr/sbin/eliloconfig .

# eliloconfig를 수정
vi eliloconfig
# 다음의 변수를 하드코딩한다.
# EFI_DEVICE=/dev/nvme0n1
# EFI_PARTITION=1

# 이제 수정한 eliloconfig를 실행한다. /dev/nvme0n1p3는 / 파티션이다.
./eliloconfig /mnt /dev/nvme0n1p3

vi /mnt/etc/fstab
# /etc/fstab에 EFI 파티션을 추가한다.
# /dev/nvme0n1p1 /boot/efi vfat defaults 0 2

이제 재부팅을 하면 슬랙웨어가 제대로 부팅된다.

3   와이파이 카드

그러나 슬랙웨어64 14.2에 포함된 리눅스 커널 4.4.14는 요가 370 안에 있는 와이파이 카드를 인식하지 못 했다. 그래서 다음과 같이 와이파이 카드의 ID를 확인했다.

lspci -nn | grep -i network

이 ID를 검색해서 와이파이 카드의 모델번호를 확인했다. 역시나 Intel Wireless 8265는 커널 4.6부터 지원했다. 그래서 커널 4.6을 컴파일하려다가 그냥 슬랙웨어64 Current에 포함된 커널 4.14.14를 시도해 보기로 했다. 그러는 김에 eliloconfig의 버그도 수정한 elilo 3.6도 같이 설치했다. 다음의 패키지들을 설치했다:

  • a/elilo-3.16-x86_64-5.txz
  • a/kernel-firmware-20180104_65b1c68-noarch-1.txz
  • a/kernel-generic-4.14.14-x86_64-1.txz
  • a/kernel-huge-4.14.14-x86_64-1.txz
  • a/kernel-modules-4.14.14-x86_64-1.txz
  • d/kernel-headers-4.14.14-x86-1.txz
  • k/kernel-source-4.14.14-noarch-1.txz

그리고 generic 커널 4.14.14를 다음과 같이 EFI 파티션에 설치했다.

cd /boot
for i in System.map config vmlinuz; do
  ln -sf $i-generic-4.14.14 $i
done
for i in generic huge; do
  ln -sf vmlinuz-$i-4.14.14 vmlinuz-$i
done
mkinitrd -c -k 4.14.14 -m nvme:ext4
eliloconfig

재부팅을 하니 와이파이 카드가 인식되었고 연결도 문제가 없었다.

4   하이버네이션

이제 하이버네이션을 설정했다. resume=/dev/nvme0n1p2 커널 옵션을 /boot/efi/EFI/Slackware/elilo.conf 파일 안에 있는 append=에 추가한 다음 pm-hibernate를 실행해 봤다. 5초도 안 되어서 하이버네이션이 되었다. 감동적인 순간을 뒤로하고 리쥼한 다음 다시 하이버네이션을 시도했다. 아! 좋은 시간도 금방 가버리고 하이버네이션이 안 되는 것이 아닌가? 전원버튼을 꾹 눌러서 재부팅을 하고 다시 해보니 또 5초도 안 되어서 하이버네이션이 잘 되었다. 다시 킨 다음 시도해 보니 또 다시 안 되었다. 그래서 그냥 기다려 봤다. 그랬더니 약 3분 뒤에 하이버네이션이 되는 것이 아닌가? 리쥼도 문제 없었다.

문제가 뭘까? /var/log/message 파일을 보니 Syncing filesystems와 done 사이에 그 3분이란 시간이 흘러간 것이 보였다. 그래서 쓰기 버퍼를 SSD로 써 내는데 문제가 있을까 싶어서 해당 메시지를 커널 소스에서 찾아 봤다. kernel/power/hibernate.c 파일 안에 hibernate()이라는 함수가 이 메시지를 출력하고 있었다. 이 두 줄 사이에 sys_sync() 함수를 호출하고 있었다. 그래서 이 줄을 주석처리하고 커널을 다시 컴파일한 다음 시도해 보니 변화가 없었다. 그래서 SSD의 읽기 쓰기 성능을 하이버네이션 사이에 비교해 봤지만 크게 다르지 않았다.

# hdparm을 이용한 읽기 테스트
hdparm -Tt --direct /dev/nvme0n1

### after a fresh boot
# cached reads: 1069.68 MB/sec
# disk reads:   1478.48 MB/sec

### after a resume
# cached reads: 1034.49 MB/sec
# disk reads:   1536.72 MB/sec

# dd를 이용한 쓰기 테스트
sync; dd if=/dev/zero of=tempfile bs=1M count=1024; sync

# dd를 이용한 버퍼에서 읽기 테스트
dd if=tempfile of=/dev/null bs=1M count=1024

# dd를 이용한 읽기 테스트
sysctl -w vm.drop_caches=3; dd if=tempfile of=/dev/null bs=1M count=1024; sysctl -w vm.drop_caches=0

### after a fresh boot
# write:       1.3 GB/sec
# buffer read: 9.1 GB/sec
# real read:   2.8 GB/sec

### after a resume
# write:       1.3 GB/sec
# buffer read: 9.3 GB/sec
# real read:   2.8 GB/sec

그래서 SSD의 문제는 아니라는 결론을 내리고 여러 줄에 걸쳐서 디버그 메시지를 추가한 다음 하이버네이션을 반복해서 해봤다. 그랬더니 3분 지연의 위치가 살짝씩 바뀌는 것이 아닌가? 가만히 생각해 보니 디버그 메시지를 출력할 때마다 쓰기 버퍼를 비워줘야 /var/log/message로 제대로 된 시간과 함께 출력될 것이 아닌가? 그래서 디버그 메시지 바로 뒤에 sys_sync()를 모두 붙였다. 그랬더니 kernel/power/process.c 파일에 있는 try_to_freeze_tasks() 함수 안에 있는 for_each_process_thread(){} 루프 안에서 지연이 일어나는 것을 발견했다. 그래서 각 쓰레드의 이름을 시간과 함께 출력해 보니 syslogd를 얼리면서 지연이 발생하는 것을 관찰했다. 그래서 syslogd를 얼리지 않고 넘어 가니 바로 다음 쓰레드인 klogd에서 지연이 발생했다. klogd도 얼리지 않으니 하이버네이션이 전혀 되지 않고 엔터키와 콘솔만 바꿀 수 있을 뿐 다른 키는 전혀 먹히지 않았다. 다시 생각을 해보니 syslogd가 어는 순간 그 다음의 디버그 메시지들은 리쥼해서 syslogd가 살아날 때까지는 출력이 되지 않을 것이다. 따라서 syslogd 때문에 뒤늦게 출력되는 디버그 메시지로는 더 이상 어떤 쓰레드가 범인인지 찾아 낼 수가 없게 되었다. 슬랙웨어64 Current를 테스트해 볼 수도 있으나 결국은 같은 커널 4.14.14를 쓰고 있으니 같은 문제가 있지 않을까 싶다.

4.1   커널 4.6 테스트

커널 4.14.14가 하이버네이션에 문제가 있으니 와이파이 카드를 지원하기 시작한 커널 4.6을 테스트하기로 했다. 우선 커널의 config 파일을 슬랙웨어64 14.2에 포함된 testing/source/linux-4.6-configs/config-huge-4.6.x64를 이용하기로 했다.

cd /usr/src
tar xvf linux-4.6.tar.xz
cd linux-4.6
cp /slackware64-14.2/testing/source/linux-4.6-configs/config-huge-4.6.x64 .config
make bzImage modules modules_install
cp arch/x86/boot/bzImage /boot/efi/EFI/Slackware/vmlinuz
reboot

재부팅이 깔끔하게 될 것이라 예상했지만 부팅하면서 크래쉬됐다. 설치 DVD로 부팅해서 커널 4.14.14로 복구한 다음 부팅해서 .config 파일을 살펴 보니 필수인 NVMe 관련 설정들이 모두 모듈로 컴파일되게 되어 있었다. 슬랙웨어64 14.2에 포함된 커널 4.4.14의 huge 커널에는 포함되어 있는 걸 보면 config-huge-4.6.x64를 만들면서 실수를 한 것 같았다. 아무튼 다음의 설정들을 모두 m에서 y로 바꿨다.

CONFIG_NVME_CORE=y
CONFIG_BLK_DEV_NVME=y

그리고 커널을 다시 컴파일했다.

make clean
make bzImage
cp arch/x86/boot/bzImage /boot/efi/EFI/Slackware/vmlinuz
reboot

이제 부팅이 제대로 되었다. 그런데 지원이 된다던 와이파이 카드 8086:24FD는 인식되지 않았다. 다음 명령으로 이 카드의 서브시스템 ID를 확인해 봤다.

lspci -v

이 카드의 서브시스템 ID는 0130이었다. 다음의 명령으로 iwlwifi 모듈이 이 카드를 지원하는지 확인해 봤다.

modinfo iwlwifi | grep 8086.*24FD
modinfo iwlwifi | grep 8086.*24FD.*0130

다른 서브시스템은 지원을 하는데 0130만 빠져 있었다.

어차피 쓸 수 없는 커널이지만 하이버네이션을 테스트해 봤다. 제대로 안 됐다.

4.2   커널 4.9.77 테스트

이제 이 답변자의 경험과 추천을 바탕으로 커널 4.9.77을 테스트하기로 했다. 컴파일은 커널 4.6과 마찬가지로 다음과 같이 진행됐다.

cd /usr/src
tar xvf linux-4.9.77.tar.xz
cd linux-4.9.77
cp /slackware64-14.2/testing/source/linux-4.6-configs/config-huge-4.6.x64 .config
make oldconfig # 이 명령을 실행한 다음 새로운 설정에 기본값을 할당하기 위해 엔터를 계속 누르고 있었다.
vi .config
# 다음의 NVME 설정들을 m에서 y로 바꾸었다.
# CONFIG_NVME_CORE=y
# CONFIG_BLK_DEV_NVME=y
make bzImage modules modules_install
cp arch/x86/boot/bzImage /boot/efi/EFI/Slackware/vmlinuz
reboot

까~~~알끔하게 부팅이 되었다. 무선 인터넷도 잘 됐다. 대망의 하이버네이션 테스트 시간이 됐다. pm-hibernate을 실행하니 금방 하이버네이션이 되었다. 리쥼하고 드디어 두번째 pm-hibernate를 실행하는 순간 가슴이 두근거렸다. 처음보다 몇초 늦은 감이 있었지만 5초도 안 되어서 하이버네이션이 완료되었다! 다음은 테스트 결과이다:

횟수소요시간
1회5.1초
2회5.7초
3회14초
4회12초
평균9.2초

감격의 눈물이 날 뻔 했다.

5   하이버네이션 속도 비교

다른 두 개의 씽크패드 랩탑과 하이버네이션 속도를 비교해 봤다.

모델메모리소요시간
X2018GB약 18초
W52032GB약 1분 9초
Yoga 3708GB평균 9.2초

요가 370의 속도가 월등하게 빠른 것을 확인할 수 있었다.

6   하이버네이션 문제의 주범

위와 같이 모두 설치하고 1월 20일 토요일날 룰루랄라 프로그램들을 설치하면서 테스트를 했다. 그런데 화면 회전용 센서를 인식하는 모듈이 커널 4.9에 처음 도입되면서 커널 4.6 테스트용으로 제공된 config로는 이 모듈을 기본적으로 컴파일하지 않고 있었다. 이 모듈이 intel-ish-hid인 것을 어떻게 알았냐면은 커널 4.14.14를 테스트할 때 화면을 자동으로 돌려 주는 프로그램이 제대로 작동했었는데 4.9.77에서는 안 되는 것을 확인하고서 두 버전에서 lspci -v를 돌려서 출력을 비교해 봤다. 그랬더니 디바이스 하나가 4.14.14에서만 intel-ish-ipc 드라이버로 구동되고 있었다. 그래서 두 config 파일을 비교하면서 INTEL_ISH라는 문자열을 찾아 보니 INTEL_ISH_HID=m라는 줄이 4.14.14에만 있었고 4.9.77에서는 컴파일 자체를 하지 않고 있었다. 4.9.77에서 이 모듈을 기본적으로 컴파일을 하지 않고 있었던 것이다. 그래서 이 모듈을 컴파일하고 4.9.77을 재부팅하니 센서가 제대로 작동했다.

여기까지 좋았다. 그런데 하이버네이션 문제가 다시 돌아 온 것이 아닌가? 그래서 해당 모듈의 파일들을 없애고 테스트해 보니 다시 하이버네이션에 문제가 없었다. 이렇게 우연히 하이버네이션 문제의 주범을 찾는 순간이었다. 센서와 하이버네이션 둘 다 살릴 수는 없을까 생각을 하며 모듈을 메모리에서 제거하는 테스트를 해 봤지만 제거 후 시스템이 불안정해졌다. 이 모듈이 구동하는 하드웨어를 하이버네이션 직전에 비활성화하는 방법을 찾아 봤지만 실패했다. 그래서 화면 회전 따위는 수작업으로 하기로 결심하고 더 유용한 하이버네이션을 살리기로 했다.

커널 4.9.77이나 4.14.14나 같은 문제가 있으니 더 최신 버전인 커널 4.14.14를 슬랙웨어64 Current에서 가져와 설치를 하고 문제가 되는 모듈들을 다음과 같이 블랙리스팅함과 동시에 다른 모듈에 의해 로드되지 않게 설정했다.

cat <<EOT > /etc/modprobe.d/intel-ish-hid.conf 
# by geni
# /etc/modprobe.d/intel-ish-hid.conf
# These modules drive the Intel Sunrise Point-LP Integrated Sensor Hub, but
# they cause a long delay in hibernation.

install intel_ish_ipc /bin/false
install intel_ishtp /bin/false
install intel_ishtp_hid /bin/false
EOT

7   인텔 ISH 모듈 패치하기

drivers/hid/intel-ish-hid/ipc/pci-ish.c 패치파일: pci-ish.c.patch

거의 2년이 지난 쓰레드에서 인텔의 소프트웨어 엔지니어인 Srinivas Pandruvada가 느린 하이버네이션 문제를 해결했다고 언급했다. 그에게 2018년 5월 6일 이에 대한 문의 이메일을 보내니 바로 다음날 Even Xu의 패치와 함께 답변이 왔다. 패치파일을 만들어 drivers/hid/intel-ish-hid/ipc/pci-ish.c 파일을 패치한 후 모듈을 다시 컴파일하고 설치했다. 재부팅한 다음 여러번 테스트한 결과 하이버네이션이 정상적으로 작동하는 것을 확인했다. ISH로 구동되는 센서도 잘 작동하는 것을 확인할 수 있었다. 이 패치를 적용한 후에는 위의 /etc/modprobe.d/intel-ish-hid.conf 파일을 삭제해야 된다.

cd ~/usr/local/src/linux-4.14.14
(cd drivers/hid/intel-ish-hid/ipc; patch < pci-ish.c.patch)

# 다음과 같이 ISH 모듈만 컴파일하면 정의되지 않은 심볼이 있다는 경고와 함께 하이버네이션 문제가 해결되지 않았다.
# make modules SUBDIRS=drivers/hid/intel-ish-hid

# 그래서 아예 커널와 모든 모듈을 재컴파일하니까 하이버네이션 문제가 해결되었다.
make bzImage modules

# 새롭게 컴파일된 모듈을 설치한다.
cp drivers/hid/intel-ish-hid/*.ko /lib/modules/4.14.14/kernels/drivers/hid/intel-ish-hid

다음은 Even Xu의 설명이다.

Subject: Re: [PATCH] hid: intel_ish-hid: ipc: register more pm callbacks to support hibernation
From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
To: Even Xu <even.xu@intel.com>, linux-input@vger.kernel.org
Cc: andriy.shevchenko@intel.com, Huidae Cho <grass4u@gmail.com>
Date: Mon, 07 May 2018 08:13:09 -0700

On Mon, 2018-05-07 at 08:28 +0800, Even Xu wrote:
> Current ish driver only register resume/suspend PM callbacks which
> don't support hibernation (suspend to disk). Now use the
> SIMPLE_DEV_PM_OPS() MACRO instead of struct dev_pm_ops directly.
> The suspend and resume functions will now be used for both suspend
> to RAM and hibernation.
> 
> If power management is disable, SIMPLE_DEV_PM_OPS will do nothing,
> the suspend and resume related functions won't be used, so mark them
> as __maybe_unused to clarify that this is intended behavior, and
> remove #ifdefs for power management.
> 
> Signed-off-by: Even Xu <even.xu@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>

> ---
>  drivers/hid/intel-ish-hid/ipc/pci-ish.c | 22 +++++++---------------
>  1 file changed, 7 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> index 582e449..a2c53ea 100644
> --- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> +++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> @@ -205,8 +205,7 @@ static void ish_remove(struct pci_dev *pdev)
>  	kfree(ishtp_dev);
>  }
>  
> -#ifdef CONFIG_PM
> -static struct device *ish_resume_device;
> +static struct device __maybe_unused *ish_resume_device;
>  
>  /* 50ms to get resume response */
>  #define WAIT_FOR_RESUME_ACK_MS		50
> @@ -220,7 +219,7 @@ static struct device *ish_resume_device;
>   * in that case a simple resume message is enough, others we need
>   * a reset sequence.
>   */
> -static void ish_resume_handler(struct work_struct *work)
> +static void __maybe_unused ish_resume_handler(struct work_struct
> *work)
>  {
>  	struct pci_dev *pdev = to_pci_dev(ish_resume_device);
>  	struct ishtp_device *dev = pci_get_drvdata(pdev);
> @@ -262,7 +261,7 @@ static void ish_resume_handler(struct work_struct
> *work)
>   *
>   * Return: 0 to the pm core
>   */
> -static int ish_suspend(struct device *device)
> +static int __maybe_unused ish_suspend(struct device *device)
>  {
>  	struct pci_dev *pdev = to_pci_dev(device);
>  	struct ishtp_device *dev = pci_get_drvdata(pdev);
> @@ -288,7 +287,7 @@ static int ish_suspend(struct device *device)
>  	return 0;
>  }
>  
> -static DECLARE_WORK(resume_work, ish_resume_handler);
> +static __maybe_unused DECLARE_WORK(resume_work, ish_resume_handler);
>  /**
>   * ish_resume() - ISH resume callback
>   * @device:	device pointer
> @@ -297,7 +296,7 @@ static DECLARE_WORK(resume_work,
> ish_resume_handler);
>   *
>   * Return: 0 to the pm core
>   */
> -static int ish_resume(struct device *device)
> +static int __maybe_unused ish_resume(struct device *device)
>  {
>  	struct pci_dev *pdev = to_pci_dev(device);
>  	struct ishtp_device *dev = pci_get_drvdata(pdev);
> @@ -311,21 +310,14 @@ static int ish_resume(struct device *device)
>  	return 0;
>  }
>  
> -static const struct dev_pm_ops ish_pm_ops = {
> -	.suspend = ish_suspend,
> -	.resume = ish_resume,
> -};
> -#define ISHTP_ISH_PM_OPS	(&ish_pm_ops)
> -#else
> -#define ISHTP_ISH_PM_OPS	NULL
> -#endif /* CONFIG_PM */
> +static SIMPLE_DEV_PM_OPS(ish_pm_ops, ish_suspend, ish_resume);
>  
>  static struct pci_driver ish_driver = {
>  	.name = KBUILD_MODNAME,
>  	.id_table = ish_pci_tbl,
>  	.probe = ish_probe,
>  	.remove = ish_remove,
> -	.driver.pm = ISHTP_ISH_PM_OPS,
> +	.driver.pm = &ish_pm_ops,
>  };
>  
>  module_pci_driver(ish_driver);

8   elilo.conf

/boot/efi/EFI/Slackware/elilo.conf 파일의 내용이다.

delay=30
read-only
root=/dev/nvme0n1p3
append="resume=/dev/nvme0n1p2"
image=vmlinuz-generic-4.14.14
        label=g14
        initrd=initrd-4.14.14.gz
image=vmlinuz-huge-4.14.14
        label=h14

9   설치 순서 정리

  1. 슬랙웨어64 14.2 DVD로 부팅한다.
  2. gdisk로 파티션을 생성한다.
  3. setup으로 패키지 설치 및 설정을 마치고 재부팅하지 않는다.
  4. eliloconfig를 수작업으로 실행한다.
  5. 재부팅한다.
  6. 다음 패키지들슬랙웨어64 Current에서 내려 받아 upgradepkg를 이용해서 업그레이드한다.
    • a/elilo-3.16-x86_64-5.txz
    • a/kernel-firmware-20180104_65b1c68-noarch-1.txz
    • a/kernel-generic-4.14.14-x86_64-1.txz
    • a/kernel-huge-4.14.14-x86_64-1.txz
    • a/kernel-modules-4.14.14-x86_64-1.txz
    • d/kernel-headers-4.14.14-x86-1.txz
    • k/kernel-source-4.14.14-noarch-1.txz
  7. 하이버네이션 문제의 주범인 모듈들을 패치한 후 컴파일 및 설치한다.
  8. elilo.conf를 작성한다.

10   후기

여러 우여곡절 끝에 드디어 요가 370에 슬랙웨어64 14.2와 함께 커널 4.14.14를 설치했다. 스스로 생각해 보니 그냥 윈도 10을 쓰면 되지 랩탑 참 어렵게 쓴다 싶기는 하다. ㅋㅋ 하지만 xterm을 너무 사랑한 나머지 윈도의 깔끔한 인터페이스만 보면 짜증나서 어쩔 수 없다. ;-)

11   참고문헌

2018년 2월 13일 화요일 오전 9:26:06 EST

프리비에스디에서 리눅스로 넘어가신 후 부터는 슬렉웨어로 정착을 하셨군요. 저는 최근에 arch + i3 라는 신세계를 살짝 맛보던 중이었는데 일때문에 윈10을 설치하고 말았네요. 어쩔수 없는것은 어쩔 수 없죠. ㅋ 언젠가는 저도 스스로 만족스러운 환경을.. - snailoff

2018년 2월 17일 토요일 오후 12:07:10 EST

그게 벌써 10년도 더 된 일이네요. arch + i3가 뭔가 했는데 Arch Linux에 타일링 윈도매니져 i3를 말씀하신 거였군요. 저도 타일링 윈도매니져를 한 번 시도해 봤었습니다. 그런데 윈도 크기와 위치를 마음대로 조절을 못 하니 너무 불편해서 Fluxbox로 돌아 왔었지요. 타일링이 맞는 작업이 있는 반면 그렇지 않은 작업도 있는 것 같습니다. 윈도매니져가 사용자의 의도를 잘 파악해서 타일링을 적절히 잘 해 준다면 몰라도 어차피 화면 전체를 채우려고 하니까 윈도 크기는 어떻게 못 할 것 같았습니다.

저도 새 랩탑에서 윈도 10을 써보니 참 편하고 좋았습니다만 남의 집에 온 느낌이었다고 할까요? 뭔가 제 마음대로 컨트롤 못 하는 것들에 대한 불편함이 크지요. -- hcho

2018년 7월 2일 월요일 오전 9:36:42 EDT

기본은 타일링인데 풀스크린이나 플로팅도 됩니다. 플로팅 모드일때는 창크기를 자유자재로 바꿀 수 있어요. 최근 다시 archlinux를 셋팅했는데 이제야 그럭저럭 쓸만하게 되었네요. 정리를 해 놔야 겠어요! — snailoff

2018년 7월 3일 화요일 오전 1:08:37 EDT

Fluxbox가 아직은 쓸만한데 3년째 업데이트가 없어서 다른 윈도매니져를 한번 시도를 해볼까 살펴 보는 중입니다. Fluxbox의 태빙과 키보드 숏컷에 너무 길들여져서 i3는 어떨지 모르겠습니다. 단축키로 xterm 같은 것을 한방에 띄울 수 있나요? 창이동, 크기변환등 거의 키보드로 처리를 하고 있거든요. -- hcho

2018년 7월 4일 수요일 오전 10:57:47 EDT

프로그램이나 이동, 크기변환 모두 숏컷으로 지원합니다. 저는 타일링 윈도매니저는 처음인데, 간단한 숏컷으로 많은 가상화면을 다룰 수 있는게 좋은 것 같아요.

여기에서는 현재 1위를 하고 있네요.

-- snailoff

2018년 7월 4일 수요일 오후 12:31:45 EDT

Awesome도 좋아 보였습니다. 워크스페이스가 아니라 태그를 쓰니까 같은 윈도를 여러 화면에서 볼 수 있다는 점이 매력적으로 보입니다. -- hcho

이 칸을 비워 두세요.

마지막 수정: 조희대 . 2018년 7월 4일 수요일 오후 12:31:45 EDT
파싱시간: 0.154초
XHTML . CSS . 윤익희가 만듦!