Try to disable ACPI emulation in both Linux guest and QEMU command line. It may help.
Also check the dmesg output when grub hangs. It may be trying to access an empty or nonexistent floppy drive (I've had this behaviour in a real machine where I had to tell grub to not search for a floppy drive) El dom, 03-06-2007 a las 23:03 +0200, Bruno Cornec escribió: > Hello, > > I hope this kind of message is acceptable for this list. > [I'm not a subscriber yet, please keep my address in cc:] > > I'm the developper of a project (http://www.mondorescue.org) where I > extensively use QEMU for generating all the packages I want to produce > for my application. > > Up to now my home system was an i686 machine and I had 26 different VMs > to generate my sw for 26 different distros. All was fine, and kudos to > the dev team for that. > > I recently changed for a Core2 Duo machine, and began to add 64 bits > virutal machines to the play. > > First point, all my 26 i386 VMs seem to still work fine. > For x86_64 VMs, the results are mixed: > > Fully operational for fedora 6, mandriva 2007.0, 2007.1, rhel 4 and 5. > > My rhel 3 x86_64 VM is unable to reboot correctly. When no special > parameter given to the kernel, it does 'Lost interrupts' after detecting > my hda IDE drive, and finishes by a kernel panic. If I add noapic > nolapic to the boot line, it goes further (without 'Lost interrupts' > mesages) but panics during ethernet card setup (acpi irq messages). > > My debian 4.0 and suse 10.2 x86_64 VMs exhibit another issue. During > installation they block at grub-install and never go out - I left them > for hours with out sign of change. I tried to install grub manually > without more luck. And thus can't really finish the installation. > > Let me know if I can provide you more precise details (or screenshots) > that could help you solve those issues, or if you have tests that you > want me to perform in order to diagnose the problem. > > I already saw some similar reports (Cf: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425648) but not any > track to solve them. > > At least I hope the report is useful. > Thanks for a great tool and best regards, > Bruno.
