Hide Forgot
Created attachment 812873 [details] guest pic Description of problem: ubuntu guest would stop at grub screen after multiple system_reset Version-Release number of selected component (if applicable): kernel-2.6.32-422.el6.x86_64 qemu-kvm-rhev-0.12.1.2-2.412.el6.x86_64 spice-server-0.12.4-3.el6.x86_64 gpxe-roms-qemu-0.9.7-6.10.el6.noarch package vgabios-bin is not installed sgabios-bin-0-0.3.20110621svn.el6.noarch seabios-0.6.1.2-28.el6.x86_64 ubuntu-12.04 or ubuntu-13.04 How reproducible: 4/4 Steps to Reproduce: 1./root/staf-kvm-devel/autotest-devel/client/tests/virt/qemu/qemu \ -S \ -name 'virt-tests-vm1' \ -nodefaults \ -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20131015-173942-7y3gpb7k,server,nowait \ -mon chardev=qmp_id_qmpmonitor1,mode=control \ -chardev socket,id=serial_id_serial1,path=/tmp/serial-serial1-20131015-173942-7y3gpb7k,server,nowait \ -device isa-serial,chardev=serial_id_serial1 \ -chardev socket,id=seabioslog_id_20131015-173942-7y3gpb7k,path=/tmp/seabios-20131015-173942-7y3gpb7k,server,nowait \ -device isa-debugcon,chardev=seabioslog_id_20131015-173942-7y3gpb7k,iobase=0x402 \ -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=0x4 \ -drive file='/root/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/images/ubuntu-13.04-server-64-virtio.qcow2',index=0,if=none,id=drive-virtio-disk1,media=disk,cache=none,snapshot=off,format=qcow2,aio=native \ -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,bootindex=0 \ -device virtio-net-pci,netdev=idnmcZuR,mac='9a:f7:f8:f9:fa:fb',bus=pci.0,addr=0x3,id='idu7Jt6M' \ -netdev tap,id=idnmcZuR,vhost=on,vhostfd=23,fd=22 \ -m 2048 \ -smp 2,maxcpus=2,cores=1,threads=1,sockets=2 \ -cpu 'SandyBridge' \ -M rhel6.5.0 \ -device AC97,addr=0x6 \ -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \ -vnc :0 \ -vga cirrus \ -rtc base=utc,clock=host,driftfix=slew \ -boot order=cdn,once=c,menu=off \ -no-kvm-pit-reinjection \ -enable-kvm 2. login guest 3. then on qemu monitor: system_reset(send multiple times, sleep 0 ~ 120 sec before next system_reset ) Actual results: vm stops at grub, wont automatically select a entry to boot, manually send enter key would boot Expected results: guest should still boot automatically Additional info:
(In reply to Xiaoqing Wei from comment #0) > 2. login guest > 3. then on qemu monitor: system_reset(send multiple times, sleep 0 ~ 120 sec > before next system_reset ) > > Actual results: > vm stops at grub, wont automatically select a entry to boot, manually send > enter key would boot Since you're resetting the VM with the OS "alive", I wonder if the guest fs is getting corrupted, or files that interfere with grub are changed by something that happens in the background (in the guest). One way to check is: once it gets stuck at the boot screen (grub), shut it off (not just a reset) and then on again. What happens on the next boot? If it gets stuck again, then my theory is right and there's nothing we can do.
(In reply to Ademar de Souza Reis Jr. from comment #2) > (In reply to Xiaoqing Wei from comment #0) > > 2. login guest > > 3. then on qemu monitor: system_reset(send multiple times, sleep 0 ~ 120 sec > > before next system_reset ) > > > > Actual results: > > vm stops at grub, wont automatically select a entry to boot, manually send > > enter key would boot > > Since you're resetting the VM with the OS "alive", I wonder if the guest fs > is getting corrupted, or files that interfere with grub are changed by > something that happens in the background (in the guest). > > One way to check is: once it gets stuck at the boot screen (grub), shut it > off (not just a reset) and then on again. What happens on the next boot? If > it gets stuck again, then my theory is right and there's nothing we can do. I tried quit the qemu process when this happens, then launch the qemu again, the vm still, get stuck at the grub, Regards, Xiaoqing.
(In reply to Xiaoqing Wei from comment #3) > > Since you're resetting the VM with the OS "alive", I wonder if the guest fs > > is getting corrupted, or files that interfere with grub are changed by > > something that happens in the background (in the guest). > > > > One way to check is: once it gets stuck at the boot screen (grub), shut it > > off (not just a reset) and then on again. What happens on the next boot? If > > it gets stuck again, then my theory is right and there's nothing we can do. > > I tried quit the qemu process when this happens, then launch the qemu again, > the vm still, get stuck at the grub, > That means something is wrong on the guest side. Since you're rebooting the VM "the hard way" many times, this is expected (it's like hitting the "reset" button on a physical machines while the OS is alive... odds are at some point it'll stop working if you do this many times)