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