다음에 적용 SUSE Linux Enterprise Server 12 SP5

19 SUSE Linux Enterprise 업그레이드 #

SUSE® Linux Enterprise(SLE)를 통해 기존 시스템을 새 버전으로 업그레이드할 수 있습니다. 새로 설치할 필요가 없습니다. 홈 디렉토리, 데이터 디렉토리 및 시스템 구성과 같은 기존 데이터가 원래 상태로 보존됩니다. 로컬 CD나 DVD 드라이브 또는 중앙 네트워크 설치 원본에서 업데이트할 수 있습니다.

이 장에서는 DVD, 네트워크, 자동 프로세스 또는 SUSE Manager를 통해 SUSE Linux Enterprise 시스템을 수동으로 업그레이드하는 방법을 설명합니다.

19.1 SLE 12 SP5에 대해 지원되는 업그레이드 경로 #

그림 19.1: 지원 업그레이드 경로 개요 #

중요: 아키텍처 간 업그레이드 지원 안 함

아키텍처 간 업그레이드(예: 32비트 버전의 SUSE Linux Enterprise Server에서 64비트 버전으로 또는 big endian에서 little endian으로 업그레이드)는 지원되지 않습니다.

특히, SLE 11 on POWER(big endian)에서 SLE 12 SP2 on POWER(최신: little endian)로의 업그레이드는 지원되지 않습니다.

또한 SUSE Linux Enterprise 12는 64비트 전용이므로 32비트 SUSE Linux Enterprise 11 시스템에서 SUSE Linux Enterprise 12 이상 버전으로의 업그레이드는 지원되지 않습니다.

아키텍처 간 업그레이드가 필요한 경우 새로 설치해야 합니다.

참고: 서비스 팩 건너뛰기

가장 빠른 업그레이드 경로는 단계별로 모든 서비스 팩을 연속적으로 설치하는 것입니다. 경우에 따라 업그레이드할 때 1~2개의 서비스 팩을 건너뛸 수 있습니다. 자세한 내용은 버전별 지원 업그레이드 경로 및 그림 19.1. “지원 업그레이드 경로 개요” 항목을 참조하십시오. 그러나 서비스 팩을 건너뛰지 않는 것이 좋습니다.

참고: 주 릴리스 업그레이드

새 주 릴리스로 업그레이드할 때 새로 설치를 수행하는 것이 좋습니다.

버전별 지원 업그레이드 경로 #

SUSE Linux Enterprise 10(서비스 팩)에서 업그레이드

SUSE Linux Enterprise 12에 대해 지원되는 직접 마이그레이션 경로는 없습니다. 이 경우 새로 설치하는 것이 좋습니다.

SUSE Linux Enterprise 11 GA / SP1 / SP2 / SP3에서 업그레이드

SUSE Linux Enterprise 12에 대해 지원되는 직접 마이그레이션 경로는 없습니다. SLE 11 SP4 이상이 있어야만 SLE 12 SP5로 넘어갈 수 있습니다.

