8장. 설치 및 부팅하기

킥스타트에 네트워크 설정이 있을 경우 initrd에서 네트워크 설정을 수정

이전에 설치 프로그램은 네트워크 인터페이스가 킥스타트 파일에 정의되어 있을 경우 initrd에서 네트워크 인터페이스를 설정 또는 재설정하지 못했습니다. 이로 인해 설치 실패하거나 킥스타트 파일에서 다른 명령으로 네트워크 액세스해야 할 경우 비상 모드로 되었습니다.
이러한 문제가 해결되어 Anaconda는 부팅 프로세스 초기에 initrd에 있는 킥스타트 파일에서 네트워크 설정을 제대로 처리할 수 있습니다.

Anaconda에서 캐시된 논리 볼륨 생성 지원

설치 프로그램은 캐시된 LVM 논리 볼륨 생성 및 이러한 볼륨에 시스템 설치를 지원합니다.
현재 이러한 방식은 킥스타트에서만 지원됩니다. 캐시된 논리 볼륨을 생성하려면 logvol 킥스타트 명령의 새로운 --cachepvs=, --cachesize=, --cachemode= 옵션을 사용합니다.
이러한 새 옵션에 대한 보다 자세한 내용은 Red Hat Enterprise Linux 7 설치 가이드에서 참조하십시오.

GRUB2 부트 메뉴 정렬 순서 개선

grub2-mkconfig 명령에서 사용되는 정렬 순서 메커니즘 문제로 인해 grub.cfg 설정 파일이 사용 가능한 커널 순서를 잘못 생성하는 원인이 될 수 있습니다.
GRUB2는 rpmdevtools 패키지를 사용하여 가장 최신 커널 버전이 상단에 나열된 설정 파일 및 사용 가능한 커널을 제대로 정렬합니다.

Anaconda는 디스크 선택 변경시 디스크 동작을 제대로 되돌리기할 수 있음

이전에는 Anaconda 및 Blivet는 디스크 선택 변경 시 디스크에 스케줄된 동작을 제대로 되돌리기할 수 없었기 때문에 여러가지 문제가 발생했습니다. 이번 업데이트에서 Anaconda는 기존 스토리지 설정의 스냅샷을 생성하여 디스크 선택 변경 시 생성된 스냅샷으로 되돌아갈 수 있으므로 디스크에 스케줄된 모든 동작이 완전히 원래 상태로 되돌아 갈 수 있습니다.

device-mapper 디스크 이름 감지 개선

이전 Red Hat Enterprise Linux 7 릴리즈에서는 LVM 논리 볼륨 및 볼륨의 메타 데이터가 아직 존재하는 디스크에 설치할 때 설치 프로그램이 충돌할 수 있었습니다. 설치 프로그램이 올바른 device-mapper 이름을 인식할 수 없어서 새 LVM 논리 볼륨 생성에 실패했었습니다.
device-mapper 장치 이름을 감지하기 위해 사용되는 방식이 업데이트되어 기존 LVM 메타 데이터가 있는 디스크에 설치 시 보다 더 안정적으로 설치할 수 있습니다.

파티션 설정 시 PReP Boot 처리 방식 수정

특정 상황에서 IBM Power Systems 상의 PReP Boot 파티션은 사용자 정의 파티션 설정에서 잘못된 크기로 설정될 수 있었습니다. 이러한 경우 파티션을 삭제하면 설치 프로그램이 충돌하는 원인이 되었습니다.
anaconda에서 체크 기능이 구현되어 파티션 크기가 4096 KiB10 MiB 사이로 제대로 설정되는지 확인합니다. 또한 크기를 변경하기 위해 PReP Boot 파티션 순서 형식을 바꿀 필요가 없습니다.

RAID1 장치에서 EFI 파티션

