When using qemu-kvm-1.0-r3 in no-kvm mode (with -no-kvm option and no kvm module loaded on host). my gentoo linux virtual machine crashes during or after the udev boot step. A) Using qmeu under libvirt environment In Libvirt/Qemu host log TODO /var/tmp/portage/app-emulation/qemu-kvm-1.0-r3/work/qemu-kvm-1.0/tci.c:1006: tcg_qemu_tb_exec() /var/tmp/portage/app-emulation/qemu-kvm-1.0-r3/work/qemu-kvm-1.0/tci.c:1006: tcg fatal error 2012-03-29 13:39:56.456+0000: shutting down. B) Same result when direct launching qemu-system-x86_64 -no-kvm ... <my-guest> ... Reproducible: Always Steps to Reproduce: 1.unload kernel kvm module on host # rmmod kvm-intel # rmmod kvm 2. Launch the virtual machine with no-kvm option /usr/bin/qemu-system-x86_64 -no-kvm ... my-machine 3. Actual Results: Be patient, virtual machine could be very slow due to -no-kvm option Display after VM crash: TODO /var/tmp/portage/app-emulation/qemu-kvm-1.0-r3/work/qemu-kvm-1.0/tci.c:1006: tcg_qemu_tb_exec() /var/tmp/portage/app-emulation/qemu-kvm-1.0-r3/work/qemu-kvm-1.0/tci.c:1006: tcg fatal error Aborted It seems that some temp portage references are hard coded in the qemu-system-x86_64 binary file # grep /var/tmp/portage/app-emulation /usr/bin/qemu-system-x86_64 Binary file /usr/bin/qemu-system-x86_64 matches. Expected Results: VM running at very slow speed but eprational and up.
Created attachment 307081 [details] emerge --info
Depending on how the build system invokes the compiler, use of __FILE__ can result in the fully qualified source path being included as a string. It is common for debugging macros to use __FILE__ as part of their output so that the corresponding source line can be found easily. An abort on startup is a real bug, but the presence of the $PORTAGE_TMPDIR paths as ordinary strings is not a bug.
Several application I've seen does this. I've you've got suggestions how to manipulate the __FILE__ values I'm all ears, otherwise there's not much that I can see that can be done.
Maybe the Portage guys have some suggestions.
I'm thinking that comment #2 sounds like a good hypothesis, which suggests that the appearance of $PORTAGE_TMPDIR in the backtrace may be irrelevant.
Well then this is a can't fix.
