Dear Experts,
Could somebody point to kicstart HOWTO specific for CentOS 7?
On CentOS 7 I somehow am always given human intervention questions about drive which defeats unattended ks install.
<rant ??> I'm doing kickstart installations for quite some time, normally I was just installing system when new release comes, and am basing kickstart file on anaconda-ks.cfg - with some adoptions from my kickstart configuration for previous system release. Never had a need to re-learn a set of trivial things I use (as far back as I remember: CentOS 6, 5, ... Fedora 5, RH 9, 8, 7...). Now it turns out to be time to re-learn the thing. At least one snag I hit consistently with CentOS 7 kickstart is: it drops me into human decision as far as wiping hard drive and creating custom (or default probably as well) partitioning scheme is concerned. Most likely it is me who needs to learn new trick (like "tricking smart macintosh into actually doing what you want done") as it looks like safety defeats my unattended kickstart installation (like on Windows: "Do you really - really want to do this?") </rant> - if that was rant that is...
Thanks a lot for your advises!
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Thu, 4 Aug 2016, Valeri Galtsev wrote:
Dear Experts,
Could somebody point to kicstart HOWTO specific for CentOS 7?
On CentOS 7 I somehow am always given human intervention questions about drive which defeats unattended ks install.
At least one snag I hit consistently with CentOS 7 kickstart is: it drops me into human decision as far as wiping hard drive and creating custom (or default probably as well) partitioning scheme is concerned. Most likely it is me who needs to learn new trick (like "tricking smart macintosh into actually doing what you want done") as it looks like safety defeats my unattended kickstart installation (like on Windows: "Do you really - really want to do this?").
It would have been helpful to see the disk-specific part of your kickstart file, but here's a snippet that's worked for me:
clearpart --all --initlabel zerombr bootloader --location=mbr part ... part ...
I've also noticed that LVM meta information will stick around during a re-installation. So if you're reusing the names of volumes groups, you might encounter an error. I do something like this in a %pre section:
%pre --interpreter=/usr/bin/bash # DANGER: will remove all volume groups for VG in $(vgs -o vg_name --noheadings); do vgremove -f "$VG" done %end
On Thu, August 4, 2016 7:13 pm, Paul Heinlein wrote:
On Thu, 4 Aug 2016, Valeri Galtsev wrote:
Dear Experts,
Could somebody point to kicstart HOWTO specific for CentOS 7?
On CentOS 7 I somehow am always given human intervention questions about drive which defeats unattended ks install.
At least one snag I hit consistently with CentOS 7 kickstart is: it drops me into human decision as far as wiping hard drive and creating custom (or default probably as well) partitioning scheme is concerned. Most likely it is me who needs to learn new trick (like "tricking smart macintosh into actually doing what you want done") as it looks like safety defeats my unattended kickstart installation (like on Windows: "Do you really - really want to do this?").
It would have been helpful to see the disk-specific part of your kickstart file, but here's a snippet that's worked for me:
clearpart --all --initlabel zerombr bootloader --location=mbr part ... part ...
I've also noticed that LVM meta information will stick around during a re-installation. So if you're reusing the names of volumes groups, you might encounter an error. I do something like this in a %pre section:
%pre --interpreter=/usr/bin/bash # DANGER: will remove all volume groups for VG in $(vgs -o vg_name --noheadings); do vgremove -f "$VG" done %end
Thanks Paul,
here is my unsuccessful (requiring human intervention) kistart disk related part:
# System bootloader configuration #bootloader --location=mbr --boot-drive=sda # Darn, they changed grub password encryption standard #bootloader --location=mbr --boot-drive=sda --append="crashkernel=no rhgb quiet" --md5pass=$1$F/BHluSk$YticIZvEKa6Ckmw6GYTno. bootloader --location=mbr --boot-drive=sda --append="crashkernel=no rhgb quiet" # Partition clearing information clearpart --all --initlabel --drives=sda # Disk partitioning information part /boot --fstype="xfs" --ondisk=sda --size=500 --asprimary part / --fstype="xfs" --ondisk=sda --size=5000 --asprimary part /usr --fstype="xfs" --ondisk=sda --size=30000 --asprimary part swap --fstype="swap" --ondisk=sda --size=4000 part /var --fstype="xfs" --ondisk=sda --size=3000 part /tmp --fstype="xfs" --ondisk=sda --size=1000 part /home --fstype="xfs" --ondisk=sda --size=50000 part /data --fstype="xfs" --ondisk=sda --size=100 --grow
I never start with drives that contained any lvm leftovers, but thanks, I will add that part to my kickstart file.
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Thu, 4 Aug 2016, Valeri Galtsev wrote:
On Thu, August 4, 2016 7:13 pm, Paul Heinlein wrote:
On Thu, 4 Aug 2016, Valeri Galtsev wrote:
At least one snag I hit consistently with CentOS 7 kickstart is: it drops me into human decision as far as wiping hard drive and creating custom (or default probably as well) partitioning scheme is concerned. Most likely it is me who needs to learn new trick (like "tricking smart macintosh into actually doing what you want done") as it looks like safety defeats my unattended kickstart installation (like on Windows: "Do you really - really want to do this?").
It would have been helpful to see the disk-specific part of your kickstart file, but here's a snippet that's worked for me:
clearpart --all --initlabel zerombr bootloader --location=mbr part ... part ...
I've also noticed that LVM meta information will stick around during a re-installation. So if you're reusing the names of volumes groups, you might encounter an error. I do something like this in a %pre section:
%pre --interpreter=/usr/bin/bash # DANGER: will remove all volume groups for VG in $(vgs -o vg_name --noheadings); do vgremove -f "$VG" done %end
Thanks Paul,
here is my unsuccessful (requiring human intervention) kistart disk related part:
# System bootloader configuration #bootloader --location=mbr --boot-drive=sda # Darn, they changed grub password encryption standard #bootloader --location=mbr --boot-drive=sda --append="crashkernel=no rhgb quiet" --md5pass=$1$F/BHluSk$YticIZvEKa6Ckmw6GYTno. bootloader --location=mbr --boot-drive=sda --append="crashkernel=no rhgb quiet" # Partition clearing information clearpart --all --initlabel --drives=sda # Disk partitioning information part /boot --fstype="xfs" --ondisk=sda --size=500 --asprimary part [... other ops on sda ...]
The only bit you don't have is the "zerombr" directive. From the Red Hat documentation:
If zerombr is specified, any invalid partition tables found on disks are initialized. This destroys all of the contents of disks with invalid partition tables. This command is required when performing an unattended installation on a system with previously initialized disks.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
On Thu, Aug 04, 2016 at 10:32:56AM -0500, Valeri Galtsev wrote:
... At least one snag I hit consistently with CentOS 7 kickstart is: it drops me into human decision as far as wiping hard drive and creating custom (or default probably as well) partitioning scheme is concerned. Most likely it is me who needs to learn new trick (like "tricking smart macintosh into actually doing what you want done") as it looks like safety defeats my unattended kickstart installation (like on Windows: "Do you really - really want to do this?") </rant> - if that was rant that is...
Is it a BIOS boot, or are you using the UEFI firmware for booting? Either way, you might need a small boot partition (not /boot) at the beginning of the disk.
On Thu, 2016-08-04 at 22:21 -0400, Jonathan Billings wrote:
Is it a BIOS boot, or are you using the UEFI firmware for booting? Either way, you might need a small boot partition (not /boot) at the beginning of the disk.
/boot/efi formatted FAT16, circa 150 MB
On Fri, Aug 05, 2016 at 01:55:07PM +0100, Always Learning wrote:
On Thu, 2016-08-04 at 22:21 -0400, Jonathan Billings wrote:
Is it a BIOS boot, or are you using the UEFI firmware for booting? Either way, you might need a small boot partition (not /boot) at the beginning of the disk.
/boot/efi formatted FAT16, circa 150 MB
Even if you're using BIOS boot, if you've got a GPT-formatted disk, you'll need a 'biosboot' partition as well.
part biosboot --fstype=biosboot --size=1
(It's not necessary if you're using MBR, but it isn't clear if that's the case here.)
On Fri, 5 Aug 2016, Jonathan Billings wrote:
Even if you're using BIOS boot, if you've got a GPT-formatted disk, you'll need a 'biosboot' partition as well.
part biosboot --fstype=biosboot --size=1
That doesn't sound right. Pure EFI boot, you can just have:
part /boot/efi --fstype="efi"
Plus whatever volumes (PVs etc.) that you want.
Other question mark I'd have over the partitioning is that it's got a separate /usr.
part /usr --fstype="xfs" --ondisk=sda --size=30000 --asprimary
Separating off /usr from / is no longer supported AFAIK.
jh
On Fri, Aug 05, 2016 at 02:40:11PM +0100, John Hodrien wrote:
On Fri, 5 Aug 2016, Jonathan Billings wrote:
Even if you're using BIOS boot, if you've got a GPT-formatted disk, you'll need a 'biosboot' partition as well.
part biosboot --fstype=biosboot --size=1
That doesn't sound right. Pure EFI boot, you can just have:
part /boot/efi --fstype="efi"
I was speaking of BIOS boots, not UEFI. I agree you need an EFI partition if you're using the UEFI firmware to boot.
On Fri, August 5, 2016 8:11 am, Jonathan Billings wrote:
On Fri, Aug 05, 2016 at 01:55:07PM +0100, Always Learning wrote:
On Thu, 2016-08-04 at 22:21 -0400, Jonathan Billings wrote:
Is it a BIOS boot, or are you using the UEFI firmware for booting? Either way, you might need a small boot partition (not /boot) at the beginning of the disk.
/boot/efi formatted FAT16, circa 150 MB
Even if you're using BIOS boot, if you've got a GPT-formatted disk, you'll need a 'biosboot' partition as well.
part biosboot --fstype=biosboot --size=1
(It's not necessary if you're using MBR, but it isn't clear if that's the case here.)
Thanks Jonathan! biosboot was exactly that what solved it. I didn't find exact documentation but it sounds like you don't have much of a handle on which disklabel anaconda puts on drive. Cleverly enough it puts gpt (at least on drives larger than 2 TB). Thanks again everybody for all your insights. Here is drive portion of my kickstart file that wipes drive no matter what and puts custom partitioning in case someone some time comes across this thread
# System bootloader configuration bootloader --location=mbr --boot-drive=sda --append="crashkernel=no rhgb quiet" # Partition clearing information clearpart --all --initlabel --drives=sda # Disk partitioning information part biosboot --fstype=biosboot --size=1 part /boot --fstype="xfs" --ondisk=sda --size=500 --label=/boot part / --fstype="xfs" --ondisk=sda --size=25000 --label=/ part /var --fstype="xfs" --ondisk=sda --size=3000 --label=/var part /tmp --fstype="xfs" --ondisk=sda --size=1000 --label=/tmp part swap --fstype="swap" --ondisk=sda --size=4000 part /usr/local --fstype="xfs" --ondisk=sda --size=20000 --label=/usr/local part /home --fstype="xfs" --ondisk=sda --size=50000 --label=/home part /data --fstype="xfs" --ondisk=sda --size=100 --grow --label=/data
Thanks again, everybody! Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Fri, 2016-08-05 at 09:11 -0400, Jonathan Billings wrote:
On Fri, Aug 05, 2016 at 01:55:07PM +0100, Always Learning wrote:
On Thu, 2016-08-04 at 22:21 -0400, Jonathan Billings wrote:
Is it a BIOS boot, or are you using the UEFI firmware for booting? Either way, you might need a small boot partition (not /boot) at the beginning of the disk.
/boot/efi formatted FAT16, circa 150 MB
Even if you're using BIOS boot, if you've got a GPT-formatted disk, you'll need a 'biosboot' partition as well.
part biosboot --fstype=biosboot --size=1
(It's not necessary if you're using MBR, but it isn't clear if that's the case here.)
Thanks for that interesting tip. My GPT disks on C6 don't have it and they boot normally.
It seems biosboot is indispensable when booting GPT partitioned disks on older hardware that lacks EFI capability.
https://www.redhat.com/archives/kickstart-list/2012-August/msg00005.html
It seems the advantage of having a biosboot partition, at the start of the disk, is the disk will successfully boot-up on EFI and on older non-EFI BIOS-only systems.
One learns something new almost every day :-)
Thank you.
-
Always Learning -
John Hodrien -
Jonathan Billings -
Paul Heinlein -
Valeri Galtsev