I’ve successfully set up a couple of AVDF installation on different VM Server as well on HP Blade or Rack servers. On the VM server I never had any problems. For the installation of AVDF 12.1.1.x on HP servers BL465c Gen8 or DL380p Gen8, there were always warnings during partitioning of the disks. So far it was never an issue to just continue the installation. With AVDF 12.1.2 this has changed. On some HP servers with smart array disk controller the installation fails because of problems with the drivers respectively device names.
Earlier installation of AVDF like 220.127.116.11.0 simply complained about not enough space.
OK, 0GB is a bit less for setting up an AVDF Server :-), nevertheless ignoring the error still worked. AVDF 18.104.22.168 as well AVDF 22.214.171.124 could be successfully setup using the cciss Driver for HP Smart Array. As of AVDF 12.1.2 the error is not that friendly any more.
The title of the error “Error Parsing Kickstart Config” indicates that there is an issue at an early stage of the system setup. It is worth having a deeper look into the kickstart configuration file. The kickstart file can be found in the initrd.img image on the AVDF installation ISO. See AVDF installation ISO for how to extract the kickstart file.
In the kickstart file we can see at line 62, that a pre-script is executed to create the partition commands. This pre-script is a python script which does create a temporary file (/tmp/partition-include) with the partition commands based on the available disks. The partition command itself is then included at line 36.
########## Partition the disk ##############
# Create logical volume group - this is where all volumes will reside
volgroup vg_root pv.01
# Now create the volumes, a.k.a logical partitions. The data partions (/var/lib/oracle) is grown
# up to the specified size. The rest of the FS is left unallocated.
# You must make changes to ruby_lib/dbfw/dbfw_fstab.rb if you change the FS specification.
logvol swap --fstype swap --vgname=vg_root --size=4096 --name=lv_swap
logvol / --fstype ext3 --fsoptions="noatime" --vgname=vg_root --size=7000 --name=lv_root
logvol /images --fstype ext3 --fsoptions="noexec,nodev,nosuid,noatime" --vgname=vg_root --size=15000 --name=lv_images
logvol /usr/local/dbfw --fstype ext3 --fsoptions="noatime" --vgname=vg_root --size=1000 --name=lv_local_dbfw
logvol /usr/local/dbfw/tmp --fstype ext3 --fsoptions="noexec,nodev,nosuid,noatime" --vgname=vg_root --size=9000 --name=lv_local_dbfw_tmp
logvol /home --fstype ext3 --fsoptions="noexec,nodev,nosuid,noatime" --vgname=vg_root --size=1000 --name=lv_home
logvol /tmp --fstype ext3 --fsoptions="nodev,nosuid,noatime" --vgname=vg_root --size=2000 --name=lv_tmp
logvol /var/log --fstype ext3 --fsoptions="noexec,nodev,nosuid,noatime" --vgname=vg_root --size=6000 --name=lv_var_log
logvol /var/tmp --fstype ext3 --fsoptions="noexec,nodev,nosuid,noatime" --vgname=vg_root --size=6000 --name=lv_var_tmp
logvol /var/www --fstype ext3 --fsoptions="nodev,nosuid,noatime" --vgname=vg_root --size=1000 --name=lv_var_www
logvol /var/www/tmp --fstype ext3 --fsoptions="nodev,nosuid,noatime" --vgname=vg_root --size=1000 --name=lv_var_www_tmp
logvol /var/lib/oracle --fstype ext3 --fsoptions="noatime" --vgname=vg_root --size=20000 --name=lv_oracle
logvol /var/dbfw --fstype ext3 --fsoptions="noatime" --vgname=vg_root --size=10000 --name=lv_var_dbfw
# Tasks performed before installation
python /kickstart/partitions.py 2> /tmp/partitions_error
if [ $? -ne 0 ]; then
Having a look into the file /tmp/partition-include reveals the wrong partition command which leads to the error mentioned earlier. As you can see below the disks are specified with –ondisk=cciss!c0d0 rather than –ondisk=cciss/c0d0. The python script which builds the partition commands, has issues with the device names. Actually, for an HP smart array disk, the corresponding driver should be loaded so that the devices are visible as sd*. The root cause could be the missing driver or an error in the python script. I’ve opened a service request with oracle Support for further analysis.
For the moment I just see the following two workarounds.
- First install and configure AVDF 126.96.36.199 and perform an upgrade to AVDF 12.1.2.
- Install AVDF 12.1.2 with an alternative kickstart file respectively partition commands
The first workaround is straightforward. It just takes a bit more time. For the second workaround you may create a new AVDF ISO image, but this is way to complex. It is much simpler to manually specify the boot options and provide an alternative kickstart file on an internal web server. The kickstart file is the same as for the regular AVDF 12.1.2 installation, it just has a fixed partition section. For that I have taken the partitioning commands from the file /tmp/partition-include and removed the –ondisk parameter. I’ll provide my kickstart file as an example for download. But do not use it directly the partitioning section must be adapted to your environment.
Action plan for the workaround:
- Create an alternative kickstart file with correct partition commands for your environment
- Put the kickstart file on a Webserver which is accessible by the AVDF Server
- Boot from AVDF 12.1.2 ISO image with custom boot parameter
My custom boot option did look like the following command. The IP address is the address of my web server.
vmlinuz noipv6 initrd=initrd.img ramdisk_size=8192 ks=http://188.8.131.52/avdf.cfg
This problem is quite annoying, especially if you have already done the installation on another physical or virtual servers several times. The workaround is basically simple. With a bit enhanced Linux knowledge and a web server, one has quickly created an installation with an alternative kickstart file. Nevertheless I highly recommend to open a service request with Oracle when you have similar issues with your hardware during the setup of a productive AVDF 12.1.2 environment.
Further information on this topic.