새로 설치할 수 없는 경우 먼저 설치된 SLE 11 서비스 팩을 SLE 11 SP4로 업그레이드하십시오. 이러한 단계는 SUSE Linux Enterprise 11용 배포 가이드에 설명되어 있습니다(https://documentation.suse.com/sles-11/).

SUSE Linux Enterprise 11 SP4에서 업그레이드

SLE 11 SP5에서 SLE 12 SP4로 업그레이드하려면 오프라인 업그레이드를 사용해야 합니다. 자세한 내용은 20장 오프라인 업그레이드 항목을 참조하십시오.

SUSE Linux Enterprise 12 GA/SP1/SP2에서 SP5로 업그레이드

SLE 12 GA, SP1 또는 SP2에서 SP5로의 직접 업그레이드는 지원되지 않습니다. SLE 12 SP3 또는 SP4로 먼저 업그레이드합니다.

SUSE Linux Enterprise 12 SP3/SP4에서 SP5로 업그레이드

SUSE Linux Enterprise 12 SP3 또는 SP4에서 SP5로 업그레이드할 수 있습니다.

SUSE Linux Enterprise 12 LTSS GA/SP1에서 SP5로 업그레이드

SUSE Linux Enterprise 12 LTSS GA 또는 SP1에서 SP5로의 직접 업그레이드는 지원되지 않습니다. 먼저 SLE 12 LTSS SP2로 업그레이드하십시오.

SUSE Linux Enterprise 12 LTSS SP2/SP3/SP4에서 SP5로 업그레이드

SUSE Linux Enterprise 12 LTSS SP2, SP3 또는 SP4에서 SP5로 업그레이드할 수 있습니다.

19.2 온라인 및 오프라인 업그레이드 #

SUSE에서 두 가지 업그레이드 및 마이그레이션 방법을 지원합니다. 용어에 대한 자세한 내용은 18.1절 “용어”를 참조하십시오. 방법은 다음과 같습니다.

온라인

실행 중인 시스템에서 실행되는 모든 업그레이드는 온라인으로 간주됩니다. 예를 들어 Zypper 또는 YaST를 사용하여 SUSE Customer Center, SMT(Subscription Management Tool), SUSE Manager를 통해 연결되는 것을 들 수 있습니다.

동일한 주 릴리스의 서비스 팩 간에 마이그레이션하는 경우 21.4절 “온라인 마이그레이션 도구(YaST)를 통한 업그레이드” 또는 21.5절 “Zypper로 업그레이드”를 따르는 것이 좋습니다.

오프라인

오프라인 방법에서는 일반적으로 설치된 SLE 버전이 업그레이드되는 다른 운영 체제를 부팅합니다. 예: DVD, 플래시 디스크, ISO 이미지, AutoYaST, “일반 RPM” 또는 PXE 부팅

중요: SUSE Manager 클라이언트

SUSE Manager에서 시스템을 관리하는 경우, 관리 인터페이스에서 업그레이드 절차를 시작해야 합니다. 자세한 내용은 20.6절 “SUSE Manager를 통한 업데이트”를 참조하십시오.

19.3 시스템 준비 #

업그레이드 절차를 시작하기 전에 시스템을 올바르게 준비해야 합니다. 무엇보다도 데이터를 백업하고 릴리스 정보를 확인하는 것이 중요합니다.

19.3.1 현재 시스템이 최신인지 확인 #

시스템 업그레이드는 최신 패치 수준에서만 지원됩니다. 최신 시스템 업데이트가 zypper 패치를 실행하거나 YaST 모듈 온라인 업데이트를 시작하여 설치되는지 확인하십시오.

19.3.2 릴리스 정보 읽기 #

릴리스 정보에서 이전 릴리스의 SUSE Linux Enterprise Server 이후에 변경된 내용에 대한 추가 정보를 확인할 수 있습니다. 릴리스 정보에서 다음을 확인하십시오.

하드웨어에 대해 특별히 고려해야 할 사항
사용된 소프트웨어 패키지가 크게 변경되었는지 여부
설치할 때 특별히 주의해야 할 사항

또한 릴리스 정보에서는 설명서에 즉시 제공할 수 없는 정보도 제공하며, 알려진 문제점에 대한 정보도 포함합니다.

하나 이상의 서비스 팩을 건너뛰는 경우 건너뛴 서비스 팩의 릴리스 정보도 확인하십시오. 일반적으로 릴리스 정보에는 연속되는 두 릴리스 간의 변경 사항만 포함됩니다. 현재 릴리스 정보만 확인하는 경우 중요한 변경 사항을 놓칠 수 있습니다.

릴리스 정보는 /usr/share/doc/release-notes 디렉토리에서 로컬로 확인하거나 https://www.suse.com/releasenotes/에서 온라인으로 확인할 수 있습니다.

19.3.3 백업 #

업데이트하기 전에 기존 구성 파일을 테이프 장치, 이동식 하드 디스크 등과 같은 별도의 매체에 복사하여 데이터를 백업합니다. 이 사항은 주로 /var 및 /opt의 일부 디렉토리 및 파일과 /etc에 저장된 파일에 적용됩니다. 또한 /home(HOME 디렉토리)의 사용자 데이터를 백업 매체에 기록해야 할 수도 있습니다. 이 데이터를 root로 백업하십시오. root에만 모든 로컬 파일에 대한 읽기 권한이 있습니다.

YaST에서 설치 모드로 기존 시스템 업데이트를 선택한 경우 나중에 (시스템) 백업을 수행하도록 선택할 수 있습니다. 수정된 모든 파일과 /etc/sysconfig 디렉토리의 파일을 포함하도록 선택할 수 있습니다. 그러나 이는 위에서 언급한 다른 모든 중요한 디렉토리가 없기 때문에 전체 백업은 아닙니다. /var/adm/backup 디렉토리에서 백업을 확인하십시오.

19.3.3.1 설치된 패키지 및 리포지토리 나열 #

새 주 SLE 릴리스를 새로 설치하거나 이전 버전으로 되돌릴 경우와 같이 설치된 패키지 목록이 있으면 유용한 경우가 많습니다.

설치된 패키지나 사용된 리포지토리 중 일부는 SUSE Linux Enterprise의 최신 릴리스에서 제공되지 않을 수 있습니다. 이름이 바뀌거나 대체된 경우도 있습니다. 또한 레거시 용도로 계속 제공되는 패키지가 있는 반면 기본적으로 사용되는 패키지도 있을 수 있습니다. 따라서 파일을 수동으로 편집해야 하는 경우가 있습니다. 그럴 경우 텍스트 편집기를 사용하면 됩니다.

사용된 모든 리포지토리 목록을 포함하는 repositories.bak라는 파일을 만듭니다.

root # zypper lr -e repositories.bak

설치된 모든 패키지 목록을 포함하는 installed-software.bak 파일도 만듭니다.

root # rpm -qa --queryformat '%{NAME}\n' > installed-software.bak

두 파일을 모두 백업합니다. 리포지토리 및 설치된 패키지는 다음 명령으로 복원할 수 있습니다.

root # zypper ar repositories.bak
root # zypper install $(cat installed-software.bak)

참고: 새로운 주 릴리스로의 업데이트에 따른 패키지 증가량

새로운 주 버전으로 업그레이드된 시스템(SLE X+1)은 초기 시스템(SLE X)보다 더 많은 패키지를 포함할 수 있습니다. 또한 동일한 패턴 선택 항목이 있는 SLE X+1의 새로운 설치보다 더 많은 패키지를 포함합니다. 그 이유는 다음과 같습니다.

패키지가 분할되어 더 세분화된 패키지 선택이 허용됩니다. 예를 들어 SLE 11의 37개 texlive 패키지는 SLE 12에서 422개 패키지로 분할되었습니다.
패키지가 다른 패키지로 분할되면 새로운 모든 패키지가 업그레이드된 사례에 설치되어 이전 버전과 동일한 기능을 유지합니다. 그러나 SLE X+1의 새로운 설치에 대한 새 기본값은 모든 패키지를 설치하지 않을 수 있습니다.
SLE X의 레거시 패키지는 호환성으로 인해 유지될 수 있습니다.
패키지 종속성 및 패턴 범위는 변경되었을 수 있습니다.

19.3.4 MySQL 데이터베이스 마이그레이션 #

SUSE Linux Enterprise 12부터 SUSE는 MySQL에서 MariaDB로 전환했습니다. 업그레이드를 시작하기 전에 데이터베이스를 백업하는 것이 좋습니다.

데이터베이스를 마이그레이션하려면 다음을 수행하십시오.

SUSE Linux Enterprise 11 컴퓨터에 로그인합니다.
덤프 파일을 생성합니다.
```
root # mysqldump -u root -p --all-databases > mysql_backup.sql
```
기본적으로 mysqldump는 INFORMATION_SCHEMA 또는 performance_schema 데이터베이스를 덤프하지 않습니다. 자세한 내용은 https://dev.mysql.com/doc/refman/5.5/en/mysqldump.html을 참조하십시오.
나중에 확인하기 위해(설치는 아님) 덤프 파일, 구성 파일 /etc/my.cnf 및 /etc/mysql/ 디렉토리를 안전한 곳에 저장합니다.
업그레이드를 수행합니다. 업그레이드 후에도 이전 구성 파일 /etc/my.cnf는 그대로 유지됩니다. 새 구성은 /etc/my.cnf.rpmnew 파일에 있습니다.
MariaDB 데이터베이스를 필요에 따라 구성합니다. 이전 구성 파일 및 디렉토리는 사용하지 마십시오. 하지만 확인용으로 사용하거나 변경하여 사용할 수는 있습니다.
다음과 같이 MariaDB 서버를 시작해야 합니다.
```
root # systemctl start mysql
```
부팅할 때마다 MariaDB 서버를 시작하려면 다음과 같이 서비스를 활성화합니다.
```
root # systemctl enable mysql
```
데이터베이스에 연결하여 MariaDB가 올바로 실행 중인지 확인합니다.
```
root # mysql -u root -p
```

19.3.5 PostgreSQL 데이터베이스 마이그레이션 #

PostgreSQL 데이터베이스의 새 버전이 유지보수 업데이트로 제공됩니다. 데이터베이스의 필수 마이그레이션 작업 때문에 자동 업그레이드 프로세스는 없습니다. 이처럼 한 버전에서 다른 버전으로 수동으로 전환해야 합니다.

기본 덤프 및 다시 로드의 대체 방법인 pg_upgrade 명령으로 마이그레이션 프로세스를 수행합니다. “덤프 및 다시 로드” 방법에 비해 pg_upgrade를 사용하면 마이그레이션에 시간이 덜 듭니다.

각 PostgreSQL 버전의 프로그램 파일은 버전별로 다른 디렉토리에 저장됩니다. 예를 들어, 버전 9.6은 /usr/lib/postgresql96/, 버전 10은 /usr/lib/postgresql10/에 저장됩니다. PostgreSQL의 버전 관리 정책은 주요 버전 9.6과 10 사이에서 변경되었습니다. 자세한 내용은 https://www.postgresql.org/support/versioning/를 참조하십시오.

중요: SLE 11에서 업그레이드

SLE 11에서 업그레이드할 때 postgresql94는 삭제되며 데이터베이스를 더 높은 버전의 PostgreSQL로 마이그레이션하는 데 사용할 수 없습니다. 따라서 이 경우 시스템을 업그레이드하기 전에 PostgreSQL 데이터베이스를 마이그레이션해야 합니다.

아래 절차는 버전 9.6에서 10으로 데이터베이스를 마이그레이션하는 방법에 대한 설명입니다. 시작 또는 대상으로 다른 버전을 사용할 때 버전 번호를 그에 맞게 교체하십시오.

데이터베이스를 마이그레이션하려면 다음을 수행하십시오.

다음 사전 조건이 충족되었는지 확인합니다.
- 아직 하지 않은 경우 유지보수 업데이트를 통해 이전 PostgreSQL 버전의 패키지를 최신 릴리스로 업그레이드합니다.
- 기존 데이터베이스의 백업을 만듭니다.
- 새 PostgreSQL 주 버전의 패키지를 설치합니다. SLE12 SP5의 경우 postgresql10-server 및 이 패키지가 종속된 패키지를 모두 설치합니다.
- 패키지 설치 postgresql10-contrib 패키지(pg_upgrade 명령 포함)를 설치합니다.
- PostgreSQL 데이터 영역(기본적으로 /var/lib/pgsql/data)이 충분한지 확인하십시오. 공간이 부족한 경우 각 데이터베이스에서 다음 SQL 명령으로 크기를 줄여 보십시오(아주 오래 걸릴 수 있음).
```
VACUUM FULL
```
다음 중 하나를 사용하여 PostgreSQL 서버를 중단합니다.
```
root # /usr/sbin/rcpostgresql stop
```
또는
```
root # systemctl stop postgresql.service
```
(업그레이드 시작 버전으로 사용하는 SLE 버전에 따라 다름)

이전 데이터 디렉토리 이름을 바꿉니다.

root # mv /var/lib/pgsql/data /var/lib/pgsql/data.old

새 데이터베이스 인스턴스를 initdb를 사용하여 수동으로 초기화하거나 PostgreSQL을 시작했다가 정지하여 자동으로 초기화합니다.
```
root # /usr/sbin/rcpostgresql start
root # /usr/sbin/rcpostgresql stop
```
또는
```
root # systemctl start postgresql.service
root # systemctl stop postgresql.service
```
(업그레이드 시작 버전으로 사용하는 SLE 버전에 따라 다름)
이전 버전에서 구성 파일을 변경한 경우, 해당 변경 사항을 새로운 구성 파일로 전송하십시오. postgresql.auto.conf, postgresql.conf, pg_hba.conf 및 pg_ident.conf 파일에 영향을 미칠 수 있습니다. 이러한 파일의 이전 버전은 /var/lib/pgsql/data.old/에 있으며, 새 버전은 /var/lib/pgsql/data에 있습니다.
새 옵션, 새 기본값 및 변경된 주석을 덮어쓸 수 있으므로 이전 구성 파일을 복사하지 않는 것이 좋습니다.

마이그레이션 프로세스를 사용자 postgres로 시작합니다.

root # su - postgres
postgres > pg_upgrade \
   --old-datadir "/var/lib/pgsql/data.old" \
   --new-datadir "/var/lib/pgsql/data" \
   --old-bindir "/usr/lib/postgresql96/bin/" \
   --new-bindir "/usr/lib/postgresql10/bin/"

다음에서 새 데이터베이스 인스턴스를 시작합니다.
```
root # /usr/sbin/rcpostgresql start
```
또는
```
root # systemctl start postgresql.service
```
(업그레이드 시작 버전으로 사용하는 SLE 버전에 따라 다름)
마이그레이션되었는지 확인합니다. 테스트 범위는 사용 사례에 따라 다릅니다. 이 단계를 자동화하는 일반 도구는 없습니다.

이전 PostgreSQL 패키지와 이전 데이터 디렉토리를 제거합니다.

root # zypper search -s postgresql96 | xargs zypper rm -u
root # rm -rf /var/lib/pgsql/data.old

19.3.6 Java 응용 프로그램용 MD5 이외의 서버 인증서 생성 #

SP1에서 SP2로 업데이트하는 절차 중에 보안 수정의 일부로 MD5 기반 인증서가 비활성화 되었습니다. MD5로 작성한 인증서가 있는 경우 다음 단계에 따라 인증서를 다시 작성하십시오.

터미널 창을 열고 root로 로그인하십시오.
개인 키를 생성합니다.
```
root # openssl genrsa -out server.key 1024
```
보다 강력한 키를 원하는 경우 1024를 4096과 같이 더 높은 숫자로 바꿉니다.

인증서 서명 요청 (CSR)을 생성합니다.

root # openssl req -new -key server.key -out server.csr

인증서에 자체 서명합니다.

root # openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

PEM 파일을 생성합니다.

root # cat server.key server.crt > server.pem

server.crt, server.csr, server.key, 및 server.pem 파일을 키가 있는 각각의 디렉토리에 배치합니다. 예를 들어 Tomcat의 경우, 해당하는 디렉토리는 /etc/tomcat/ssl/입니다.

19.3.7 가상 머신 게스트 종료 #

시스템이 KVM 또는 Xen에 대한 VM 호스트 서버 역할을 할 경우 업데이트 전에 실행 중인 VM 게스트가 모두 올바르게 종료되었는지 확인합니다. 그렇지 않으면 업데이트 후 게스트에 액세스할 수 없습니다.

19.3.8 SMT 클라이언트 설정 조정 #

업그레이드하려는 시스템이 SMT 서버에 클라이언트로 등록된 경우 다음을 수행하십시오.

호스트의 clientSetup4SMT.sh 스크립트 버전이 최신인지 확인합니다. 이전 버전 SMT의 clientSetup4SMT.sh는 SMT 12 클라이언트를 관리할 수 없습니다. 정기적으로 SMT 서버에 소프트웨어 패치를 적용하는 경우 언제든지 <SMT_HOSTNAME>/repo/tools/clientSetup4SMT.sh에서 최신 버전의 clientSetup4SMT.sh를 찾을 수 있습니다.

시스템을 SUSE Linux Enterprise Server의 최신 버전으로 업그레이드하지 못한 경우 절차 19.1에 설명된 대로 SMT 서버에서 시스템을 등록 취소합니다. 이후에 업그레이드 프로세스를 다시 시작하십시오.

절차 19.1: SMT 서버에서 SUSE Linux Enterprise Client 등록 취소 #

클라이언트 시스템에 로그인합니다.

다음 단계는 클라이언트의 현재 운영 체제에 따라 다릅니다.

SUSE Linux Enterprise 11인 경우 다음 명령을 실행합니다.

tux > sudo suse_register -E
tux > sudo rm -f /etc/SUSEConnect
tux > sudo rm -rf /etc/zypp/credentials.d/*
tux > sudo rm -rf /etc/zypp/repos.d/*
tux > sudo rm -f /etc/zypp/services.d/*
tux > sudo rm -f /var/cache/SuseRegister/*
tux > sudo rm -f /etc/suseRegister*
tux > sudo rm -f /var/cache/SuseRegister/lastzmdconfig.cache
tux > sudo rm -f /etc/zmd/deviceid
tux > sudo rm -f /etc/zmd/secret

SUSE Linux Enterprise 12인 경우 다음 명령을 실행합니다.

tux > sudo SUSEConnect --de-register
tux > sudo SUSEConnect --cleanup
tux > sudo rm -f /etc/SUSEConnect
tux > sudo rm -rf /etc/zypp/credentials.d/*
tux > sudo rm -rf /etc/zypp/repos.d/*
tux > sudo rm -f /etc/zypp/services.d/*

SMT 서버에 로그인합니다.
모든 클라이언트 등록을 나열하여 클라이언트가 등록 취소되었는지 확인합니다.
```
tux > sudo smt-list-registrations
```
클라이언트의 호스트 이름이 이 명령의 출력에 여전히 나열되면 첫 번째 열에서 클라이언트의 고유한 ID를 가져옵니다. (클라이언트에 ID가 여러 개 나열될 수 있습니다.)
이 클라이언트에 대한 등록을 삭제합니다.
```
tux > sudo smt-delete-registration -g UNIQUE_ID
```
클라이언트에 ID가 여러 개 나열되는 경우 고유한 ID에 대해 각각 위의 단계를 반복하십시오.
다음을 다시 실행하여 이제 클라이언트가 등록 취소되었는지 확인합니다.
```
tux > sudo smt-list-registrations
```

19.3.9 디스크 공간 #

소프트웨어는 버전이 바뀌면서 커지는 경향이 있습니다. 따라서 업데이트하기 전에 사용 가능한 파티션 공간을 살펴보십시오. 디스크 공간 부족이 의심되면 예를 들어 파티션 크기를 조정하는 방법으로 가용 공간을 늘리기 전에 먼저 데이터를 백업하십시오. 각 파티션의 크기에 대한 일반적인 규칙은 없습니다. 공간 요구사항은 특정 파티셔닝 프로파일과 선택한 소프트웨어에 따라 달라집니다.

참고: YaST에서 충분한 공간 자동 확인

업데이트 절차 중 YaST가 사용 가능한 여유 디스크 공간을 검사하고 설치 용량이 여유 공간보다 클 경우 사용자에게 경고를 표시합니다. 이 경우 업데이트를 수행하면 사용할 수 없는 시스템이라는 오류가 발생할 수 있습니다. 상황을 정확히 알고 있는 경우에만(사전 테스트를 수행하여) 경고를 무시하고 업데이트를 진행할 수 있습니다.

19.3.9.1 비 Btrfs 파일 시스템에서 디스크 공간 확인 #

df 명령을 사용하여 가용 디스크 공간을 나열합니다. 예를 들어 예 19.1. “df -h로 나열”에서 루트 파티션은 /dev/sda3(/로 탑재됨)입니다.

예제 19.1: df -h로 나열 #

Filesystem     Size  Used Avail Use% Mounted on
/dev/sda3       74G   22G   53G  29% /
tmpfs          506M     0  506M   0% /dev/shm
/dev/sda5      116G  5.8G  111G   5% /home
/dev/sda1       44G    4G   40G   9% /data

19.3.9.2 Btrfs 루트 파일 시스템에서 디스크 공간 확인 #

시스템에서 Btrfs를 루트 파일 시스템으로 사용하는 경우 사용 가능한 공간이 충분한지 확인해야 합니다. 최악의 경우 업그레이드에 새 스냅샷용 현재 루트 파일 시스템만큼의 디스크 공간이 필요합니다(/.snapshot이 없는 경우). 사용 가능한 디스크 공간을 표시하려면 다음 명령을 사용합니다.

root # df -h /

탑재된 다른 모든 파티션에서도 가용 공간을 확인합니다. 다음은 검증된 권장 사항입니다.

Btrfs를 비롯한 모든 파일 시스템에서 사용 가능한 디스크 공간이 충분해야 큰 RPM을 다운로드하고 설치할 수 있습니다. 이전 RPM의 공간은 새 RPM을 설치해야만 비워집니다.
스냅샷이 포함된 Btrfs의 경우 현재 설치에 소요되는 공간만큼의 사용 가능한 공간이 적어도 필요합니다. 사용 가능한 공간이 현재 설치보다 두 배 많은 것이 좋습니다.
사용 가능한 공간이 충분하지 않으면 스냅퍼를 사용하여 이전 스냅샷을 삭제해 볼 수 있습니다.
```
root # snapper list
root # snapper delete NUMBER
```
하지만 경우에 따라서는 도움이 되지 않을 수도 있습니다. 마이그레이션 전에 대부분의 스냅샷은 적은 공간만 차지합니다.

19.3.10 커널 다중 버전 지원을 일시적으로 비활성화 #

SUSE Linux Enterprise Server는 /etc/zypp/zypp.conf에서 해당 설정을 활성화하여 다중 커널 버전 설치를 지원합니다. 서비스 팩으로 업그레이드할 경우 이 기능에 대한 지원을 일시적으로 비활성화해야 합니다. 업그레이드가 성공적으로 끝나면 다중 버전 지원을 다시 활성화할 수 있습니다. 다중 버전 지원을 비활성화하려면 /etc/zypp/zypp.conf에 해당 줄에 주석을 추가하십시오. 결과는 다음과 같습니다.

#multiversion = provides:multiversion(kernel)
#multiversion.kernels = latest,running

업데이트 성공 후 이 기능을 다시 활성화하려면 주석 기호를 제거하십시오. 다중 버전 지원에 관한 자세한 내용은 15.1절 “다중 버전 지원 활성화 및 구성” 항목을 참조하십시오.

19.4 IBM Z에서 업그레이드 #

IBM Z에서 SUSE Linux Enterprise 설치를 업그레이드하려면 parmfile 등을 통한 Upgrade=1 커널 파라미터가 필요합니다. 4.3절 “parmfile - 시스템 구성 자동화” 참조.

19.5 IBM POWER: X 서버 시작 #

SLES 12 for IBM POWER에서는 디스플레이 관리자가 기본적으로 로컬 X 서버를 시작하지 않도록 구성됩니다. SLES 12 SP1부터는 이 설정이 바뀌어 디스플레이 관리자가 X 서버와 함께 시작됩니다.

업그레이드 중 문제를 방지하려면 SUSE Linux Enterprise Server 설정을 자동으로 변경하지 않아야 합니다. 업그레이드 후 디스플레이 관리자가 X 서버를 시작하도록 하려면 /etc/sysconfig/displaymanager에서 DISPLAYMANAGER_STARTS_XSERVER의 설정을 다음과 같이 변경하십시오.

DISPLAYMANAGER_STARTS_XSERVER="yes"