EFI 시스템 파티션은 RAID1 장치에 생성되어 부팅 디스크에 문제가 발생할 경우 시스템을 복구할 수 있습니다. 하지만 Boot####BootOrder에서 펌웨어에 의해 검색된 ESP 볼륨이 손상되어 있지만 유효한 ESP로 표시될 경우 부팅 순서는 자동으로 재구성되지 않습니다. 하지만 두 번 째 디스크에서 시스템을 수동으로 부팅할 수 있습니다.

네트워크 설정 시 텍스트 모드 설치가 더이상 충돌하지 않음

이전에는 대화형 텍스트 모드 설치 프로그램의 네트워크 설정 화면에서 네임 서버를 지정할 때 공백을 사용하면 설치 프로그램이 중단되었습니다.
Anaconda는 텍스트 모드에서 네임 서버를 지정할 때 공백을 올바르게 처리하여 네임 서버 주소를 구별하기 위해 공백을 사용해도 더이상 설치 프로그램이 중단되지 않습니다.

IBM System z에서 복구 모드 화면이 더이상 잘리지 않음

이전에는 IBM System z의 복구 모드에서 두 번째 및 세 번째 화면이 잘못 표시되어 인터페이스의 일부분이 잘렸습니다. 이러한 아키텍처에서 복구 모드가 개선되어 모든 화면이 올바르게 작동합니다.

Anaconda의 OpenSCAP 애드온

설치 도중 SCAP (Security Content Automation Protocol) 컨텐츠를 적용할 수 있습니다. 이러한 새로운 설치 프로그램 애드온을 통해 사용자 정의 스크립트에 의존하지 않고 보안 정책을 쉽고 안정적으로 설정할 수 있습니다.
이러한 애드온은 새로운 킥스타트 섹션 ("%addon org_fedora_oscap") 및 대화형 설치 도중 그래픽 사용자 인터페이스에서 새로운 화면을 제공합니다. 이러한 부분에 대한 자세한 내용은 Red Hat Enterprise Linux 7 설치 가이드에서 확인하십시오.
설치 도중 보안 정책을 적용하면 설치 도중 또는 설치 후 활성화한 정책에 따라 여러 변경 사항이 실행됩니다. 프로파일을 선택하면 openscap-scanner 패키지 (OpenSCAP 컴플라이언스 검사 도구)가 패키지 선택에 추가되어 설치 완료 후 초기 컴플라이언스 검사가 실행됩니다. 검사 결과는 /root/openscap_data에 저장됩니다.
설치 미디어에서 여러 프로파일이 scap-security-guide 패키지를 통해 제공됩니다. 필요에 따라 HTTP, HTTPS, FTP 서버에서 데이터 스트림, 아카이브, RPM 패키지로 컨텐츠를 불러올 수 있습니다.
보안 정책을 모든 시스템에 적용할 필요는 없습니다. 이러한 애드온은 특정 정책이 조직 또는 정부 규정에 의해 설정되는 경우에만 사용합니다. 그렇지 않을 경우 애드온은 보안 규칙을 적용하지 않는 기본 상태로 둘 수 있습니다.

Anaconda에서 CD 또는 DVD 상의 킥스타트 파일 대기 시간을 초과하지 않음

이전에는 Anaconda가 inst.ks=cdrom:/ks.cfg 명령을 사용하여 광학 미디어에서 킥스타트 파일을 불러오도록 설정되어 있고 시스템이 CD나 DVD에서 부팅될 경우 설치 프로그램은 디스크를 교체할 때 까지 잠시 대기했었습니다. 이러한 대기 시간은 기본값으로 매우 짧아 (약 30초 정도) 대기 시간이 지난 후 시스템은 응급 모드로 들어갔었습니다.
Anaconda가 수정되어 CD 또는 DVD에서 킥스타트 파일을 제공하기 위한 사용자 대기 시간이 초과되지 않습니다. inst.ks=cdrom 부팅 옵션이 사용되고 킥스타트 파일이 감지되지 않을 경우 Anaconda는 프롬프트를 표시하고 파일이 지정되거나 재부팅할 때 까지 대기합니다.