Is this the likely problem: extracting from
/usr/lib/python2.7/site-packages/koan/virtinstall.py and adding line numbers:
198 if is_qemu and virt_type:
199 if not disable_virt_type:
200 cmd += "--virt-type %s " % virt_type
201 if fullvirt or is_qemu or is_import:
202 if fullvirt is not None:
203 cmd += "--hvm "
204 else:
205 cmd += ("--extra-args=\"%s\" " % (extra))
206 if is_xen:
207 cmd += "--pxe "
208 elif cdrom:
209 cmd += "--cdrom %s " % cdrom
210 elif location:
211 cmd += "--location %s " % location
212 elif importpath:
213 cmd += "--import "
214 if arch:
215 cmd += "--arch %s " % arch
216 else:
217 cmd += "--paravirt "
218 cmd += ("--boot kernel=%s,initrd=%s,kernel_args=\"%s\"
" %
219 (kernel, initrd, extra))
I think that the else: on line 204 is wrong: if it's a qemu virtualisation, then
surely the --extra-args need passing through to get the kickstart file name?
I'm not sure as I've only got a qemu based set up, but if I remove the else:, it
works for me.
Tim
On 3 Sep 2012, at 11:58, Tim Coote wrote:
Hullo
I've recently preupgrade-cli'd a box from f15 to f17 and now my koan/cobbler
builds no longer inject kickstart files.
Even if I take the stock /var/lib/cobbler/kickstarts/sample.ks and use it as the ks for a
profile, when I run:
sudo koan --virt --virt-name=robot --server=puppet --system=robot
[robot's defined as being based on f17-i386 profile, which has a Kickstart using the
sample.ks above]
After powering up, the vm starts a graphical install and seems to have no knowledge of
the kickstart file. If I take it through the graphical install, the /root/anaconda-ks.cfg
is the default created by anaconda. Nothing gives the game away when I log into the
VM's console during the installation.
It doesn't seem to matter if I use an older profile (I've tried F15).
I'm using cobbler-2.2.3-2.fc17.noarch, and koan-2.2.3-2.fc17.noarch
sudo cobbler validateks doesn't complain (I had to fix the
$kickstart_start/$kickstart_done in the old kickstarts, but these are not present in the
sample.ks).
The only oddities that I can identify are /var/log/messages entries like these:
Sep 3 10:28:18 mercury libvirtd[4807]: 2012-09-03 09:28:18.284+0000: 4808: error :
virSecurityDACRestoreSecurityFileLabel:148 : cannot resolve symlink
/var/lib/libvirt/boot/virtinst-vmlinuz.
5LB4JW: No such file or directory
Sep 3 10:28:18 mercury libvirtd[4807]: 2012-09-03 09:28:18.284+0000: 4808: error :
virSecurityDACRestoreSecurityFileLabel:148 : cannot resolve symlink
/var/lib/libvirt/boot/virtinst-initrd.i
mg.fhjuOM: No such file or directory
which could imply that there's something odd that's preventing the libvirtd
setting up the boot filesystem, but I don't know enough about the innards to work that
out. sudo rpm -V libvirtd shows no errors.
Any pointers on how to work out what's going wrong/how to identify what's going
wrong?
Tim