Bug 1019778 - ubuntu guest would stop at grub screen after multiple system_reset
ubuntu guest would stop at grub screen after multiple system_reset
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
6.5
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Ademar Reis
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-16 07:41 EDT by Xiaoqing Wei
Modified: 2013-10-17 10:55 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-17 10:55:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
guest pic (20.36 KB, image/jpeg)
2013-10-16 07:41 EDT, Xiaoqing Wei
no flags Details

  None (edit)
Description Xiaoqing Wei 2013-10-16 07:41:45 EDT
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:
Comment 2 Ademar Reis 2013-10-16 10:01:54 EDT
(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.
Comment 3 Xiaoqing Wei 2013-10-16 22:26:29 EDT
(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.
Comment 4 Ademar Reis 2013-10-17 10:55:05 EDT
(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)

Note You need to log in before you can comment on or make changes to this bug.