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
_______________________________________________
cobbler mailing list
cobbler@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/cobbler
