IF you've sorted this out, skip this email, it might be confusing.
Your best bet might be to do this in a VM using custom partitioning
then look at the resulting /root/anaconda-ks.cfg for hints. I find the
nomenclature of anaconda kickstarts to be very confusing and
non-obvious. And I'm willing to bet this stuff changes a LOT between
versions of anaconda, especially in new areas like UEFI firmware as
during Fedora testing in the approximate lifecycle of RHEL 7, there
were lots of bugs and lots of fixes.
So I just tried a two disk autopartitioning with CentOS 7 (not 7.2)
which is using anaconda-19.31.79-1. The kickstart I get
#version=RHEL7
# System authorization information
auth --enableshadow --passalgo=sha512
# Use CDROM installation media
cdrom
# Run the Setup Agent on first boot
firstboot --enable
ignoredisk --only-use=vda,vdb
# Keyboard layouts
keyboard --vckeymap=us --xlayouts='us'
# System language
lang en_US.UTF-8
# Network information
network --bootproto=dhcp --device=ens3 --onboot=off --ipv6=auto
network --hostname=localhost.localdomain
# Root password
rootpw --iscrypted $6$
# System timezone
timezone America/New_York --isUtc
# System bootloader configuration
bootloader --location=mbr --boot-drive=vda
autopart --type=lvm
# Partition clearing information
clearpart --none --initlabel
%packages
@core
%end
-----
So the screwy parts... bootloader --location=mbr makes zero sense to
me on UEFI systems. Clearly it should be on a partition, the EFI
system partition, and the installation that resulted in this kickstart
file did create an EFI system partition, a bootloader is on it, and
there is no bootloader code in the first 440 bytes of the PMBR. So,
yeah... pretty screwy that this kickstart does the right thing.
FWIW I don't highly recommend this layout because what it does is
creates a linear/concat of vda and vdb primarily for LVM, and spreads
rootfs (and home) across both drives. One device failure means
complete data loss. The install will let you create an mdadm raid
level 1 (mirror) of the EFI system partition in custom partitioning on
two drives. It's debatable if this is a great idea for enterprise
software, but no one has bothered to come up with the kind of solution
you'd see on other platforms where the thing that modifies the ESP is
capable of modifying all ESPs, to keep them in sync, without using
software RAID. So we're sorta stuck with mdadm raid1, or you'd have to
create your own script that syncs a primary ESP to the secondary ESP
(primary being the one mounted at /boot/efi and the only one that'd
get updated bootloaders and bootloader config).
Yada.
Chris Murphy
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
