Kickstart Error - Error Partitioning - When Installing
So I'm testing Kickstart in latest version of VirtualBox and working with RHEL6 and the server with the Kickstart file and install isos and then I have a client.
It finds the Kickstart file via HTTP and start the process and then it hits the following error:
Error Partitioning
Could not allocate requested partitions:
not enough free space on disks.
Press 'OK' to exit the installer
I run ksvalidator against the Kickstart file and no errors come back. I've looked at alot of sample Kickstart files online to see if I can figure it out and can't make any headway.
I'm going to post what I have here:
install
lang en_US.UTF-8
keyboard us
network --bootproto-static --ip=192.168.122.100 --netmask=255.255.255.0 --device=eth0
rootpw --iscrypted (hash goes here)
firewall -disabled
authconfig --enabledshadow --passalgo-sha512
selinux --disabled
timezone --utc America/Chicago
bootloader --location=mbr --driverorder=sda --append="crashkernel=auto"
clearpart --all --initlabel
zerombr
text
logging --level=info
part /boot --fstype="ext4" --size=224
part swap --recommended
part pv.00 --size=40000 --grow
#part pv.01 --size1 --grow
volgroup Vol_Group pv.00
logvol / --fstype=ext4 --name=LogVol00 --vgname-Vol_Group01 --size=5028
logvol /home --fstype=ext4 --name=LogVol01 --vgname-Vol_Group01 --size=2028
logvol /tmp --fstype=ext4 --name=LogVol02 --vgname-Vol_Group01 --size=10052
logvol /usr --fstype=ext4 --name=LogVol03 --vgname-Vol_Group01 --size=8052
logvol /var --fstype=ext4 --name=LogVol04 --vgname-Vol_Group01 --size=4028
logvol /usr/local --fstype=ext4 --name=LogVol05 --vgname-Vol_Group01 --size=3028
logvol /opt --fstype=ext4 --name=LogVol06 --vgname-Vol_Group01 --size=4028
%packages
@base
@client-mgmt-tools
@console-internet
@core
@debugging
@basic-desktop
@desktop-platform
@directory-client
@fonts
@general-desktop
@hardware-monitoring
@internet-browser
@java-platform
@large-systems
@network-file-system-client
@network-tools
@performance
@perl-runtime
@security-tools
@server-platform
@server-policy
@system-admin-tools
@x11
mtools
pax
python-dmidecode
oddjob
wodim
sgpio
genisoimage
device-mapper-peristent-data
samba-winbind
certmonger
pam_krb5
krb5-workstation
perl-DBD-SQLite
p11-kit-trust
%end
Responses
Guru
6222 points
Volumegroup Name
volgroup Vol_Group pv.00
does not match the references in the logvol lines, and error in the use of vgname parameter.
logvol /home --fstype=ext4 --name=LogVol01 --vgname-Vol_Group01 --size=2028
*** suggested correction ***
volgroup Vol_Group01 pv.00
logvol /home --fstype=ext4 --name=LogVol01 --vgname=Vol_Group01 --size=2028
Guru
6827 points
I've seen this also on some Dell and Oracle systems (hardware), on occasion (not always), I've seen the kickstart attempt to inappropriately use the on-board media drive (not hard drive), and I had to (on Dells) adjust the visibility of the media drive.
On Sun systems, I've had this happen as well, and I had to dig through it's preboot bios or other bios system configs to make sure the proper disk was cited.
In some cases, I was able to use the "on disk" directive once i determined which disk was applicable.
Of course, the problem could be something other than above, and this is not always the case, but I've seen it occur more than once on both Oracle hardware (previously Sun Microsystems) and Dells.
lastly, on Dell and Oracle systems, I had to make sure the virtual disk was created in the raid controller bios prior to proceeding. This is especially true if someone's swapped out disks prior to loading the systems. I had to go into the raid bios, configure appropriate raids, initialize (on dells, use 'fast initialization') and then proceed.
ADDED: In some cases, I did a manual load just to get to the load screen to see what disks were visible, if any. Once I identified the proper disk, adjust the kickstart as needed, or take action as above.
See previous comments, because this may not necessarily be what I've written in this post reply...
I've found that I can get to a console with Alt+F2 and there are logs and info in /tmp and /run. In my hardware the virtual media or if the system is boot from SAN or not, FusionIO or not makes for exciting storage goofyness. Sometimes I'm installing to sdd as Anaconda see it.
In my .ks I've got it trapping a bunch of logs and info to help in those times when the install seems to work but something still failed, especially in my post Here is some stuff from the tail of my v7 ks. I expect v6 should be similar unless Anacona has changed too much. I dump them to what will be /root. They don't take much room an eventually get purged after the box is fully running. If you keep having issues hopefully this helps.
To begin with my pre and post start like this:
%pre --log=/tmp/anaconda-pre-log.txt
%post --nochroot --log=/mnt/sysimage/root/anaconda-logs/anaconda-post-log.txt mkdir /mnt/sysimage/root/anaconda-logs
Then at the end of my post I have this:
.# Grab boot choice echo $(grep "Kernel command line" /tmp/syslog) 2>&1 >> /mnt/sysimage/root/anaconda-logs/boot-choice
.# Grab .ks file(s) cp /run/install/repo/*.ks /mnt/sysimage/root/anaconda-logs/
.# Grab Anaconda logs cp -r /tmp/* /mnt/sysimage/root/anaconda-logs/ .#These logs are created by Anaconda itself in /tmp. See: https://fedoraproject.org/wiki/Anaconda/Logging .# anaconda.log, the general installation information, particularly the step changes. .# storage.log, storage devices scan and manipulation (hard drives, partitions, LVM, RAID), partitioning. .# program.log, calls to external programs, their output. .# syslog, messages from kernel and external programs (Network Manager). .# anaconda-yum.log, yum's internal log. .# ifcfg.log, Processing and creation of the network scripts. .# packaging.log, further info from Yum & Anaconda. .# ks-scriot-*, Resolved %pre and %post sections.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.