Description of problem: As swap partitions use the same ID as old Solaris partitions. Version-Release number of selected component (if applicable): xenner-0.36-1.fc9.x86_64
Can you provide a log? (/var/log/libvirt/qemu/<name>.log when using libvirt, stderr otherwise). Probably it is pygrub failing to find a kernel on the guest disk.
[root@nostromo images]# pygrub -i /var/lib/libvirt/images/test.img Traceback (most recent call last): File "/usr/bin/pygrub", line 648, in <module> fs = fsimage.open(file, get_fs_offset(file)) File "/usr/bin/pygrub", line 117, in get_fs_offset offset += get_solaris_slice(file, offset) File "/usr/bin/pygrub", line 80, in get_solaris_slice raise RuntimeError, "Invalid disklabel magic" RuntimeError: Invalid disklabel magic
Ok, so it actually is pygrub failing. It isn't xenner specific, trying with xen itself will fail the very same way. It also isn't very surprising because pygrub uses the bootable flag to figure the partition it should get the kernel from. IMHO that isn't a bug. Why is the boot flag set on the swap partition in the first place?
Left over from playing with a usb stick, IIRC. Why is it not a bug? Shouldn't it just ignore the partition and continue?
Ignoring the partition would break booting solaris guests. Just fix the active flag.
How would it break booting a solaris guest if you just logged the disklabel error and continued? If they don't have a valid solaris boot, it would still then fail.
Ignoring the swap partition (by id) would break solaris guests, this is what I assumed you meant. Well, continue with what? pygrub doesn't scan all partitions, trying to guess which one is the boot partition. It expects the boot flag being set on the boot partition and looks only at that one.
Hm, OK. However, you can have multiple partitions with the boot flag, so I wonder if that's enough.